commited changes that I originally submitted for scipy.signal.cspline…

[anielsen001]

…1d_eval cannot return complex results (Trac #1260) #1787. The bspline interpolator can produce complex results, but will only work correctly if the output uses complex values.

I originally made the trac ticket mentioned above. I have the changes implemented in this pull request.

The basic issue is that the bspline interpolator can produce correct complex results, but must use complex coefficients. In order for this to work, the zeros_like function has to be changed because in the case of a complex interpolator the bspline interpolation coefficients are complex while input x-values that are interpolated to may be real. (The zeros_like function operators on the x-values that are interpolated to.)

[larsoner]

It would be better to have a space between the arguments here and below

[person142]

Also zeros_like takes a dtype argument, so that could be

res = zeros_like(newx, dtype=cj.dtype)

[anielsen001]

Those are both good suggestions. It appears that zeros_like is a better choice since zeros here because it will attempt to keep the same memory layout as the original which could be more efficient. I made both changes on my fork.

[larsoner]

You'll also need to add a test that fails on master but passes on this PR. It can be very simple.

[anielsen001]

I added an example of the error and the result with my changes at this gist:
https://gist.github.com/anielsen001/7b1f7686bd3cb9697eedb3b2824d2807

It's clunky test requiring commenting and uncommenting lines. However, the crucial fact can be seen. Without there is a warning about losing the imaginary part and the resulting interpolated values have zero imaging part. After my suggested change the interpolated values retain their imaginary part and reflect the original data.

[larsoner]

Can you add a simple test to this PR? Some trivial case is fine as long as it shows the bug properly

[anielsen001]

This code block raises a ValueError on the scipy master and does not with my suggested patch. There is also a ComplexWarning issued that the imaginary part has been discarded on the scipy master. I was not sure what format is required for the test (will it become some part of an automatic system?) so if there is a template I should follow please point me toward that.

#!/usr/bin/env python

from scipy.signal import cspline1d
from scipy.signal import cspline1d_eval
#from bspline_change import cspline1d_eval

from numpy import *

from matplotlib.pylab import *

# create some smoothly varying complex signal to try and interpolate
x=arange(100)
y=zeros(x.shape,dtype=complex64)
T=10.0
f=1.0/T
y=sin(2.0*pi*f*x)+1.0J*cos(2.0*pi*f*x)

# get the cspline transform
cy=cspline1d(y)

# determine some xvalues to interpolate
xnew=arange(1.0,10.0,0.001)
ynew=cspline1d_eval(cy,xnew)

if (ynew.imag==0).all():
    raise ValueError,'scipy.signal.cspline1d_eval does not support complex numbers'

[person142]

@anielsen001 the test would go in

https://github.com/scipy/scipy/blob/master/scipy/signal/tests/test_signaltools.py#L641

That way the test will run as part of the CI build. You can also run all the signal tests locally with python runtests.py -s signal from the top-level scipy directory. I might rewrite the test a bit to be something like:

def test_complex():
    x = np.arange(100)
    T=10.0
    f=1.0/T
    y = np.exp(2.0*np.pi*f*x)
    cy = signal.cspline1d(y)

    xnew = np.arange(1.0, 10.0, 0.001)
    ynew = signal.cspline1d_eval(cy, xnew)

    assert_(np.any(ynew.imag != 0))

Warning: didn't test this code.

[anielsen001]

Thank you for the instructions and example. I created a test_complex() function and tested it locally; runs as I expect so I pushed the changes to my fork.

[person142]

BTW you can check the pep8 stuff locally by installing pep8 (pip install pep8) and running pep8 scipy from the top-level directory. (Apologies if you already knew that.)

[person142]

Doing y = np.exp(2j*np.pi*f*x) should achieve the same thing. (Mathematically it's off by a factor of -i and a complex conjugation.)

[anielsen001]

You're correct. When I originally wrote the test I was trying to verify what was going on with pure real or complex terms so I wrote it up to easily add/remove the imaginary terms.

For the test purposes it does not matter what the input data is, as long as it comes across as complex before the interpolation.

The test code also computes many more values than are necessary to perform the test. I could cut down the test to save computation if that is seen as important.

[larsoner]

+1 for using complex exponential instead of cos + sin

[larsoner]

Also, yes please cut down on the number of points. For a big library like this, cutting test time is important.

[anielsen001]

Thank you, I didn't know about using pep8 myself. I installed and ran my own checks.

[larsoner]

@anielsen001 looks good to me except for my last couple of comments. After making those changes, can you squash your commits? Then we should be good to merge.

[anielsen001]

Thank you for all the comments. I switched to the complex exponential form and the test now uses just a single point which is all that's needed to test for complex value generation.

I learned to squash which was very handy to know.

[larsoner]

Thanks @anielsen001. Anybody else want to have a look? If not, I'll go ahead and merge in a few days. @anielsen001 feel free to ping me if I forget.

[anielsen001]

@Eric89GXL and @person142 Thank you for your comments and assistance. I'll be glad to provide anything else if needed.

[ev-br]

thanks @anielsen001 @Eric89GXL @person142