mirror of https://github.com/python/cpython
96685bfbf0
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). |
||
|---|---|---|
| .. | ||
| .cvsignore | ||
| abstract.c | ||
| bufferobject.c | ||
| cellobject.c | ||
| classobject.c | ||
| cobject.c | ||
| complexobject.c | ||
| descrobject.c | ||
| dictobject.c | ||
| fileobject.c | ||
| floatobject.c | ||
| frameobject.c | ||
| funcobject.c | ||
| intobject.c | ||
| iterobject.c | ||
| listobject.c | ||
| longobject.c | ||
| methodobject.c | ||
| moduleobject.c | ||
| object.c | ||
| obmalloc.c | ||
| rangeobject.c | ||
| sliceobject.c | ||
| stringobject.c | ||
| tupleobject.c | ||
| typeobject.c | ||
| unicodectype.c | ||
| unicodeobject.c | ||
| unicodetype_db.h | ||
| xxobject.c | ||