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, [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-support/92849dec-4de0-4685-84bb-46e044e421e2n%40googlegroups.com.
