Tim Peters added the comment:
Mark, thanks for the counterexample! I think I can fairly accuse you of
thinking ;-)
I expect the same approach would be zippy for scaling x by 2**e, provided that
the scaled value doesn't exceed the dynamic range of the decimal context. Like
so:
def erootn(x, e, n,
D=decimal.Decimal,
D2=decimal.Decimal(2),
pow=c.power,
sub=c.subtract,
div=c.divide):
g = x**(1.0/n) * 2.0**(e/n) # force e to float for Python 2?
Dg = D(g)
return g - float(sub(Dg, div(D(x)*D2**e, pow(Dg, n-1)))) / n
The multiple errors in the native-float-precision starting guess shouldn't
hurt. In this case D(x)*D2**e may not exactly equal the scaled input either,
but the error(s) are "way at the end" of the extended-precision decimal format.
I don't know the range of `e` you have to worry about. On my box,
decimal.MAX_EMAX == 999999999999999999 ... but the docs say that on a 32-bit
box it's "only" 425000000. If forcing the context Emax to that isn't enough,
then your code is still graceful but this other approach would need to get
uglier.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27761>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
