By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,733 Members | 930 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,733 IT Pros & Developers. It's quick & easy.

I think a problem occured when i used long()

P: n/a
Ali
I did the folloing in python shell:
x = 5.07e-25
x = long(x)
print x

0L

Um... I was under the impresion that long numbers had very very long
precision. But, it seems that in this case it rounded it to zero :(

Please Help. Thank you :)
Jul 18 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
al**********@hotmail.com (Ali) writes:
I did the folloing in python shell:
x = 5.07e-25
x = long(x)
print x 0L

Um... I was under the impresion that long numbers had very very long
precision. But, it seems that in this case it rounded it to zero :(

Please Help. Thank you :)


Isn't "long" a long integer? ;-)

help(long)


class long(object)
| long(x[, base]) -> integer
|
| Convert a string or number to a long integer, if possible. A floating
| point argument will be truncated towards zero (this does not include a
| string representation of a floating point number!) When converting a
| string, use the optional base. It is an error to supply a base when
| converting a non-string.

(...)
So, converting a float to an integer should really truncate the result,
as is in the documentation.
Sds,
--
Godoy. <go***@ieee.org>
Jul 18 '05 #2

P: n/a
On 2004-09-01, Ali <al**********@hotmail.com> wrote:
I did the folloing in python shell:
x = 5.07e-25
x = long(x)
print x

0L

Um... I was under the impresion that long numbers had very very long
precision. But, it seems that in this case it rounded it to zero :(

Please Help. Thank you :)


Um... what did you expect the integer value of 5.07e-25 to be?

--
Grant Edwards grante Yow! .. I see TOILET
at SEATS...
visi.com
Jul 18 '05 #3

P: n/a
"long" only represents integers, not numbers with a fractional part.
long(f) when f is a float discards the fraction.
long(-.999) 0L long(.999) 0L

The Decimal module, which will be in 2.4, can exactly represent numbers
with decimal fractions.
decimal.Decimal("5.07e-25") Decimal("5.07E-25") 5.07e-25 + 1 - 1 0.0 decimal.Decimal("5.07e-25") + 1 - 1

Decimal("5.07E-25")

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBNistJd01MZaTXX0RAq2VAJ9BSWxS2jznfFSP/PNsUBd0kgCeOACfemR3
eXbJUbV8a0gDGj+oK7SdTew=
=yzNl
-----END PGP SIGNATURE-----

Jul 18 '05 #4

P: n/a
al**********@hotmail.com (Ali) writes:
x = 5.07e-25
x = long(x)
print x

0L

Um... I was under the impresion that long numbers had very very long
precision. But, it seems that in this case it rounded it to zero :(


Longs are arbitrary precision integers.
Jul 18 '05 #5

P: n/a
al**********@hotmail.com (Ali) wrote in message news:<8f*************************@posting.google.c om>...
I did the folloing in python shell:
x = 5.07e-25
x = long(x)
print x

0L

Um... I was under the impresion that long numbers had very very long
precision. But, it seems that in this case it rounded it to zero :(

Please Help. Thank you :)

Long numbers are still integers. in any case, python floating point is
C double (rather than float), most likely 64 bits with 53 bits for
precision.

Incidently, I remember seeing the thread somewhere re whether we need
128bit floating representation (with similarly adjusted number of bits
for precision) and the general consensus was that the double covers
pretty much all the bases.
Jul 18 '05 #6

P: n/a
al**********@hotmail.com (Ali) wrote in message news:<8f*************************@posting.google.c om>...
I did the folloing in python shell:
x = 5.07e-25
x = long(x)
print x 0L

Um... I was under the impresion that long numbers had very very long
precision. But, it seems that in this case it rounded it to zero :(


"long" numbers are indeed unbounded, but they're only for integers;
fractions get truncated.
long(1.001) 1L long(0.999) 0L

5.07e-25 is between 0 and 1, so it gets rounded to zero.

Perhaps you meant 5.07e+25, which doesn't.
long(5.07e+25)

50699999999999999203082240L

(The "noise" digits at the end are there because the original float
value is stored with only 53 significant bits.)

Or perhaps you really do want high-precision fractional values. You
*can* use long for this, by scaling your data so it's an integer. For
example, instead of storing an amount as $1.99, store it as 199 cents
(and remember the scaling by 100). For greater fractional precision,
use higher scaling factors.

The "decimal" class in Python 2.4 will take care of this behind the
scenes.
Jul 18 '05 #7

P: n/a
po**********@my-deja.com (Porky Pig Jr) writes:
Incidently, I remember seeing the thread somewhere re whether we need
128bit floating representation (with similarly adjusted number of bits
for precision) and the general consensus was that the double covers
pretty much all the bases.


The x86 supports 80 bit extended floats and I hope Python has a way to
use them (maybe with a build option).

I'd had the impression that some of the PowerPC processors support 128
bit floats, but I'm not sure of that. And it may be limited to IBM
workstation processors, not Macs.
Jul 18 '05 #8

P: n/a
Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

The x86 supports 80 bit extended floats and I hope Python has a way to
use them (maybe with a build option).

Very interesting. Probably special C directive (unless something like
'extended float' is some kind of C (unofficial) standard. I'll check
x86 architecture reference.

Incidently, if I recall, the arguments against 'very high precision'
was coming from scientists (e.g. those dealing with quantum mechanics
issues) rather than from programmers. The main argument was that the
measuring tools' precision is soo well below 53bit precision available
as 'C double' that using anything higher than that will mistakenly
create the impression of 'very high precision of the experiment' - but
this is just it - *mistakenly*.

I'd had the impression that some of the PowerPC processors support 128
bit floats, but I'm not sure of that. And it may be limited to IBM
workstation processors, not Macs.

Jul 18 '05 #9

P: n/a
Porky Pig Jr wrote:
Incidently, if I recall, the arguments against 'very high precision'
was coming from scientists (e.g. those dealing with quantum mechanics
issues) rather than from programmers. The main argument was that the
measuring tools' precision is soo well below 53bit precision available
as 'C double' that using anything higher than that will mistakenly
create the impression of 'very high precision of the experiment' - but
this is just it - *mistakenly*.


Out of curiosity, I looked for the physical constant
with the most precisely measured value. It looks
to be the electron magn. moment to Bohr magneton ratio
http://physics.nist.gov/cuu/Constant...e/allascii.txt
which is
-1.001 159 652 1859 with error of 0.000 000 000 0038

That's 1 part in 10**13. So there are a few things
which need that sort of precision.

(53 bits is about 1 part in 10**16. 10**13 needs only
43 bits.)

I also think GIS systems need enough precision so that
single isn't good enough for large maps. 23 bits for
a 32 bit float gives about a 4m resolution while 53
bits gives about a nm resolution.

I did molecular mechanics, not QM, but I don't recall
the QM people complaining about this issue.
Andrew
da***@dalkescientific.com
Jul 18 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.