Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> One related issue is testing these, how can a NaN and +/-Infinity
> float object be created in Python?
In 2.6 and 3.0 (but not 2.5 and older), float('nan'), float('inf') and
float('-inf') should all work reliably across platforms (or at least
those platforms that support infs and nans). If they don't it's a bug.
> (2) On your 2nd comment, supporting non-IEEE floating point, perhaps
> the Kahan method should be used in that case. If so, the next
> question is how to detect that?
Actually, I think you could probably just leave the algorithm exactly as
it is, but put a warning in the documentation that the exactness only
applies in the presence of IEEE 754 semantics. Practically everybody's
on an IEEE 754 platform anyway.
> There are two symbols in pyconfig.h HAVE_IEEEFP_H and
> HAVE_LIBIEEE. Are those the proper ones to determine IEEE floating
> point support?
I'm not sure that either of these is the right thing. Neither is
defined on my MacBook, for example.
> (3) On the 3rd comment, Raymond and I did discus using a single
> function to be called by the math and cmath modules.
I think you're right that it's easier to just duplicate the code.
It's a nice feature that this function only has to pass once through the
data, and it doesn't seem worth losing that to save a little bit of code
duplication.
I still wonder whether there's a way to avoid incorrectly signaling
overflow in the case where the result is finite. (e.g. sum([1e308,
1e308, -1e308])).
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2819>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
