On Aug 23, 2006, at 3:29 PM, Thomas Wouters wrote:
>
> Since Alex isn't on python-dev, forwarding this for his convenience
> (he said he wanted to reply.)
Thanks! I _am_ on Python-Dev (otherwise couldn't read what you're
forwarding here), but not on Python-Checkins (where the discussion
was started).
> Tim also replied to his checkin, but I didn't forward that message.
Yep, saw that (thanks Brett) -- if I read him right, Tim was
basically suggesting better ways to check for infinity rather than
saying it's better to keep today's inconsistency (he can surely
correct me if I misread). Tim is of course right, but PEP 754 (the
fpconst module) would appear to be the right way to perform the
checking, anyway.
> I don't think this can be right. The returnvalue of pow() in the
> case of ERANGE isn't defined anywhere that I can find, at least.
> How can we assume it is +Infinity? As I tried to say over the
> visiphone, you can't even use compile-
That's how I read ISO/IEC 9899:1999 7.12.1.4 , which is describing
C's <math> functions in general:
"""
If a floating result overflows and default rounding is in effect, or
if the mathematical result is an exact infinity (for example log
(0.0)), then the function returns the value of the macro HUGE_VAL,
HUGE_VALF, or HUGE_VALL according to the return type, with the same
sign as the correct value of the function;
"""
etc.
Yes, that's a C language standard that's just 7 years old, rather
than the 16-years-old standard Python can "definitely" count on; but
we could presumably test (and rely on) __STDC_IEC_559__ if we need
features in Appendix F, or just on __STDC_VERSION__ being defined and
>= 199901L for more generic parts of the standard (such as the part
I was quoting above from chapter 7). People who build Python with C
compilers not meeting these macro criteria but still "good enough" to
afford a minimally functional implementation of IEEE 754 floats might
run configure with some appropriate -with-whatever options to assert
the fact, if needed (i.e., if either because of C 1990 Standard
language, or realworld brokenness of important compilers, automatic
tests are in fact unreliable).
And PEP 754 (and thus fpconst, or some other way for Python code to
tell if it's running on a minimally functional implementation of IEEE
754 floats, and if so test for and generate NaNs and infinities)
should also be there so that the Python-coded unittests can properly
decide whether to test for compliance.
> time or startup-time checks for the behaviour because 'undefined'
> also means it need not be consistent, either. The
Yes, but the behavior is not undefined in standard C (1999 standard;
I don't have access to the 1990 standard)
> best we could do, if we really wanted to return +inf instead of
> raising OverflowError (which I don't, but don't really care about
> either), is generate +Infinity in some guaranteed way. I'm sure Tim
> can come up with a convenient, portable way < 0.9 wink>.
The macro Py_HUGE_VAL seems to be the documented way to do it. And
while I'd rather uniformly get infinity from operations producing
infinity, what I'm really keen to avoid is having one such operation
raise an exception while another one succeeds.
> But I'd prefer to keep it the way it was: x*x and x**2 don't always
> do the same thing. Floats have a lot more confusing features like
> that, such as 10*x - 9*x need not be x. I don't see the added value
> of trying to make it consistent in just this case, even if it's
> portable.
There's a huge conceptual gap between, on one side, two values
produced by "roughly equivalent" expressions being only *ALMOST*
equal rather than strictly equal, and one of the expressions raising
an exception while the other one happily proceeds. The former case
is reasonably easy to handle -- that's why we have an
assertAlmostEqual method in unittest.TestCase; the latter can be a
nightmare.
The same goes for the other bug I recently added to the tracker, the
""" x != y and [x] == [y] """ one. Of course, according to this
"more confusing features" philosophy, I guess it can be considered
quite OK to leave in Python absurdities like this one, as well. I
abhor that whle "slippery slope" philosophy ("there's a tiny
unavoidable problem in this corner so it's OK to leave a huge gaping
hole all over the place") but I see no way to resolve such
philosophical conflict without BDFL pronouncement. So, I have
reverted r51525; I now believe it can't be done right (with proper
unittests) without PEP 754 or something like that, anyway.
Alex
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
