scipy.signal.filter_design.butter fails

[dk]

First, an apology: I am not sure I'm doing this entirely correctly.

Commands typed
==============

from scipy.signal.filter_design import *
butter(2,0.5)

Result
=====

An error (traceback given below).

Expected result
============

The expected output was a list of coefficients for the moving-average
and recursive parts of a Butterworth digital filter.

System
======
Mac OSX running Sage Version 3.2.3, Release Date:
2009-01-05 |

Traceback
========

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/kelley/.sage/sage_notebook/worksheets/admin/7/code/
10.py",
line 7, in <module>
butter(_sage_const_2 ,_sage_const_0p5 )
File "/Applications/sage/local/lib/python2.5/site-packages/
SQLAlchemy-0.4.6-py2.5.egg/",
line 1, in <module>

File "/Applications/sage/local/lib/python2.5/site-packages/scipy/
signal/filter_design.py",
line 482, in butter
return iirfilter(N, Wn, btype=btype, analog=analog, output=output,
ftype='butter')
File "/Applications/sage/local/lib/python2.5/site-packages/scipy/
signal/filter_design.py",
line 434, in iirfilter
z, p, k = typefunc(N)
File "/Applications/sage/local/lib/python2.5/site-packages/scipy/
signal/filter_design.py",
line 957, in buttap
p = numpy.exp(1j*(2*n-1)/(2.0*N)*pi)*1j
AttributeError: exp

[Mike Hansen]

Hi Dan,

On Sun, Feb 8, 2009 at 2:17 PM, dk <Dan.K...@dal.ca> wrote:
>
> First, an apology: I am not sure I'm doing this entirely correctly.
>
> Commands typed
> ==============
>
> from scipy.signal.filter_design import *
> butter(2,0.5)
>
> Result
> =====
>
> An error (traceback given below).

This problem is caused by the fact that numpy and scipy don't play
totally nicely with Sage's types. There are a couple ways around
this. First, you could use the 'r' suffix to tell Sage not to use its
data types for these numbers.

sage: from scipy.signal.filter_design import *
sage: butter(2r,0.5r)

(array([ 0.29289322, 0.58578644, 0.29289322]),
array([ 1.00000000e+00, -1.95106077e-16, 1.71572875e-01]))
sage: type(2)
<type 'sage.rings.integer.Integer'>
sage: type(2r)
<type 'int'>
sage: type(0.5)
<type 'sage.rings.real_mpfr.RealLiteral'>
sage: type(0.5r)
<type 'float'>

Or you could turn the preparser off:

sage: preparser(False)
sage: butter(2,0.5)
(array([ 0.29289322, 0.58578644, 0.29289322]),
array([ 1.00000000e+00, -1.95106077e-16, 1.71572875e-01]))

I think it'd be a good project to see what would have to be done to
make numpy and scipy work with the Sage data types.

--Mike

[mabshoff]

On Feb 8, 2:17 pm, dk <Dan.Kel...@Dal.Ca> wrote:

Hi,

> First, an apology: I am not sure I'm doing this entirely correctly.

Nah, this sounds about right, in case it is above average. For some
reason it seems that the moderation system the groups have is racy
since this email showed up twice :)

We are running the last official release (indeed, we run some svn
release after that), but it is way out of date compared to scipy
0.7.rc2. The plan is to update to that in the near future, but so far
every time we tried something else got in the way.

It might be nice to try this in pure python and with scipy 0.7.rc2 and
in case this is supposed to work and still broken complain to the
scipy folks and open a ticket in their tracker. Until then we should
open a ticket in Sage's trac so we add a doctest that verifies this
works (assuming it is a bug :) once we update to scipy 0.7.

Cheers,

Michael

[dk]

Thanks, this

sage: from scipy.signal.filter_design import *
sage: butter(2r,0.5r)

works beautifully. I really appreciate the help provided (within
moments!) on this list.

PS. the reason I'm doing this in sage and not in scipy itself is that
I can't build scipy on my machine (OSX 10.5 powerPC), and binaries are
not supplied for this architecture. Numpy builds without problems,
though.

-- Dan

[mabshoff]

On Feb 8, 2:38 pm, dk <Dan.Kel...@Dal.Ca> wrote:

Hi Dan,

If you want "just" python + scipy + numpy you can run

./sage -python

and then you won't have to deal with the pesky preparser in Sage :)

Obviously there are many fun things in Sage besides scipy, so feel
free to explore all that code, too.

It is also possible to build Sage in 64 bit mode on OSX 10.5, but that
isn't officially supported yet since not all doctests pass.

> -- Dan

Cheers,

Michael

[Mike Hansen]

On Sun, Feb 8, 2009 at 2:43 PM, mabshoff <mabs...@googlemail.com> wrote:
> If you want "just" python + scipy + numpy you can run
>
> ./sage -python
>
> and then you won't have to deal with the pesky preparser in Sage :)

Actually, "sage -ipython" would probably be a bit more useful.

--Mike

[mabshoff]

On Feb 8, 2:46 pm, Mike Hansen <mhan...@gmail.com> wrote:

> On Sun, Feb 8, 2009 at 2:43 PM, mabshoff <mabsh...@googlemail.com> wrote:
> > If you want "just" python + scipy + numpy you can run
>
> >  ./sage -python
>
> > and then you won't have to deal with the pesky preparser in Sage :)
>
> Actually, "sage -ipython" would probably be a bit more useful.

True. And to illustrate my point about running a 64 bit Sage on OSX
(this is actually an Intel box):

Sprocketer:sage-3.3.alpha5-64 michaelabshoff$ ./sage -ipython
Python 2.5.2 (r252:60911, Feb 3 2009, 22:28:14)
Type "copyright", "credits" or "license" for more information.

IPython 0.9.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints
more.

In [1]: import numpy as np

In [2]: import scipy as scipy

In [3]: import sys

In [4]: print sys.maxint
9223372036854775807

In [5]: from scipy.signal.filter_design import *

In [6]: butter(2,0.5)
Out[6]:

(array([ 0.29289322, 0.58578644, 0.29289322]),
array([ 1.00000000e+00, -1.95106077e-16, 1.71572875e-01]))

The problems I mentioned above about failed doctests are not related
to numpy/scipy at all, i.e. they are problems related to libSingular
and Givaro which you will never see if you run sage -ipython

I am getting my access to an OSX 10.5 PPC G5 box back hopefully
tomorrow, so I might post 64 bit OSX 10.5 binaries of the final 3.3
release for Intel and PPC CPUs.

> --Mike

Cheers,

Michael