Re: NaN handling

2006-05-06 Thread Robert Kern
py'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. > > Does numpy's NaN handling only work within numpy functions, or > does it enable HW

Re: NaN handling

2006-05-06 Thread Grant Edwards
On 2006-05-06, Terry Reedy <[EMAIL PROTECTED]> wrote: >> That's Python 2.4.1 on Mac OS X. > float("NaN") > > Traceback (most recent call last): > File "", line 1, in -toplevel- > float("NaN") > ValueError: invalid literal for float(): NaN > > As Tim Peters has said often enough, this so

Re: NaN handling

2006-05-06 Thread Grant Edwards
knock yourself out. It's not going to be trivial, > though. > It's heavily embedded in the ufunc machinery. 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 opera

Re: NaN handling

2006-05-06 Thread Robert Kern
Alexander Schmolck wrote: > Robert Kern <[EMAIL PROTECTED]> writes: >>Ivan Vinogradov wrote: >>>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. >

Re: NaN handling

2006-05-06 Thread Robert Kern
Felipe Almeida Lessa wrote: > Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu: > >>This works to catch NaN on OSX and Linux: >> >># assuming x is a number >>if x+1==x or x!=x: >> #x is NaN > > This works everywhere: > > nan = float('nan') Have you tried it on Windows? -- Robe

Re: NaN handling

2006-05-06 Thread Terry Reedy
"Ryan Forsythe" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Terry Reedy wrote: >> "Felipe Almeida Lessa" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> This works everywhere: >>> >>> nan = float('nan') >> >> Not. >> > nan = float('nan') >> >> Traceback (m

Re: NaN handling

2006-05-06 Thread Ryan Forsythe
Terry Reedy wrote: > "Felipe Almeida Lessa" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> This works everywhere: >> >> nan = float('nan') > > Not. > nan = float('nan') > > Traceback (most recent call last): > File "", line 1, in -toplevel- > nan = float('nan') > Va

Re: NaN handling

2006-05-06 Thread Terry Reedy
"Felipe Almeida Lessa" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > This works everywhere: > > nan = float('nan') Not. >>> nan = float('nan') Traceback (most recent call last): File "", line 1, in -toplevel- nan = float('nan') ValueError: invalid literal for float(): nan

Re: NaN handling

2006-05-06 Thread Alexander Schmolck
Felipe Almeida Lessa <[EMAIL PROTECTED]> writes: > Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu: > > This works to catch NaN on OSX and Linux: > > > > # assuming x is a number > > if x+1==x or x!=x: > > #x is NaN > > This works everywhere: > > nan = float('nan') > > . > . >

Re: NaN handling

2006-05-06 Thread Felipe Almeida Lessa
Em Sex, 2006-05-05 às 16:37 -0400, Ivan Vinogradov escreveu: > This works to catch NaN on OSX and Linux: > > # assuming x is a number > if x+1==x or x!=x: > #x is NaN This works everywhere: nan = float('nan') . . . if x == nan: # x is not a number -- Felipe. -- http://mail.python

Re: NaN handling

2006-05-06 Thread Alexander Schmolck
Robert Kern <[EMAIL PROTECTED]> writes: > Ivan Vinogradov wrote: > > > It doesn't seem to be here under OSX either (universal Python install). > > It's not enabled by default. In the source distribution, it is > Modules/fpectlmodule.c . > > > Since numpy seems to be working on a variety of plat

Re: NaN handling

2006-05-06 Thread Dan Bishop
Ivan Vinogradov wrote: > > > > NaNs are handled. > > 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 x != x works, but: >>> x = 1e100 >>> x + 1 == x True -- http

Re: NaN handling

2006-05-05 Thread Robert Kern
Ivan Vinogradov wrote: > It doesn't seem to be here under OSX either (universal Python install). It's not enabled by default. In the source distribution, it is Modules/fpectlmodule.c . > Since numpy seems to be working on a variety of platforms/hardware, > how hard would it be to extract this fu

Re: NaN handling

2006-05-05 Thread Ivan Vinogradov
On 5-May-06, at 6:45 PM, Grant Edwards wrote: > On 2006-05-05, Robert Kern <[EMAIL PROTECTED]> wrote: > >>> Our programming expectations may differ, but an option to catch >>> NaNs as >>> an exception is a great idea. >> > [...] > >> Pure Python has a similar, but somewhat less flexible method,

Re: NaN handling

2006-05-05 Thread Robert Kern
Grant Edwards wrote: > On 2006-05-05, Robert Kern <[EMAIL PROTECTED]> wrote: >>Pure Python has a similar, but somewhat less flexible method, on UNIX >>platforms. >> >> http://docs.python.org/dev/lib/module-fpectl.html > > For which "Unix" platforms? It's not there under Linux: > > Python 2.4.

Re: NaN handling

2006-05-05 Thread Grant Edwards
On 2006-05-05, Robert Kern <[EMAIL PROTECTED]> wrote: >> Our programming expectations may differ, but an option to catch NaNs as >> an exception is a great idea. > [...] > Pure Python has a similar, but somewhat less flexible method, on UNIX > platforms. > > http://docs.python.org/dev/lib/modu

Re: NaN handling

2006-05-05 Thread Grant Edwards
On 2006-05-05, Ivan Vinogradov <[EMAIL PROTECTED]> wrote: >> >> 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 >> "exceptional" with a NaN are very limited

Re: NaN handling

2006-05-05 Thread Robert Kern
Ivan Vinogradov wrote: >> >>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 >>"exceptional" with a NaN are very limited. The vast majority >>of the time, I ne

Re: NaN handling

2006-05-05 Thread Ivan Vinogradov
> > 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 > "exceptional" with a NaN are very limited. The vast majority > of the time, I need them to propagate qu

Re: NaN handling

2006-05-05 Thread Grant Edwards
On 2006-05-05, Ivan Vinogradov <[EMAIL PROTECTED]> wrote: > >> >> NaNs are handled. > > Throwing an exception would be nice in regular Python (non-scipy). 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

Re: NaN handling

2006-05-05 Thread Ivan Vinogradov
> > NaNs are handled. 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

Re: NaN handling

2006-05-03 Thread Grant Edwards
On 2006-05-03, Andy McDonagh <[EMAIL PROTECTED]> wrote: > 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

Re: NaN handling

2006-05-03 Thread Robert Kern
Andy McDonagh wrote: > 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

NaN handling

2006-05-03 Thread Andy McDonagh
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=