[SciPy-Dev] Proposal for Scikit-Signal - a SciPy toolbox for signal processing

josef.pktd@gmai... josef.pktd@gmai...
Tue Jan 3 08:54:59 CST 2012


On Tue, Jan 3, 2012 at 6:50 AM, Gaël Varoquaux
<gael.varoquaux@normalesup.org> wrote:
>
> Hi Jaidev, hi list,
>
> I am resending a mail that I sent a few weeks ago, as I am not sure why,
> but I haven't been able to send to the list recently. This e-mail is a
> bit out of context with the current discussion, but I'd just like to get
> it out for the record, and because I originally wrote it to support the
> idea. I am writing a new mail to address the current discussion.
>
> -- Original mail --
>
> Indeed, at the scipy India, Jaidev gave a great talk about the empirical
> mode decomposition, and the Hilbert-Huang Transform. Given that I have
> absolutely formal training in signal processing, one thing that I really
> appreciated in his talk, is that I was able to sit back and actually
> learn useful practical signal processing. Not many people go through the
> work of making code and examples understandable to none experts.
>
> That got me thinking that we, the scipy community, could really use a
> signal processing toolkit, that non experts like me could use. There is a
> lot of code lying around, in different toolkits (to list only
> MIT/BSD-licensed code: nitime, talkbox, mne-python, some in matplotlib),
> without mentioning code scattered on people's computer.
>
> I think that such a project can bring value only if it manages to do more
> than lumping individual code together. Namely it needs code quality,
> consistency across functionality and good documentation and examples.
> This value comes from the community dynamics that build around it. A
> project with a low bus factor is a project that I am weary of. In
> addition, once people start feeling excited and proud of it, the quality
> of the contributions increases.
>
> I do not have the time, nor the qualifications to drive a scikit-signal.
> Jaidev is not very experimented in building scipy packages, but he has
> the motivation and, I think, the skills. At scipy India, we pushed him to
> give it a go. Hopefully, he will find the time to try, and walk down the
> recipe I cooked up to create a project [1], but for the project to be
> successful in the long run, it needs interest from other contributors of
> the scipy ecosystem.
>
>
> In the mean time, better docs and examples for scipy.signal would also
> help. For instance, hilbert transform is in there, but because I don't
> know signal processing, I do not know how to make a good use of it.
> Investing time on that is a investment with little risks: it is editable
> on line at http://docs.scipy.org/scipy/docs/scipy-docs/index.rst/
>
> My 2 euro cents
>
> Gaël
>
> [1] https://gist.github.com/1433151
>
> PS: sorry if you receive this message twice.

I think scipy as a central toolbox has still a very valuable role. For
example statsmodels uses linalg, stats, optimize, interpolate,
special, signal, fft and some sparse, and I might have forgotten
something.

sklearn (Fabian) brought several improvements to linalg back to scipy,
the recent discussion on sparse graph algorithms show there are
enhancements that are useful to have centrally across applications and
across scikits.
(another example Lomb-Scargle looks interesting as general tool, but I
haven't seen any other code for unevenly space time yet, and haven't
used it yet..)

The advantage of the slow and backwards compatible pace of scipy is
that we don't have to keep up with the much faster changes in the
early stages of scikits development.

One advantage of a scikits is that it is possible to figure out a more
useful class structure for extended work, than the more "almost
everything is a function approach" in scipy.

I also agree with Gael that having some usage documentation, like the
examples in statsmodels, sklearn and matplotlib, are very useful. My
recent examples, figuring out how to use the quadrature weights and
points (I managed), and how to use the signal wavelets or pywavelets
for function approximation (no clue yet).
Some parts are well covered in the scipy tutorials, others we are on our own.

Josef

>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


More information about the SciPy-Dev mailing list