Sign in

username or email:

password:



Not a member?
Forgot your password?

Search blogs



Search tips

Articles by category

Our Bloggers

See Also

Embedded SystemsFPGA

DSP Blogs > Christopher Felton > scipy.signal calling all developers

Christopher Felton
Christopher Felton's current favorite projects are implementing DSP digital circuits with MyHDL for FPGAs. More information @ LinkedIn.


RSS Feed

Would you like to be notified by email when Christopher Felton publishes a new blog?

  

Pageviews: 1194

scipy.signal calling all developers

Posted by Christopher Felton on Jan 19 2012   

There has been some chatter on the scipy-dev mailing list lately about enhancing the scipy.signal package.  Unfortunately, there seems to be a split.  Some are going off and starting a new package scikit-signal.  The original developer, Travis Oliphant, appears to have strong interest in seeing the scipy.signal evovle.  If you are interested in signal processing you should check out the mailing lists (scipy-user and scipy-dev) and the scipy.signal GitHub repository and consider contributing.  Contributions can be functional code, test code, documentation, opinions, comments, etc.

The following is a sub-list of categories and functions currently supported by the scipy.signal package.  The scipy documentation breaks the signal package into the following categories:

  • Convolution
  • B-splines
  • Filtering
  • Filter design
  • Continuous-time linear systems
  • LTI representations
  • Waveforms
  • Window Functions
  • Wavelets

A list of functions from the scipy.signal import:

'abcd_normalize', 'abs', 'absolute', 'add', 'allclose', 'any', 'arange',
'arccosh', 'arcsinh', 'arctan', 'arctan2', 'argsort', 'array', 'asarray',
'atleast_1d', 'atleast_2d', 'band_dict', 'band_stop_obj', 'barthann',
'bartlett', 'bessel', 'besselap', 'bilinear', 'blackman', 'blackmanharris',
'bohman', 'boxcar', 'bspline', 'bsplines', 'buttap', 'butter', 'buttord',
'c0_P', 'cascade', 'cast', 'ceil', 'cheb1ap', 'cheb1ord', 'cheb2ap',
'cheb2ord', 'chebwin', 'cheby1', 'cheby2', 'chirp', 'cmplx_sort', 'comb',
'conjugate', 'convolve', 'convolve2d', 'correlate', 'correlate2d', 'cos',
'cosh', 'cspline1d', 'cspline1d_eval', 'cspline2d', 'cubic', 'daub',
'decimate', 'deconvolve', 'detrend', 'diag', 'dot', 'ellip', 'ellipap',
'ellipord', 'exp', 'expand_dims', 'extract', 'eye', 'factorial', 'fft',
'fft2', 'fftconvolve', 'fftfreq', 'fftn', 'filter_design', 'filter_dict',
'filtfilt', 'findfreqs', 'fir_filter_design', 'firwin', 'firwin2', 'flattop',
'flipud', 'floor', 'freqs', 'freqz', 'gamma', 'gauss_spline', 'gaussian',
'gausspulse', 'general_gaussian', 'get_window', 'greater', 'greater_equal',
'hamming', 'hann', 'hanning', 'hilbert', 'hilbert2', 'ifft', 'ifft2', 'ifftn',
'ifftshift', 'iirdesign', 'iirfilter', 'impulse', 'impulse2', 'integrate',
'interpolate', 'invres', 'invresz', 'irfft', 'iscomplexobj', 'isscalar',
'kaiser', 'kaiser_atten', 'kaiser_beta', 'kaiserord', 'kratio', 'less',
'less_equal', 'lfilter', 'lfilter_zi', 'lfiltic', 'linalg', 'linspace',
'log', 'log10', 'logical_and', 'logspace', 'lp2bp', 'lp2bs', 'lp2hp', 'lp2lp',
'lsim', 'lsim2', 'lti', 'ltisys', 'maxflat', 'mean', 'medfilt', 'medfilt2d',
'mintypecode', 'mod', 'morlet', 'nan', 'nan_to_num', 'ndarray', 'newaxis',
'normalize', 'np', 'numpy', 'nuttall', 'ones', 'optimize', 'order_filter',
'parzen', 'pi', 'piecewise', 'place', 'poly', 'polyadd', 'polyder', 'polydiv',
'polyint', 'polymul', 'polysub', 'polyval', 'prod', 'product', 'qmf',
'qspline1d', 'qspline1d_eval', 'qspline2d', 'quadratic', 'r_', 'rank',
'ravel', 'real', 'real_if_close', 'remez', 'resample', 'reshape', 'residue',
'residuez', 'resize', 'roots', 'sawtooth', 'scipy', 'sepfir2d', 'signaltools',
'sigtools', 'sin', 'sinc', 'sinh', 'slepian', 'sort', 'special', 'spline',
'spline_filter', 'sqrt', 'square', 'squeeze', 'ss2tf', 'ss2zpk', 'step',
'step2', 'sum', 'sweep_poly', 'symiirorder1', 'symiirorder2', 'take', 'tan',
'test', 'tf2ss', 'tf2zpk', 'transpose', 'triang', 'types', 'unique',
'unique_roots', 'vratio', 'warnings', 'waveforms', 'wavelets', 'where',
'wiener', 'windows', 'yulewalk', 'zeros', 'zeros_like', 'zpk2ss', 'zpk2tf'

As seen in my other posts (blog1, blog2, snip1, snip2, snip3) I use Python quite extensively and the scipy.signal package.  I have found Python plus the numerical / scientific packages to be very powerful and productive.

As mentioned, if you enjoy signal processing and open-source packages getting involved with scipy.signal could be a opportunity to gain experience with signal processing software and group development.  I plan on contributing but (excuses, excuses) my time is limited and I also contribute to MyHDL (and would like to contribute more).

Even if you do not want to or cannot contribute to the scipy.signal development try out the Python programming language and the signal processing packages available.



Rate this article:
0
Rating: 0 | Votes: 0
 
   
 
posted by Christopher Felton
Christopher Felton's current favorite projects are implementing DSP digital circuits with MyHDL for FPGAs. More information @ LinkedIn.


Previous post by Christopher Felton: [Book Review] Numpy 1.5 Beginner's Guide
Next post by Christopher Felton: Curse you, iPython Notebook!
all articles by Christopher Felton

Would you like to be notified by email when Christopher Felton publishes a new blog?

  


Comments


jaidevd
Said:
Hello Christopher, In light of the debate on the scipy-dev mailing list, I have attempted to summarize the discussion here - http://brocabrain.blogspot.com/2012/01/scikit-signal-python-for-signal.html Hope this helps. Thanks
1 year ago
0
Reply
Sorry, you need javascript enabled to post any comments.
cfelton
Replied:
Jaidevd, Thanks for the comment. I had seen your post before posting mine. In some cases splits -just happen- and can end up being good in the long run. Example of a split that seemed to make sense was the pypy numpypy, simply because it is a reimplementation and not an enhancement. But the pypy separation had some concerns as well. I guess this is how I look at it, if a faster design cycle is desired I think the QoR will be lower. Which is desired; and from what I can tell the reason for the split. I am not trying to jab at the developers, it is simply that the focus is on development and experimentation vs. QoR releases (skunk works). Which is exciting and I can see the desire for a separate project with lower cost of entry. But I think this could be achieved with a development branch of scipy.signal instead of completely different project. Cutting edge developers can have access to the development branch and use it. This leaves the new and old as a cohesive group. Changes and modifications to the base and the new are more efficient. Regards, Chris
1 year ago
0
Sorry, you need javascript enabled to post any comments.