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/