[Scipy-tickets] [SciPy] #731: Strange subclassing behavior for `UnivariateSpline`

SciPy scipy-tickets@scipy....
Mon Sep 1 06:55:52 CDT 2008


#731: Strange subclassing behavior for `UnivariateSpline`
-------------------------------+--------------------------------------------
 Reporter:  jguyer             |       Owner:  somebody
     Type:  defect             |      Status:  new     
 Priority:  normal             |   Milestone:  0.7.0   
Component:  scipy.interpolate  |     Version:          
 Severity:  normal             |    Keywords:          
-------------------------------+--------------------------------------------
 I've encountered some very strange behavior with `UnivariateSpline`. If I
 run the code
 {{{
 #!python
 from scipy.interpolate import UnivariateSpline
 from numpy import log, exp, arange, pi

 class DerivedSpline(UnivariateSpline):
     def __init__(self, x, y):

         UnivariateSpline.__init__(self, x=x, y=y)

     def __call__(self, x, nu=None):
         return 10**UnivariateSpline.__call__(self, x=x, nu=nu)


 x = arange(0, 10, 0.1)

 s1 = DerivedSpline(x, x)
 s2 = DerivedSpline(x, 10**x)
 s3 = DerivedSpline(x, 10**(x/10.))

 print "s1", s1(2.)
 print "s2", s2(2.)
 print "s3", s3(2.)
 }}}
 I get back
 {{{
 s1 [ 2.]
 s2 [  4.34894242e+99]
 s3 [ 1.60608541]
 }}}

 I would expect
 {{{
 s1 = 10**2 = 100
 s2 = 10**10**2 = 1e100
 s3 = 10**10**0.2 = 38.4
 }}}
 so only s2 is reasonable.

 This seems to happen because the different range (or different
 "flattness"?) of values causes the s1 and s3 objects to be defined
 differently from the the s2 object:
 {{{
 #!python
 >>> numpy.source(s1.__call__)
 In file: /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
 /site-packages/scipy/interpolate/fitpack2.py

     def __call__(self, x, nu=None):
         """ Evaluate spline (or its nu-th derivative) at positions x.
         Note: x can be unordered but the evaluation is more efficient
         if x is (partially) ordered.

         """
         if nu is None:
             return dfitpack.splev(*(self._eval_args+(x,)))
         return dfitpack.splder(nu=nu,*(self._eval_args+(x,)))

 >>> numpy.source(s2.__call__)
 In file: splinebug.py

     def __call__(self, x, nu=None):
         return 10**UnivariateSpline.__call__(self, x=x, nu=nu)

 >>> numpy.source(s3.__call__)
 In file: /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
 /site-packages/scipy/interpolate/fitpack2.py

     def __call__(self, x, nu=None):
         """ Evaluate spline (or its nu-th derivative) at positions x.
         Note: x can be unordered but the evaluation is more efficient
         if x is (partially) ordered.

         """
         if nu is None:
             return dfitpack.splev(*(self._eval_args+(x,)))
         return dfitpack.splder(nu=nu,*(self._eval_args+(x,)))
 }}}

 s1, s2 and s3 are all instances of `DerivedSpline`. How can they have
 different methods?


 I've seen this behavior both with SciPy 0.7.0.dev4200 on a Leopard Mac and
 with 0.6.0 on a Debian etch machine.

 (For anybody wondering why I would want to do any of this in the first
 place, I've got optical absorption data that drops precipitously from
 10**6 cm**-1 to 10 cm**-1 over a few tens of nanometers in wavelength. It
 seemed to me that I would capture this shoulder more faithfully if I
 splined the log of the data, but I ultimately need absorption, not
 log(absorption))

-- 
Ticket URL: <http://scipy.org/scipy/scipy/ticket/731>
SciPy <http://www.scipy.org/>
SciPy is open-source software for mathematics, science, and engineering.


More information about the Scipy-tickets mailing list