headers
Nils Wagner | 2 Mar 09:51
Picon
Favicon

sandbox packages maskedarray and timeseries

Hi all,

I have enabled the sandbox packages maskedarray and timeseries.

The file

enabled_packages.txt

in /scipy/Lib/sandbox contains

delaunay
pyem
numexpr
arpack
spline
rbf
maskedarray
timeseries

If I try to import maskedarray and timeseries I get

Python 2.4 (#1, Oct 13 2006, 16:43:49)
[GCC 3.3.5 20050117 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy.sandbox import maskedarray
>>> from scipy.sandbox import timeseries
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib64/python2.4/site-packages/scipy/sandbox/timeseries/__init__.py",
(Continue reading)

Permalink | Reply | 501 comments |
headers
Pierre GM | 2 Mar 18:27
Picon

Re: sandbox packages maskedarray and timeseries

On Friday 02 March 2007 03:51:00 Nils Wagner wrote:
> Hi all,
>
> I have enabled the sandbox packages maskedarray and timeseries.

Wow, thanks a lot. We didn't even make a proper annoucement on timeseries 
yet ! (We want to have the week-end to check for some bugs first...)

> How can I fix this problem ?

Mmh. I don't know, I never tried to install the package with Scipy. You could 
try to install maskedarray first, and then... *finishes his coffee and 
realizes that's not the question*. Oh:

I guess it's a namespace problem. 
timeseries.tcore tries to find maskedarray, when in fact only 
scipy.sandbox.maskedarray is available in the namespace.

Could you try something like
from scipy.sandbox import maskedarray as maskedarray 
?

I've never tried this approach, I always have maskedarray and timeseries 
directly in my PYTHONPATH and everything works fine (of course, except for 
the bugs in the modules themselves, but we're working on that...)

Let me know how it goes.
Permalink | Reply | 501 comments |
headers
John Hunter | 4 Mar 22:53
Picon
Gravatar

bug in scipy.stats.norm.cdf ?

I was surprised by the nans in the cdf output below; ditto for the
survival function which is probably using the same code (svn scipy
compiled for OS X panther python2.3)

In [1]: import scipy

In [2]: import scipy.stats

In [3]: scipy.__version__
Out[3]: '0.5.3.dev2818'

In [4]: distribution = scipy.stats.norm(loc=0, scale=1)

In [5]: x = scipy.arange(-3,3,0.1)

In [6]: distribution.cdf(x)
Out[6]:
array([ 0.0013499 ,  0.00186581,  0.00255513,  0.00346697,  0.00466119,
               nan,  0.00819754,  0.01072411,  0.01390345,  0.01786442,
               nan,  0.02871656,  0.03593032,  0.04456546,  0.05479929,
               nan,  0.08075666,  0.09680048,  0.11506967,  0.13566606,
               nan,  0.18406013,  0.2118554 ,  0.24196365,  0.27425312,
               nan,  0.34457826,  0.38208858,  0.42074029,  0.46017216,
        0.5       ,  0.53982784,  0.57925971,  0.61791142,  0.65542174,
        0.69146246,  0.72574688,  0.75803635,  0.7881446 ,  0.81593987,
        0.84134475,  0.86433394,  0.88493033,  0.90319952,  0.91924334,
        0.9331928 ,  0.94520071,  0.95543454,  0.96406968,  0.97128344,
        0.97724987,  0.98213558,  0.98609655,  0.98927589,  0.99180246,
        0.99379033,  0.99533881,  0.99653303,  0.99744487,  0.99813419])
(Continue reading)

Permalink | Reply | 14 comments |
headers
John Hunter | 4 Mar 23:27
Picon
Gravatar

Re: bug in scipy.stats.norm.cdf ?

On 3/4/07, John Hunter <jdh2358 <at> gmail.com> wrote:
> I was surprised by the nans in the cdf output below; ditto for the
> survival function which is probably using the same code (svn scipy
> compiled for OS X panther python2.3)

In case this helps one of the scipy gurus -- I've narrowed the bug to
scipy.special_cephes.erf but haven't been able to narrow it further.
I wonder if this is related to a platform specific nan test....  Do
others see this?

In [20]: import scipy.special._cephes as c

In [21]: x = scipy.arange(-3, -2, 0.1)

In [22]: x
Out[22]: array([-3. , -2.9, -2.8, -2.7, -2.6, -2.5, -2.4, -2.3, -2.2, -2.1])

In [23]: c.erf(x)
Out[23]:
array([-0.99997791, -0.9999589 , -0.99992499, -0.99986567, -0.99976397,
               nan, -0.99931149, -0.99885682, -0.99813715, -0.99702053])

In [24]: x[5]
Out[24]: -2.5

In [25]: c.erf(x[5])
Out[25]: nan

In [26]: c.erf(float(x[5]))
Out[26]: nan
(Continue reading)

Permalink | Reply | 13 comments |
headers
eric jones | 4 Mar 23:39

Re: bug in scipy.stats.norm.cdf ?

It looks like it works with latest install of Python -- Enthought 
Edition on WinXP.  This is python 2.4.3.

In [81]: from scipy.special import _cephes as c

In [83]: a
Out[83]: array([-3. , -2.9, -2.8, -2.7, -2.6, -2.5, -2.4, -2.3, -2.2, -2.1])

In [85]: c.erf(a)
Out[85]:
array([-0.99997791, -0.9999589 , -0.99992499, -0.99986567, -0.99976397,
       -0.99959305, -0.99931149, -0.99885682, -0.99813715, -0.99702053])

In [86]: import scipy
In [87]: scipy.__version__
Out[87]: '0.5.3.dev2749'

In [88]: import numpy
In [89]: numpy.__version__
Out[89]: '1.0.2.dev3552'

John Hunter wrote:
> On 3/4/07, John Hunter <jdh2358 <at> gmail.com> wrote:
>   
>> I was surprised by the nans in the cdf output below; ditto for the
>> survival function which is probably using the same code (svn scipy
>> compiled for OS X panther python2.3)
>>     
>
> In case this helps one of the scipy gurus -- I've narrowed the bug to
(Continue reading)

Permalink | Reply | 12 comments |
headers
Fernando Perez | 4 Mar 23:53
Picon
Gravatar

Re: bug in scipy.stats.norm.cdf ?

On 3/4/07, eric jones <eric <at> enthought.com> wrote:
> It looks like it works with latest install of Python -- Enthought
> Edition on WinXP.  This is python 2.4.3.

Looks OK here too:

In [8]: c.erf(x)
Out[8]:
array([-0.99997791, -0.9999589 , -0.99992499, -0.99986567, -0.99976397,
       -0.99959305, -0.99931149, -0.99885682, -0.99813715, -0.99702053])

In [9]: x[5]
Out[9]: -2.5

In [10]: c.erf(x[5])
Out[10]: -0.999593047983

In [11]: c.erf(-2.5)
Out[11]: -0.999593047983

In [12]: import numpy

In [13]: numpy.__version__
Out[13]: '1.0.2.dev3569'

In [14]: scipy.__version__
Out[14]: '0.5.3.dev2819'

Ubuntu Edgy on x86, built from SVN right this minute.  GCC is 4.1.2.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Auger | 5 Mar 00:00
Picon

Re: bug in scipy.stats.norm.cdf ?

Three more data points: works fine for me on i686, x86_64, and my intel
mac with scipy 0.5.3.dev2774 and numpy 1.0.2.dev3552.
Permalink | Reply | 0 comments |
headers
John Hunter | 5 Mar 00:36
Picon
Gravatar

Re: bug in scipy.stats.norm.cdf ?

On 3/4/07, eric jones <eric <at> enthought.com> wrote:
> It looks like it works with latest install of Python -- Enthought
> Edition on WinXP.  This is python 2.4.3.
>
> In [81]: from scipy.special import _cephes as c
>

Yep, it's an isnan bug.  If I add a dummy function "erfjdh" to ndtr.c
and _cephesmodule.c

double erfjdh(double x)
{
  double y, z;
  if (isnan(x)) {
    mtherr("erf", DOMAIN);
    return -2.0;
  }
  return 2.0;
}

and then run my test code

In [1]: import scipy

In [2]: import scipy.special._cephes as c

In [3]: x = scipy.arange(-3, -2, 0.1)

In [4]: c.erfjdh(x)
Out[4]: array([ 2.,  2.,  2.,  2.,  2., -2.,  2.,  2.,  2.,  2.])
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Hunter | 5 Mar 01:08
Picon
Gravatar

Re: bug in scipy.stats.norm.cdf ?

On 3/4/07, John Hunter <jdh2358 <at> gmail.com> wrote:

> Yep, it's an isnan bug.  If I add a dummy function "erfjdh" to ndtr.c
> and _cephesmodule.c

latest update: the ndtr.c module is using cephes_isnan defined in
cephes/isnan.c.  With some experimenting, it appears I am falling into
the "size(int)==4 and  #ifdef IBMPC" branch of that function, when I
should be in the "size(int)==4 and  #ifdef MIEEE" branch as far as I
can determine.

If I manually define MIEEE in isnan.h, I avoid the unwanted isnans.
Looking at mconf.h where these macros are defined, it looks like I am
not hitting the branch

#elif defined(sel) || defined(pyr) || defined(mc68000) || defined (m68k) || \
          defined(is68k) || defined(tahoe) || defined(ibm032) || \
          defined(ibm370) || defined(MIPSEB) || defined(_MIPSEB) || \
          defined(__convex__) || defined(DGUX) || defined(hppa) || \
          defined(apollo) || defined(_CRAY) || defined(__hppa) || \
          defined(__hp9000) || defined(__hp9000s300) || \
          defined(__hp9000s700) || defined(__AIX) || defined(_AIX) ||\
          defined(__pyr__) || defined(__mc68000__) || defined(__sparc) ||\
          defined(_IBMR2) || defined (BIT_ZERO_ON_LEFT)
#define MIEEE 1     /* Motorola IEEE, high order words come first */
#define BIGENDIAN 1

Is there some additional "defined" check  that needs to be added here?
 Are other mac power pc users seeing this problem?
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Hunter | 5 Mar 02:05
Picon
Gravatar

Re: bug in scipy.stats.norm.cdf ?

On 3/4/07, eric jones <eric <at> enthought.com> wrote:
> It looks like it works with latest install of Python -- Enthought
> Edition on WinXP.  This is python 2.4.3.
> In [87]: scipy.__version__
> Out[87]: '0.5.3.dev2749'

Hey Eric,

On the enthought python download page
http://code.enthought.com/enthon/, the scipy version is listed as
"SciPy 0.5.0.2033: Scientific Library for Python" but you are showing
a much more recent version.  The code I am using in scipy.stats was
broken in one of the 0.5.0.* branches I was testing on, so I want to
make sure my students, who are mainly win32, are getting the latest
packages.  I was planning on pointing them to the enthought edition;
is there a pointer to a development or testing release, or is the
version number on the main page out of date?

Thanks,
JDH
Permalink | Reply | 6 comments |

Gmane