Is it the same M for 9.4 as for 9.5?

On Sun, 6 Feb 2022, 10:52 'Alan Stafford' via sage-support, <
sage-support@googlegroups.com> wrote:

> 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
> <https://groups.google.com/d/msgid/sage-support/0103d0cd-ae31-4e6f-861f-ccbbbda26830n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAAWYfq0f3PmsV3-58G5R6LU4K7yMR2-g1Fw41scnbmLz%3DOdcyw%40mail.gmail.com.

Reply via email to