I think a problem occured when i used long()

[Ali]

I did the folloing in python shell:
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

 

[Jorge Godoy]

I did the folloing in python shell:

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? ;-)


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,

 

[Grant Edwards]

I did the folloing in python shell:

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?

 

[Jeff Epler]

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

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

Jeff

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

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

 

[Paul Rubin]

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.

 

[Porky Pig Jr]

I did the folloing in python shell:

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.

 

[Dan Bishop]

I did the folloing in python shell:

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.
0L

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

Perhaps you meant 5.07e+25, which doesn't.
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.

 

[Paul Rubin]

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.

 

[Porky Pig Jr]

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*.

 

[Andrew Dalke]

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/Constants/Table/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
(e-mail address removed)