long int computations

[Victor Eijkhout]

I have two long ints, both too long to convert to float, but their ratio
is something reasonable. How can I compute that? The obvious "(1.*x)/y"
does not work.

Victor.

 

[Peter Otten]

I have two long ints, both too long to convert to float, but their ratio
is something reasonable. How can I compute that? The obvious "(1.*x)/y"
does not work.

Traceback (most recent call last):
16.137254901960784

Peter

 

[Jerry Hill]

I have two long ints, both too long to convert to float, but their ratio
is something reasonable. How can I compute that? The obvious "(1.*x)/y"
does not work.

You didn't say what version of python you were using, but this seems
to work for me in 2.6.4:

Traceback (most recent call last):
File "<pyshell#5>", line 1, in <module>
float(long1)
OverflowError: long int too large to convert to float

0L

0.5

The "from __future__ import division" line gets python to return a
float as the result of dividing two integers (or longs), instead of
returning an integer. If I recall correctly, this has been available
for quite a few python versions (since 2.2 maybe?), and has become the
default in python 3.

If you need to do integer division, you would use the // operator:
0L

Hope that helps.

 

[Dave Angel]

I have two long ints, both too long to convert to float, but their ratio
is something reasonable. How can I compute that? The obvious "(1.*x)/y"
does not work.

Victor.

You don't make clear what you mean by "too long to convert to float."
Do you mean can't convert exactly, or that they're more than 400 digits
or whatever the exponent limit of float is (I'm too lazy to look it up
right now) ?

Assuming the latter, you could divide each by the same constant, then
use your formula above to make a float version of the ratio. How to
pick the constant? How about the smaller of your numbers, divided by
1e18 ? You'd have to build that number using longs as well.

Alternatively, you could build your own floating point library, using
longs as the mantissa.

DaveA

 

[Peter Pearson]

Traceback (most recent call last):

16.137254901960784

Does this still work if y = 765 * 10**1000 + 1 ? It looks
as if it might rely on x and y having a large common divisor.

(I blush to confess that my Python has no fractions module,
and it's too early in the morning to risk trying to update
anything.)

 

[Jussi Piitulainen]

Traceback (most recent call last):

16.137254901960784

Logarithms agree to 13 decimal digits or so:
16.13725490196353

 

[Peter Otten]

Does this still work if y = 765 * 10**1000 + 1 ? It looks
as if it might rely on x and y having a large common divisor.

You mean something like this?
1.0

But my D'oh!* moment really was seeing Jerry Hill doing it with
1.0

Peter

(*) I'm having a lot of these lately. Looks like I need a new brain.

 

[Victor Eijkhout]

0.5

Beautiful. Thanks so much guys.

Victor.

 

[Mensanator]

I have two long ints, both too long to convert to float, but their ratio
is something reasonable. How can I compute that? The obvious "(1.*x)/y"
does not work.

You could try using the gmpy module. It supports arbitrary precision
floats, so converting long to float is no problem.

YY = 3**10684
float(YY)
Traceback (most recent call last)
File "pyshell#78>", line 1, in <module>
float(YY)
OverflowError: Python int too large to convert to C double

import gmpy
gmpy.mpf(YY)
mpf('3.6600365709...0197681e5097',16936)

 

[Victor Eijkhout]

You could try using the gmpy module. It supports arbitrary precision
floats, so converting long to float is no problem.

I fear I may actually have to go symbolic. I'm now having to use the
12th root of 2, and I would like the twelfth power of that to be exactly
2.

Victor.

 

[Paul Rubin]

I have two long ints, both too long to convert to float, but their ratio
is something reasonable. How can I compute that? The obvious "(1.*x)/y"
does not work.

The math.log function has a special hack for long ints, that might help:

Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47) 2.9999999999994813

 

[Mark Dickinson]

Beautiful. Thanks so much guys.

And if for some reason you don't want to use the 'from __future__'
import, then you can do long1.__truediv__(long2):
1.0

If you care about speed at all, I'd avoid the Fractions solution; it
does an expensive and slow gcd computation.