Re: [sage-devel] Re: devising a speed comparison test between different types

2016-12-04 Thread William Stein
On Sat, Dec 3, 2016 at 10:53 PM, Ralf Stephan <> wrote: “Both ZZ and numpy use libgmp internally “ No, ZZ uses libgmp (actually really MPIR, which is a fork of GMP), and numpy uses Python’s ints/longs. Python’s int/long type is arbitrary precision, despite the confusing naming. It only

Re: [sage-devel] Re: devising a speed comparison test between different types

2016-12-04 Thread Volker Braun
On Sunday, December 4, 2016 at 5:58:45 PM UTC+1, Pierre wrote: > -- numpy.int32 or int.64: like "int" initially, but works mod 2^32 or > 2^64, and gives an overflow warning when it happens. No increase in > speed, for general reasons which I will just call "overhead" for lack > of a better

Re: [sage-devel] Re: devising a speed comparison test between different types

2016-12-04 Thread Pierre Guillot
PPS come to think of it, my last PS explains it all. So in summary: -- ZZ= always arbitrary precision. -- int= a C int when the numbers stay < 2^64, so there is an increase of speed -- but not nearly as much of an increase as I expected, which is why I was confused at first, because I wasn't

[sage-devel] Re: devising a speed comparison test between different types

2016-12-04 Thread Pierre
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

[sage-devel] Re: devising a speed comparison test between different types

2016-12-04 Thread Pierre
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:

[sage-devel] Re: devising a speed comparison test between different types

2016-12-04 Thread Simon King
PS: On 2016-12-03, Pierre wrote: > I thought about multiplying large matrices, but I'm afraid that completely > different algorithms/libraries will be used depending on the parent ring Yes, this would measure the efficiency of matrix arithmetics but would give no

[sage-devel] Re: devising a speed comparison test between different types

2016-12-04 Thread Simon King
Hi Pierre, On 2016-12-03, Pierre wrote: > We are talking about very basic advice to give to a beginner, and so, I > knew enough to say that well, C ints (so I guess numpy.int's) will be fast, > but limited in size, and elements of ZZ can be as large as your memory >

[sage-devel] Re: devising a speed comparison test between different types

2016-12-03 Thread Ralf Stephan
On Sunday, December 4, 2016 at 12:00:58 AM UTC+1, Pierre wrote: > > I tried naive things like setting x and y to be integers of a certain > type, and then > > sage: %timeit x^y > > for example, but I always get "" The slowest run took 59.81 times longer > than the fastest. This could mean that