Does Python have a long floating data type please?

David C. Ullrich ullrich at math.okstate.edu
Fri Mar 31 11:40:24 EST 2000


    Another slight problem is it's not really all that accurate all the
time. I believe the problems have to do with the "consistent handling
of 0", whatever that means - it's possible an earlier version worked
better. There are definite problems:

    The guy says that he doesn't guarantee the most accurate possible
results, but the digits you do get are guaranteed correct. Consider
this:

>>> x=r(0,10)
>>> x
.00000000000+-3
>>> x*x
0.+-1e12

    Note the "e12" - there's no minus sign. What this says is that if
x is something between -0.00000000003 and 0.00000000003
then x*x is between -1000000000000 and 1000000000000.
This is not a lie, so in _some_ sense it's not a bug, but it seems
we should be able to pin down the value of x*x a little bit
more precisely than that. (It's not hard to hack out a fix for
this. Or what appears to be a fix - I don't know the rest of the
module well enough to be certain that what I did has no
deleterious effects elsewhere.)

    The problem is ok with a higher-precision 0. But "don't
use low-precision 0's" is not an answer - it could well be
that some calculation that reduces precision _returns_ a
low-precision 0 value, and modifying the routine to give
a higher-precision result could render it unusable. (The
problem arose in exactly that situation - took me the
longest time to figure out what was going wrong...)

    Anyway, the above is not a "bug" in some formal sense,
since the author just claims to be telling no lies, not to be
telling the whole truth. But here's a lie:

>>> x=Real(1,0)
>>> x
1.+-1
>>> 1/x
2.+-2

    We have x.mant=1 and x.expon=0; this means that x is
a number between 0 and 2. So 1/x should be a "possible
zero divide" error! The above says "If x is between 0 and
2 then 1/x is between 0 and 4", and that's simply not so.

    There should be a "possible zero division" error any
time we divide by a real with mant=-1, 0, or 1; the
module only raises the exception when mant=0.
I thought about just changing that one line, but I
decided that given that it's lying here I'm really not
going to trust what it says if I "fix" it anyway - at
this point I decided to give up on real.py and make
my own.

Martin von Loewis wrote:

> "Fredrik Lundh" <effbot at telia.com> writes:
>
> > this page might help:
> > http://www.python.org/topics/scicomp/numbercrunching.html
>
> Looking at it, I'd think the link titled "Real Number manipulation
> Tools" would be especially helpful, however, it points to
>
> ftp://ftp.python.org/pub/python/contrib/Math/real-accurate.pyar
>
> which does not exist. Instead, it is now in
>
> ftp://ftp.python.org/pub/python/contrib-09-Dec-1999/DataStructures/real-accurate.pyar
>
> Regards,
> Martin




More information about the Python-list mailing list