NaN handling

[Terry Reedy]

Re: NaN handling


"Felipe Almeida Lessa" <felipe.lessa@g mail.com> wrote in message
news:1146929327 .30335.5.camel@ kenshin.CASA...[color=blue]
> This works everywhere:
>
> nan = float('nan')[/color]

Not.
[color=blue][color=green][color=darkred]
>>> nan = float('nan')[/color][/color][/color]

Traceback (most recent call last):
File "<pyshell#4 >", line 1, in -toplevel-
nan = float('nan')
ValueError: invalid literal for float(): nan

Above is Windows, which requires something else.

tjr

[Ryan Forsythe]

Re: NaN handling

Terry Reedy wrote:[color=blue]
> "Felipe Almeida Lessa" <felipe.lessa@g mail.com> wrote in message
> news:1146929327 .30335.5.camel@ kenshin.CASA...[color=green]
>> This works everywhere:
>>
>> nan = float('nan')[/color]
>
> Not.
>[color=green][color=darkred]
>>>> nan = float('nan')[/color][/color]
>
> Traceback (most recent call last):
> File "<pyshell#4 >", line 1, in -toplevel-
> nan = float('nan')
> ValueError: invalid literal for float(): nan
>
> Above is Windows, which requires something else.[/color]

I think he meant:
[color=blue][color=green][color=darkred]
>>> float("NaN")[/color][/color][/color]
nan

That's Python 2.4.1 on Mac OS X.

[Terry Reedy]

Re: NaN handling


"Ryan Forsythe" <ryanf@cs.uoreg on.edu> wrote in message
news:445CD5E3.1 070600@cs.uoreg on.edu...[color=blue]
> Terry Reedy wrote:[color=green]
>> "Felipe Almeida Lessa" <felipe.lessa@g mail.com> wrote in message
>> news:1146929327 .30335.5.camel@ kenshin.CASA...[color=darkred]
>>> This works everywhere:
>>>
>>> nan = float('nan')[/color]
>>
>> Not.
>>[color=darkred]
>>>>> nan = float('nan')[/color]
>>
>> Traceback (most recent call last):
>> File "<pyshell#4 >", line 1, in -toplevel-
>> nan = float('nan')
>> ValueError: invalid literal for float(): nan
>>
>> Above is Windows, which requires something else.[/color]
>
> I think he meant:
>[color=green][color=darkred]
> >>> float("NaN")[/color][/color]
> nan
>
> That's Python 2.4.1 on Mac OS X.[/color]
[color=blue][color=green][color=darkred]
>>> float("NaN")[/color][/color][/color]

Traceback (most recent call last):
File "<pyshell#5 >", line 1, in -toplevel-
float("NaN")
ValueError: invalid literal for float(): NaN

As Tim Peters has said often enough, this sort of thing is specific to the
underlying C library and will remain so until someone cares enough to write
or fund a cross-platform solution.

Terry Jan Reedy

[Robert Kern]

Re: NaN handling

Felipe Almeida Lessa wrote:[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')[/color]

Have you tried it on Windows?

--
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

[Robert Kern]

Re: NaN handling

Alexander Schmolck wrote:[color=blue]
> Robert Kern <robert.kern@gm ail.com> writes:[color=green]
>>Ivan Vinogradov wrote:[/color][/color]
[color=blue][color=green][color=darkred]
>>>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.[/color]

Fair enough. If you want to go through numpy's code to rip out its floating
point error handling, knock yourself out. It's not going to be trivial, though.
It's heavily embedded in the ufunc machinery.

--
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]

Re: NaN handling

On 2006-05-06, Robert Kern <robert.kern@gm ail.com> wrote:
[color=blue][color=green][color=darkred]
>>>>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?
>>>
>>>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.[/color]
>
> Fair enough. If you want to go through numpy's code to rip out its floating
> point error handling, knock yourself out. It's not going to be trivial, though.
> It's heavily embedded in the ufunc machinery.[/color]

Does numpy's NaN handling only work within numpy functions, or
does it enable HW FP signals and then catch them for "normal"
floating point operations that take place outside of numpy code?

--
Grant Edwards grante Yow! I'm in direct contact
at with many advanced fun
visi.com CONCEPTS.

[Grant Edwards]

Re: NaN handling

On 2006-05-06, Terry Reedy <tjreedy@udel.e du> wrote:
[color=blue][color=green]
>> That's Python 2.4.1 on Mac OS X.[/color]
>[color=green][color=darkred]
>>>> float("NaN")[/color][/color]
>
> Traceback (most recent call last):
> File "<pyshell#5 >", line 1, in -toplevel-
> float("NaN")
> ValueError: invalid literal for float(): NaN
>
> As Tim Peters has said often enough, this sort of thing is specific to the
> underlying C library and will remain so until someone cares enough to write
> or fund a cross-platform solution.[/color]

Yea, that's a royal PITA. I had to add my own code into the
"pickle" classes to handle NaNs. Having a pickler that only
works for a subset of the legal IEEE FP values proved to be
sort of useless.

--
Grant Edwards grante Yow! Were these parsnips
at CORRECTLY MARINATED in
visi.com TACO SAUCE?

[Robert Kern]

Re: NaN handling

Grant Edwards wrote:[color=blue]
> On 2006-05-06, Robert Kern <robert.kern@gm ail.com> wrote:
>[color=green][color=darkred]
>>>>>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?
>>>>
>>>>Harder than just enabling fpectl.
>>>
>>>Last thing I heard fpectl was considered to be completely broken -- it's
>>>likely not disabled by default for no reason.[/color]
>>
>>Fair enough. If you want to go through numpy's code to rip out its floating
>>point error handling, knock yourself out. It's not going to be trivial, though.
>>It's heavily embedded in the ufunc machinery.[/color]
>
> Does numpy's NaN handling only work within numpy functions, or
> does it enable HW FP signals and then catch them for "normal"
> floating point operations that take place outside of numpy code?[/color]

Just in numpy code, it seems.

In [1]: import numpy
i
In [2]: import math

In [3]: numpy.seterr(in valid='raise')
Out[3]: {'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under':
'ignore'}

In [4]: numpy.log(-1.0)
---------------------------------------------------------------------------
exceptions.Floa tingPointError Traceback (most recent call
last)

/Users/kern/<ipython console>

FloatingPointEr ror: invalid encountered in log

In [5]: math.log(-1.0)
Out[5]: nan

--
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