PS actually, i am a little wrong with Python ints being arbitrary precision. In fact there is no such thing as just a python int, there is "int" and "long", but computations with ints can give you an answer which is "long"; presumably this mostly means that everything is as slow as if everything was always a "long". Well, i don't really know, and I wish I did.
On Sunday, December 4, 2016 at 8:47:12 AM UTC-5, Pierre wrote: > > Hi all, > > Thanks for your answers. There are a few things that I now understand, but > i'm still confused. One crucial mistake I made was, as I see now thanks to > Ralf's message, to believe that numpy.int meant "C int": no, it means > python int ! For C ints, use numpy.int32 (or 64). In fact : > > sage: numpy.int(2) ^ numpy.int(32) > 4294967296 > > sage: numpy.int(2) ^ numpy.int(64) > 18446744073709551616L #notice the L, typical of python ints > > sage: numpy.int32(2) ^ numpy.int32(32) > /Applications/SageMath/src/bin/sage-ipython:1: RuntimeWarning: overflow > encountered in int_scalars > #!/usr/bin/env python > 0 > > > All as expected. And to answer Simon's interrogation, if I'm correct a > python int is actually arbitrary precision (and it prints with an L when > above 2^64), but it's slower than ZZ. It's not a C int. > > However, i've been playing with Simon's code for testing (nice idea!), and > i'm still puzzled: > > sage: %time testfunc(ZZ(1234123), ZZ(1234123), operator.add) > CPU times: user 69.3 ms, sys: 787 µs, total: 70.1 ms > Wall time: 70.8 ms > > sage: %time testfunc(int(1234123), int(1234123), operator.add) > CPU times: user 42.3 ms, sys: 631 µs, total: 42.9 ms > Wall time: 43.5 ms > > sage: %time testfunc(numpy.int(1234123), numpy.int(1234123), operator.add) > CPU times: user 44 ms, sys: 538 µs, total: 44.5 ms > Wall time: 45 ms > > sage: %time testfunc(numpy.int32(1234123), numpy.int32(1234123), operator. > add) > CPU times: user 74.2 ms, sys: 822 µs, total: 75 ms > Wall time: 77.7 ms > > So ZZ is slightly slower than python int = numpy.int, which is already > weird since the arbitrary precision integers of ZZ are meant to faster than > those of python. > > But even more bizarre is the fact that numpy.int32 gives the slowest > performance! i'm guessing that the operator.add includes overhead when > asking numpy to add its ints. > > Question: Is there a way of using very fast C integers within Sage, > without using Cython? (the latter because the answer is meant to be > understandable by beginners). > > If I figure this out, I guess the analogous question with floats will be > answered, too. > > Thanks ! > > Pierre > > > > > > > > -- 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.
