# [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.
```