My point is that it is the same on Apple Mac, that it isn't related to the 
recent interface and multiprocessing problems but has just appeared with 
the 9.5 kernel beta release as it works with the 9.4 kernel.

On Sunday, February 6, 2022 at 8:53:51 AM UTC Emmanuel Charpentier wrote:

> That was my initial complaint... ;-)
>
> Le samedi 5 février 2022 à 18:05:42 UTC+1, alan_thoma...@yahoo.co.uk a 
> écrit :
>
>> M.eigenvalues() never returns.
>> On Saturday, February 5, 2022 at 11:48:47 AM UTC Emmanuel Charpentier 
>> wrote:
>>
>>> 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/0103d0cd-ae31-4e6f-861f-ccbbbda26830n%40googlegroups.com.

Reply via email to