summaryrefslogtreecommitdiffstats
path: root/configure
diff options
context:
space:
mode:
authorTim Peters <tim.peters@gmail.com>2001-08-23 22:31:37 (GMT)
committerTim Peters <tim.peters@gmail.com>2001-08-23 22:31:37 (GMT)
commit96685bfbf0e954febd4f873721d3db5d03cb2d99 (patch)
treed138d923949eb1d81530c828a1b604c9500a591c /configure
parent29a62dd6ebe48c4a5c7b4f7d6f0e8589d94a5a0d (diff)
downloadcpython-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