On 2008-02-15, Carl Banks <[EMAIL PROTECTED]> wrote:
>> For Python, I'd suggest throwing a Python exception on all
>> errors recognized by the FPU, except maybe underflow. If
>> you're doing such serious number-crunching that you really
>> want to handle NANs, you're probably not writing in Python
>> anyway.
>
> Even if that were entirely true, there are cases where (for
> example) you're using Python to glue together numerical
> routines in C, but you need to do some preliminary
> calculations in Python (where there's no edit/compile/run
> cycle but there is slicing and array ops), but want the same
> floating point behavior.
Or when you're verifying/testing algorithms implemented on
another platform that follows the IEEE standard.
Or when propagating quiet NaNs and Infinities is by far the
simplest way to do what needs to be done. Being able to feed
NaN values into a set of calculations and have outputs
dependant on invalid inputs turn out to be NaNs is just _so_
much simpler than either
1) Having a complete set of boolean logic code in parallel to
the calculations that keeps track of what's valid and
what's not.
2) Writing a floating point class with some sort of "valid
flag" that travels along with the values.
> IEEE conformance is not an unreasonable thing to ask for,
Especially when the hardware already provides it (or at least
provides something close enough to satisfy most of us who
whinge about such things).
> and "you should be using something else" isn't a good answer
> to "why not?".
even for Usenet. ;)
--
Grant Edwards grante Yow! A shapely CATHOLIC
at SCHOOLGIRL is FIDGETING
visi.com inside my costume..
--
http://mail.python.org/mailman/listinfo/python-list
