Jason wrote:
> Please note that NaN's are very funky and platform dependent. They
> depend on their underlying platform's C library for creation and
> display. On windows, "float('nan')" will cause an exception, as there
> are no valid string representations of NAN that can be converted to
> the special floating point value. Also, if you manage to create a nan
> under Windows, it displays as "1.#QNAN".
>
> Infinite values are also problematic. In almost all cases, it is far
> better to avoid infinite and NaN values.
CC to Python Dev
I've fixed that and enhanced the support for NaN and inf for 2.6 and
3.0. I'm working together with Mark on more NaN and inf related fixes
and he has fixed some numerical issues in the cmath module. We both hope
to get Python's math more sound and stable across platforms.
So far I got float('nan'), float('inf') and float('-inf') working on all
platforms. The math module got three new methods: isinf, isnan, copysign.
Additionally the trunk-math branch contains code for inverse hyberbolic
functions (acosh), log1p, Mark's fixes for complex math and more stuff.
For example operations on NaNs now return a NaN on all platforms (except
1**NAN which is defined as 1 and 0**NAN which is defined as 0). In 2.5
it depends on the platform whether a function raises an exception or
returns NaN.
Mark had the nice idea to introduce a thread local or global flag for
NaN support. Depending on a flag Python turns a NaN into an exception.
The feature needs a proper PEP. Maybe Mark has time to write a PEP in time.
Christian
--
http://mail.python.org/mailman/listinfo/python-list
