diff options
author | Tim Peters <tim.peters@gmail.com> | 2001-08-23 22:31:37 (GMT) |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2001-08-23 22:31:37 (GMT) |
commit | 96685bfbf0e954febd4f873721d3db5d03cb2d99 (patch) | |
tree | d138d923949eb1d81530c828a1b604c9500a591c /configure | |
parent | 29a62dd6ebe48c4a5c7b4f7d6f0e8589d94a5a0d (diff) | |
download | cpython-96685bfbf0e954febd4f873721d3db5d03cb2d99.zip cpython-96685bfbf0e954febd4f873721d3db5d03cb2d99.tar.gz cpython-96685bfbf0e954febd4f873721d3db5d03cb2d99.tar.bz2 |
float_pow: Put *all* of the burden on the libm pow in normal
cases.
powu: Deleted.
This started with a nonsensical error msg:
>>> x = -1.
>>> import sys
>>> x**(-sys.maxint-1L)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: negative number cannot be raised to a fractional power
>>>
The special-casing in float_pow was simply wrong in this case (there's
not even anything peculiar about these inputs), and I don't see any point
to it in *any* case: a decent libm pow should have worst-case error under
1 ULP, so in particular should deliver the exact result whenever the exact
result is representable (else its error is at least 1 ULP). Thus our
special fiddling for integral values "shouldn't" buy anything in accuracy,
and, to the contrary, repeated multiplication is less accurate than a
decent pow when the true result isn't exactly representable. So just
letting pow() do its job here (we may not be able to trust libm x-platform
in exceptional cases, but these are normal cases).
Diffstat (limited to 'configure')
0 files changed, 0 insertions, 0 deletions