performance problem in python 2.2

[Jeff Davis]

Paul Rubin wrote:

> Jeff Davis <jdavis at empires.org> writes:
>> 'p' was an unsigned long long int. I slightly modified the algorithm in
>> C because it doesn't have (native) support for > 64-bit ints. Since the
>> number of possibilities is 2**64 that value will be slightly bigger than
>> a 64 bit int could hold. So, I just basically multiplied twice by 2^32
>> and divided twice by 2^32. In other words, I basically treated 'p' as
>> sqrt(p)*sqrt(p) and commuted the multiplication so that I would arrive
>> at the same result (and the testing seemed to show the same results as
>> my other algorithm). I have attached my c code below in case you'd like
>> to know exactly what's going on.
> 
> It's amazing that you ended up with an accurate answer doing that.
> 
> You should do this kind of thing completely in floating point:
> 
> double p;
> p = pow(2.0, 64.0);   /* 2**64 */
> etc.

Strange that you mention that, because I sort of thought I might get  a 
more precise answer. After all, mine preserves the entire number 2^64, 
yours just preserves most. Mine might end up losing it all later in the 
calculations (because there are more multiplications), is that what you 
mean?

But yes, yours is more elegant, and even if mine did get some extra 
precision, it didn't affect the results appearently. So, in the future, I 
will just use doubles and maybe try something else if I really do *need* 
it. 

I actually did this more to preserve the type of calculations that the C 
program was doing compared with the python program. However, I'll use the 
floats in python as well from now on :)

Regards,
        Jeff

> 
> 
>> #!/usr/bin/python2.2
>> 
>> import sys
>> 
>> n = 1.0
>> p = 2L**64
>> c = long(sys.argv[1],10)
> 
> Try "p = 2.**64" instead of "2L**64" and see if you get a speedup.
> Also, make c int instead of long unless you want c > 2**31.