NaN handling

**Grant Edwards** · May 3 '06, 05:35 PM

Re: NaN handling

On 2006-05-03, Andy McDonagh <andymcdonagh@e arthlink.net> wrote:[color=blue]
> Dear python experts,
>
> I am new to python and this site, so I apologize if this is off topic (i.e. is it a SciPy question?). I will try to demonstrate my problem below:
> --------------------------------------------------------
> #!/usr/local/bin/python
>
> from scipy import *
> from scipy.stats import *
> a=norm(loc=0,sc ale=1)
> a_data = a.rvs(10)
>
> problem = zeros(10)
> print problem
>
> h_x1_x2 = -sum(problem * log2(a_data))
>
> print h_x1_x2
> #NaN
> ----------------------------------------------------------
>
> I need a way of handling NaNs[/color]

NaNs are handled.

Apparently they aren't handled the way you want them to be?
[color=blue]
> for example R has the 'na.omit' option. Does anybody know if
> this exists?[/color]

It would help if you explain how you want NaNs handled, but I
don't recall that tehre are any "options" for handling NaNs
other than the default way in scipy.

--
Grant Edwards grante Yow! It's NO USE... I've
at gone to "CLUB MED"!!
visi.com

**Ivan Vinogradov** · May 5 '06, 08:55 PM

Re: NaN handling

[color=blue]
> <snip>
> NaNs are handled.[/color]

Throwing an exception would be nice in regular Python (non-scipy).

This works to catch NaN on OSX and Linux:

# assuming x is a number
if x+1==x or x!=x:
#x is NaN

But is expensive as a precautionary measure.
Assert can be used for testing, if production code can be run with -0
or -OO.

**Grant Edwards** · May 5 '06, 09:05 PM

Re: NaN handling

On 2006-05-05, Ivan Vinogradov <vinogri@mcmast er.ca> wrote:[color=blue]
>[color=green]
>> <snip>
>> NaNs are handled.[/color]
>
> Throwing an exception would be nice in regular Python (non-scipy).[/color]

That would break most of my Python programs (at least most of
the ones in which I do floating point). My main problem with
NaNs (and Infs) is that there isn't a string represention that
is consistent across platforms.
[color=blue]
> This works to catch NaN on OSX and Linux:
>
> # assuming x is a number
> if x+1==x or x!=x:
> #x is NaN
>
> But is expensive as a precautionary measure. Assert can be
> used for testing, if production code can be run with -0 or
> -OO.[/color]

There are those of us that need NaNs in production code, so it
would have to be something that could be configured. I find
that in my programs the places where I need to do something
"exceptiona l" with a NaN are very limited. The vast majority
of the time, I need them to propagate quietly.

--
Grant Edwards grante Yow! Thousands of days of
at civilians... have produced
visi.com a... feeling for the
aesthetic modules --

**Ivan Vinogradov** · May 5 '06, 10:15 PM

Re: NaN handling

> <snip>[color=blue]
> There are those of us that need NaNs in production code, so it
> would have to be something that could be configured. I find
> that in my programs the places where I need to do something
> "exceptiona l" with a NaN are very limited. The vast majority
> of the time, I need them to propagate quietly.[/color]

Our programming expectations may differ, but an option to catch NaNs as
an exception is a great idea.

Regards, Ivan.

**Robert Kern** · May 5 '06, 10:35 PM

Re: NaN handling

Ivan Vinogradov wrote:[color=blue][color=green]
>><snip>
>>There are those of us that need NaNs in production code, so it
>>would have to be something that could be configured. I find
>>that in my programs the places where I need to do something
>>"exceptiona l" with a NaN are very limited. The vast majority
>>of the time, I need them to propagate quietly.[/color]
>
> Our programming expectations may differ, but an option to catch NaNs as
> an exception is a great idea.[/color]

numpy lets the programmer control how NaNs are handled in numpy code. Producing
a NaN can be ignored, create a warning, raise an exception or call a function.
It's not well documented at the moment, but the functions are seterr(),
seterrcall(), seterrobj(), geterr(), geterrcall(), and geterrobj().

Pure Python has a similar, but somewhat less flexible method, on UNIX platforms.

Page not found — Python 3.15.0a8 documentation

http://docs.python.org/dev/lib/module-fpectl.html

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

**Grant Edwards** · May 5 '06, 10:45 PM

Re: NaN handling

On 2006-05-05, Ivan Vinogradov <vinogri@mcmast er.ca> wrote:[color=blue][color=green]
>> <snip>
>> There are those of us that need NaNs in production code, so it
>> would have to be something that could be configured. I find
>> that in my programs the places where I need to do something
>> "exceptiona l" with a NaN are very limited. The vast majority
>> of the time, I need them to propagate quietly.[/color]
>
> Our programming expectations may differ, but an option to
> catch NaNs as an exception is a great idea.[/color]

Unless it's done in hardware, it would be hopelessly slow.
There some platforms where it's possible for an application to
enable and handle FP interrupts (all of the exampls for that
seem to be in Fortran). I don't know if the common platforms
(IA32/MS-Windows, IA32/Linux) even have that ability.

--
Grant Edwards grante Yow! I'm into SOFTWARE!
at
visi.com

**Grant Edwards** · May 5 '06, 10:55 PM

Re: NaN handling

On 2006-05-05, Robert Kern <robert.kern@gm ail.com> wrote:
[color=blue][color=green]
>> Our programming expectations may differ, but an option to catch NaNs as
>> an exception is a great idea.[/color]
>[/color]
[...]
[color=blue]
> Pure Python has a similar, but somewhat less flexible method, on UNIX platforms.
>
> http://docs.python.org/dev/lib/module-fpectl.html[/color]

For which "Unix" platforms? It's not there under Linux:

Python 2.4.2 (#1, Feb 14 2006, 07:55:13)
[GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> import fpectl[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named fpectl[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

--
Grant Edwards grante Yow! Do I hear th'
at SPINNING of various
visi.com WHIRRING, ROUND, and WARM
WHIRLOMATICS?!

**Robert Kern** · May 5 '06, 11:15 PM

Re: NaN handling

Grant Edwards wrote:[color=blue]
> On 2006-05-05, Robert Kern <robert.kern@gm ail.com> wrote:[/color]
[color=blue][color=green]
>>Pure Python has a similar, but somewhat less flexible method, on UNIX platforms.
>>
>> http://docs.python.org/dev/lib/module-fpectl.html[/color]
>
> For which "Unix" platforms? It's not there under Linux:
>
> Python 2.4.2 (#1, Feb 14 2006, 07:55:13)
> [GCC 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)] on linux2
> Type "help", "copyright" , "credits" or "license" for more information.
>[color=green][color=darkred]
>>>>import fpectl[/color][/color]
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> ImportError: No module named fpectl[/color]

You might have to enable it during the Python build process.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

**Ivan Vinogradov** · May 5 '06, 11:55 PM

Re: NaN handling

On 5-May-06, at 6:45 PM, Grant Edwards wrote:
[color=blue]
> On 2006-05-05, Robert Kern <robert.kern@gm ail.com> wrote:
>[color=green][color=darkred]
>>> Our programming expectations may differ, but an option to catch
>>> NaNs as
>>> an exception is a great idea.[/color]
>>[/color]
> [...]
>[color=green]
>> Pure Python has a similar, but somewhat less flexible method, on
>> UNIX platforms.
>>
>> http://docs.python.org/dev/lib/module-fpectl.html[/color]
>
> For which "Unix" platforms? It's not there under Linux:[/color]
<snip>

It doesn't seem to be here under OSX either (universal Python install).

Since numpy seems to be working on a variety of platforms/hardware,
how hard would it be to extract this functionality from it to add to
Python proper?

Cheers, Ivan.

**Robert Kern** · May 6 '06, 02:05 AM

Re: NaN handling

Ivan Vinogradov wrote:
[color=blue]
> It doesn't seem to be here under OSX either (universal Python install).[/color]

It's not enabled by default. In the source distribution, it is
Modules/fpectlmodule.c .
[color=blue]
> Since numpy seems to be working on a variety of platforms/hardware,
> how hard would it be to extract this functionality from it to add to
> Python proper?[/color]

Harder than just enabling fpectl.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

**Dan Bishop** · May 6 '06, 08:45 AM

Re: NaN handling

Ivan Vinogradov wrote:[color=blue][color=green]
> > <snip>
> > NaNs are handled.[/color]
>
> Throwing an exception would be nice in regular Python (non-scipy).
>
> This works to catch NaN on OSX and Linux:
>
> # assuming x is a number
> if x+1==x or x!=x:
> #x is NaN[/color]

x != x works, but:
[color=blue][color=green][color=darkred]
>>> x = 1e100
>>> x + 1 == x[/color][/color][/color]
True

**Alexander Schmolck** · May 6 '06, 12:55 PM

Re: NaN handling

Robert Kern <robert.kern@gm ail.com> writes:
[color=blue]
> Ivan Vinogradov wrote:
>[color=green]
> > It doesn't seem to be here under OSX either (universal Python install).[/color]
>
> It's not enabled by default. In the source distribution, it is
> Modules/fpectlmodule.c .
>[color=green]
> > Since numpy seems to be working on a variety of platforms/hardware,
> > how hard would it be to extract this functionality from it to add to
> > Python proper?[/color]
>
> Harder than just enabling fpectl.[/color]

Last thing I heard fpectl was considered to be completely broken -- it's
likely not disabled by default for no reason. A short google turned up this:

Comment By: Michael Hudson (mwh)
Date: 2006-02-20 12:59

Message:
Logged In: YES
user_id=6656

Waaa, the correct thing to is to remove the --with-fpectl from configure!
I've
been meaning to post to python-dev for a while now proposing the ripping out
of this code. It's just not useful any more. At any rate, I am actively
opposed to
advertising its existence more widely.

And in pep 356 (python 2.5 release schedule) we find:

Possible features for 2.5
[...]
- Remove the fpectl module?

So "just enabling fpectl" doesn't look like a viable long term solution.

'as

**Felipe Almeida Lessa** · May 6 '06, 03:45 PM

Re: NaN handling

Em Sex, 2006-05-05 Ã s 16:37 -0400, Ivan Vinogradov escreveu:[color=blue]
> This works to catch NaN on OSX and Linux:
>
> # assuming x is a number
> if x+1==x or x!=x:
> #x is NaN[/color]

This works everywhere:

nan = float('nan')

..
..
..

if x == nan:
# x is not a number

--
Felipe.

**Alexander Schmolck** · May 6 '06, 03:45 PM

Re: NaN handling

Felipe Almeida Lessa <felipe.lessa@g mail.com> writes:
[color=blue]
> Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu:[color=green]
> > This works to catch NaN on OSX and Linux:
> >
> > # assuming x is a number
> > if x+1==x or x!=x:
> > #x is NaN[/color]
>
> This works everywhere:
>
> nan = float('nan')
>
> .
> .
> .
>
> if x == nan:
> # x is not a number[/color]

No it doesn't.

'as