[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