OK, so I should have asked this student (not one of mine!) for an example before emailing the lists. In his (toy) example he had a 6x6 integer matrix M and did
e = max(M.eigenvalues()) N = M-e v = N.right_kernel().basis()[0] etc, which resulted in everything happening in Qbar, or in fact AA since the eigenvalues were all real. In that example there was an eigenvalue 1 with multiplicity 4 and two other quadratic ones; when I manually changed the base to the correct quadratic field his computation time went down from 35s to 0.02s. Now all he needs is to wait for Jeroen's splitting field code from #2217 and #15626 -- already merged i n6.1.beta -- to be released! Sorry for the noise. John On 9 January 2014 15:50, William Stein <wst...@gmail.com> wrote: > On Thu, Jan 9, 2014 at 6:21 AM, John Cremona <john.crem...@gmail.com> wrote: >> Thanks, Bill. I don't think that the Warwick student is using Magma, >> he was more "how can it possibly take so long to multiply a couple of >> algebraic numbers!". His degrees are not large (at most 12) but >> coefficients large. > > Are they relative extensions? Our relative numbers fields are very > slow in some situations compared to magma, since we just convert to an > absolute field and work there. Or at least that was the case a few > years ago when I tried to fix it (at RISC), but didn't finish that > patch. I think Mike Hansen worked on this, but I don't know if he > fixed it. > > I think pure arithmetic in quadratic fields in Sage is faster than > other systems, due to low-level optimizations that Robert Bradshaw > made with a specialized quadratic field class. > > william > >> >> I have asked for some more speicif sample computations and will take a >> ook at their code myself before passing it on for some testing. >> >> John >> >> On 9 January 2014 13:58, Bill Hart <goodwillh...@googlemail.com> wrote: >>> If they are comparing with Magma there are two reasons that I'm aware of: >>> >>> 1) Magma multiplies elements b and c of a number field with defining >>> polynomial f by simply multiplying the polynomials representing b and c, but >>> NOT reducing mod f. Only when you request an operation which requires a >>> canonical representation does it actually do the reduction. Thus when timing >>> some operations, Magma seems almost infinitely faster. >>> >>> 2) Magma does not bring rational coefficients *of number field elements* >>> into lowest terms, again until you request an operation which requires a >>> canonical representation. >>> >>> The ANTIC library Claus Fieker and I are implementing currently does the >>> reductions, but we have plans to add some operations which don't do the >>> reduction so the user has control over this. The reason for this is that in >>> timings I found that the method speeds up some things but uses much more >>> memory and can also slow down some computations. >>> >>> Anyway, with or without reduction, ANTIC beats Magma, of course. But >>> development of this flint extension is still in early days. Magma does a lot >>> of things internally when working with number fields, and it isn't clear yet >>> exactly how things will go for us. We might yet slow down a lot. >>> >>> Bill. >>> >>> P.S: At least in some versions of Magma you can actually bring the garbage >>> collector to its knees with some carefully chosen number field computations. >>> All subsequent operations then take many times longer. I did report this to >>> the Magma people. >>> >>> >>> >>> >>> On 9 January 2014 14:42, John Cremona <john.crem...@gmail.com> wrote: >>>> >>>> Two separate people today (one a colleague who works in geometric >>>> topology and group theory, the other a number theorist known to many >>>> on these lists) have said to me "Sage is still ridiculously slow on >>>> number field calculations" (quoting one of them). >>>> >>>> I also know that when William wanted to do some large-scale >>>> computations over Q(sqrt(5)) he found it necessary to implement >>>> arithmetic in that specific field directly in order to get good >>>> performance; and a student of mine is finding similar slow >>>> performance for imaginary quadratic fields. >>>> >>>> I am only talking about basic field arithmetic here, nothing fancy. >>>> >>>> Does anyone know the real cause of this, or have any ideas on how to >>>> improve the situation? Surely the pari C library is not so slow? Is >>>> it the interface? >>>> >>>> I am CC-ing Bill Hart since I know that he is working on a new >>>> extension to FLINT which would do this. >>>> >>>> John >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-nt" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-nt+unsubscr...@googlegroups.com. >> To post to this group, send an email to sage...@googlegroups.com. >> Visit this group at http://groups.google.com/group/sage-nt. >> For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > You received this message because you are subscribed to the Google Groups > "sage-nt" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-nt+unsubscr...@googlegroups.com. > To post to this group, send an email to sage...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-nt. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
