The case that started me was sage: a=SR(1/2) sage: b=SR(3) sage: %timeit _=a^b The slowest run took 9.38 times longer than the fastest. This could mean that an intermediate result is being cached. 100000 loops, best of 3: 2.14 µs per loop sage: %timeit _=b^a 10000 loops, best of 3: 62.1 µs per loop
but I think I can shortcut Python/Cython usage here. I also wanted to scout the software landscape before any other decisions. On Monday, May 29, 2017 at 8:39:59 AM UTC+2, Dima Pasechnik wrote: > > > > On Monday, May 29, 2017 at 6:09:33 AM UTC+1, Ralf Stephan wrote: >> >> On Sunday, May 28, 2017 at 11:40:08 PM UTC+2, Jeroen Demeyer wrote: >>> >>> On 2017-05-26 15:19, Ralf Stephan wrote: >>> > The qqbar source does not use a lower-level library. >>> >>> What do you mean with this? It actually uses quite a large fraction of >>> Sage (number fields, polynomials, interval arithmetic, ...) >>> >> >> Make that "lower-language-level" i.e. C/C++. There was also >> the words "one" and "fast" in my original post. >> > > Is qqbar really so slow? Perhaps you could point out particularly slow for > your purposes parts ? > > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
