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/5075f1d9-b060-49e7-ba30-216df60a2336n%40googlegroups.com.

Reply via email to