Bug in Decimal??
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Tue Apr 29 23:39:12 EDT 2014
On Tue, 29 Apr 2014 19:37:17 -0700, pleasedontspam wrote:
> from decimal import *
> getcontext().prec=2016
> one=Decimal(1)
> number=Decimal('1e-1007')
> partial=(one+number)/(one-number)
> final.ln()
What's final? Did you mean partial?
When I try it in Python 3.3, I get:
py> from decimal import *
py> getcontext().prec=2016
py> one = Decimal(1)
py> number = Decimal('1e-1007')
py> partial = (one+number)/(one-number)
py> partial.ln()
Decimal('1.9999[...]9999987E-1007')
with a lot of 9s deleted for brevity.
> The result should be 2.00000... with all zeroes and 7 at the end.
Can you demonstrate exactly how you tested it on Wolfram-Alpha, because I
cannot reproduce that. When I try it with ln((1+1e-1007)/(1-1e-1007)),
the decimal expansion shown starts off as:
2.00000000000000000000000000000000000000000000000000000... × 10^-1007
By repeatedly clicking "More digits", I get:
2.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000...
× 10^-1007
For brevity, I will truncate some repeated digits from this point on.
1.99999999999999999[...]999999999999999999999999999999999999999999999...
× 10^-1007
as above, except with even more nines (477 of them if I have calculated
correctly)
2.00000000000000000[...]0000000000000000000000000000000000000000000000...
× 10^-1007
as above, with even more zeroes
and finally the last available approximation is
2.000000[...]000000666666[...]666666... × 10^-1007
with a lot of zeroes and sixes not shown. But not ending in 7.
> Instead, I'm getting 1.999999.. with 2 digits different at the end.
Well, it's hard to say exactly what's going on, since Wolfram Alpha
doesn't show the context, but it looks like Python's version may agree
with two out of the seven decimal approximations Alpha makes available.
This suggests to me that it's a representation issue.
[...]
> Can other people confirm this or is it just my imagination? I tested
> with python 2.7.5 in XUbuntu, and also with my own build of mpdecimal
> 2.4.0 (latest, built from source). I compared the results with wolfram
> Alpha, and also with an open source arbitrary precision calculator,
> which matches Alpha results.
I think it's worth raising a ticket for it on the bug tracker.
I think it would help if you can provide a link or instructions to how to
replicate this in Alpha, also give the name and version number of the
arbitrary precision calculator you used. Anything that can be used to
replicate your results.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
More information about the Python-list
mailing list