[SciPy-dev] Possible PPC float bug with special.ndtr

[Tom Loredo]

Hi folks-

A bit of code misbehaved with my first test case in a bewildering
manner.  I was coding on a PPC; it seems the test failure may be
due to a bug on PPC, as the code works fine on OS X Intel and
Linux Intel.

It boils down to this simple example.  Here is the (expected)
behavior on both Intel platforms:

In [1]: from scipy.special import ndtr

In [2]: ndtr(1.)
Out[2]: 0.841344746069

In [3]: arg=(1.2-1.)/.2

In [4]: arg
Out[4]: 0.99999999999999978

In [5]: ndtr(arg)
Out[5]: 0.841344746069

Here is the (unexpected) behavior on PPC (OS X, Python 2.4.4,
numpy 1.0.3.1, scipy 0.5.2.1):

In [1]: from scipy.special import ndtr

In [2]: ndtr(1.)
Out[2]: 0.841344746069

In [3]: arg = (1.2-1.)/.2

In [4]: arg
Out[4]: 0.99999999999999978

In [5]: ndtr(arg)
Out[5]: nan

In [6]: ndtr(arg+1.e-16)
Out[6]: nan

In [7]: ndtr(arg+2.e-16)
Out[7]: 0.841344746069

In [8]: ndtr(arg-1.e-10)
Out[8]: nan

In [9]: ndtr(arg-1.e-9)
Out[9]: 0.841344745827

I.e, there is a sliver of arguments near 1.0 where ndtr (or perhaps
erf or erfc, which it relies on) misbehaves (giving nan), but only 
on PPC.

Anyone else see this on PPC?  Should I submit this to Trac, or is it 
something already dealt with?  I took a peek at ndtr.c, but it's not
obvious what might be going on.  It looks like various constants
get defined in an architecture-dependent manner, and perhaps an
inaccurate definition is underlying this problem.

Thanks,
Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/