What exactly fails in the example ?
Le vendredi 4 février 2022 à 13:20:26 UTC+1, alan_thoma...@yahoo.co.uk a
écrit :
>
> On Apple Mac the example above runs on the 9.4 kernel using either the 9.4
> or 9.5 interface but not on the 9.5 kernel from either Interface.
> On Thursday, February 3, 2022 at 6:44:47 AM UTC Emmanuel Charpentier wrote:
>
>> Le mercredi 2 février 2022 à 22:15:00 UTC+1, Nils Bruin a écrit :
>>
>> On Monday, 31 January 2022 at 15:19:49 UTC-8 Emmanuel Charpentier wrote:
>>>
>>>> As advertised, an atempt at a minimal (non-)working example :
>>>>
>>>> # Reproducible minimal example
>>>> with seed(0): M = matrix(AA, 3, 3, lambda u,v: AA.random_element())
>>>> # Working ring
>>>> WR = M.base_ring().algebraic_closure()
>>>> # A variable to carry the eigenvalues
>>>> l = SR.var("l")
>>>> # Vector of unknowns for the eigenvectors
>>>> V =vector(list(var("v", n=2))+[SR(1)])
>>>> # M.eigenvalues does not return. Get them by hand
>>>>
>>>> Actually, for me on 9.5beta9, `M.eigenvalues()` works just fine.
>>>
>> Hmmm… You may have obtained a “less pathological” M than I did, due to
>> possible differences in random numbers generation (notwithstanding my
>> attempt at reproducibility…).
>>
>> What do you get for M ? I have :
>>
>> sage: with seed(0): M = matrix(AA, 3, 3, lambda u,v: AA.random_element())
>> sage: M.apply_map(lambda u:u.radical_expression())
>> [ -sqrt(2) - 1 -1/4 -2*sqrt(3)]
>> [ 1/2 1/8*sqrt(33) + 1/8 -1/5*sqrt(29) + 3/5]
>> [ 0 1/4 1/2]
>>
>> So the problem is perhaps just platform-dependent, or there is a very
>>> recent change that affected this (my M gets just integer entries from
>>> {-2..2})
>>>
>> Okay. We have a problem in reproducibility : with seed(0): should entail
>> a reproducible, platform-independent result. It did not. BTW, what is your
>> platform ?
>>
>> Suggestions on how to document this and file a ticket ?
>>
>> I agree with the rest of your conclusions, but going to numerical
>> approximations then trying to somehow “recognize” the algebraics they are
>> approximations of somehow denies the whole point of working in QQbar…
>>
>> Looking at the example a bit: you'd be forcing sage to work with a huge
>>> compositum if you're actually getting a 3x3 matrix with non-rational
>>> algebraic entries: even if they are just independent quadratics, you'd end
>>> up in an extension of degree 2^9. This will only work in very limited cases.
>>>
>>> One way to get this kind of thing to work is to work with high-precision
>>> floats, use numerically (fairly) stable methods to compute the desired
>>> answer, and then try to recognize it as algebraic. You probably only care
>>> if it is one of fairly low height. You can then try to turn your
>>> computation into proof, possibly by tracing through height bounds and
>>> showing your precision was sufficient to identify the right solution
>>> uniquely.
>>>
>>> You could work on automating this kind of thing, but I doubt you'd ever
>>> get it to work on a reasonable range of examples; just because the height
>>> bounds would be rather ill-behaved.
>>>
>>> You can still trace the root cause further on this and perhaps improve
>>> arithmetic in AA a bit, but the general shape of the problem you're trying
>>> to deal with does not look promising for generally performant methods.
>>>
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-support/1371b6cf-4ae6-4a69-b178-b9ee0a4e8761n%40googlegroups.com.
