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

[Christopher Felton]

On 1/3/12 3:00 AM, Travis Oliphant wrote:
> I don't know if this has already been discussed or not.   But, I really don't understand the reasoning behind "yet-another-project" for signal processing.   That is the whole-point of the signal sub-project under the scipy namespace.   Why not just develop there?  Github access is easy to grant.
>
> I must admit, I've never been a fan of the scikits namespace.  I would prefer that we just stick with the scipy namespace and work on making scipy more modular and easy to distribute as separate modules in the first place.   If you don't want to do that, then just pick a top-level name and use it.
>
> I disagree with Gael that there should be a scikits-signal package.   There are too many scikits already that should just be scipy projects (with scipy available in modular form).    In my mind, almost every scikits- project should just be a scipy- project.   There really was no need for the scikits namespace in the first place.
>
> Signal processing was the main thing I started writing SciPy for in the first place.   These are the tools that made Matlab famous and I've always wanted Python to have the best-of-breed algorithms for.     To me SciPy as a project has failed if general signal processing tools are being written in other high-level packages.   I've watched this trend away from common development in SciPy in image processing, machine learning, optimization, and differential equation solution with some sadness over the past several years.    Frankly, it makes me want to just pull out all of the individual packages I wrote that originally got pulled together into SciPy into separate projects and develop them individually from there.   Leaving it to packaging and distribution issues to pull them together again.
>
>
> Hmm.. perhaps that is not such a bad idea.   What do others think?  What should really be in core SciPy and what should be in other packages?   Perhaps it doesn't matter now and SciPy should just be maintained as it is with new features added in other packages?   A lot has changed in the landscape since Pearu, Eric, and I released SciPy.    Many people have contributed to the individual packages --- but the vision has waned for the project has a whole.     The SciPy community is vibrant and alive, but the SciPy project does not seem to have a coherent goal.   I'd like to see that changed this year if possible.
>
> In working on SciPy for .NET, I did a code.google search for open source packages that were relying on scipy imports.   What I found was that almost all cases of scipy were:  linalg, optimize, stats, special.   It makes the case that scipy as a packages should be limited to that core set of tools (and their dependencies).   All the other modules should just be distributed as separate projects / packages.
>
> What is your experience?  what packages in scipy do you use?
>
> Thanks,
>
> -Travis
>
>

My experience, I have not used scikits and I mainly use the scipy.signal 
package.  I don't have a strong opinion if .signal should be part of the 
core scipy or an independent package.  But it seems that there should be 
one package!  And hopefully, one development effort.  In general 
extending and enhancing the current .signal (regardless if it is part of 
scipy or not) not fragmenting the signal processing related code across 
multiple packages.

Regards,
Chris