[Scipy-tickets] [SciPy] #325: scipy.special.erf erroneously returns nan on Mac OS X for certain inputs
SciPy
scipy-tickets at scipy.net
Thu Nov 30 11:38:37 CST 2006
#325: scipy.special.erf erroneously returns nan on Mac OS X for certain inputs
---------------------------+------------------------------------------------
Reporter: jwanders | Owner: somebody
Type: defect | Status: new
Priority: normal | Milestone:
Component: scipy.special | Version:
Severity: major | Resolution:
Keywords: |
---------------------------+------------------------------------------------
Old description:
> The scipy.special.erf function erroneously returns NaN on Mac OS X for
> certain inputs.
>
> Test system specs:
> OS: Mac OS X 10.4.5
> python: 2.4.3
> gcc: 4.0.1
> scipy: 0.5.2.dev2095
> numpy: 1.0.dev3334
>
> Example code:
>
> {{{
> >>> from scipy.special import erf
> >>> erf(1)
> 0.84270079294971478 # Correct
> >>> erf(.999999999)
> 0.84270079253460728 # Correct
> >>> erf(.9999999999)
> nan # Incorrect
> }}}
>
> This problem was briefly discussed on the scipy.user mailing list in
> January of 2006 The hypothesis and possible fixes quoted below were
> suggested:
>
> >>On OS X, /usr/include/math.h defines an erf() function that is probably
> getting >>picked up instead of Cephes's version.
> >
> >We've seen this type of problem before, with round(). Cephes really
> should use a >namespace (cephes_erf() instead of plain erf(), for
> instance).
> >
> >The least-intrusive patch would be a header with things like #define erf
> cephes_erf >then when linking the cephes version will be pulled in.
> >
> >I've also just noticed that we're using an older version of Cephes
> (release 2.3, >Jan. 1995) compared with one on netlib (release 2.9, Nov.
> 2000).
New description:
The scipy.special.erf function erroneously returns NaN on Mac OS X for
certain inputs.
{{{
Test system specs:
OS: Mac OS X 10.4.5
python: 2.4.3
gcc: 4.0.1
scipy: 0.5.2.dev2095
numpy: 1.0.dev3334
}}}
Example code:
{{{
>>> from scipy.special import erf
>>> erf(1)
0.84270079294971478 # Correct
>>> erf(.999999999)
0.84270079253460728 # Correct
>>> erf(.9999999999)
nan # Incorrect
}}}
This problem was briefly discussed on the scipy.user mailing list in
January of 2006 The hypothesis and possible fixes quoted below were
suggested:
{{{
>>On OS X, /usr/include/math.h defines an erf() function that is probably
getting >>picked up instead of Cephes's version.
>
>We've seen this type of problem before, with round(). Cephes really
should use a >namespace (cephes_erf() instead of plain erf(), for
instance).
>
>The least-intrusive patch would be a header with things like #define erf
cephes_erf >then when linking the cephes version will be pulled in.
>
>I've also just noticed that we're using an older version of Cephes
(release 2.3, >Jan. 1995) compared with one on netlib (release 2.9, Nov.
2000).
}}}
Comment (by rkern):
Well, it works for me on OS X 10.4 (Intel), Python 2.5, and scipy
0.5.2.dev2329. Can you use nm(1) to determine if cephes_erf is actually
linked into _cephes.so?
That fix that you mention was also implemented in January.
--
Ticket URL: <http://projects.scipy.org/scipy/scipy/ticket/325#comment:3>
SciPy <http://www.scipy.org/>
SciPy is open-source software for mathematics, science, and engineering.
More information about the Scipy-tickets
mailing list