[SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?

Travis Oliphant oliphant at ee.byu.edu
Tue Sep 28 12:09:24 CDT 2004

Pearu Peterson wrote:

> On Mon, 27 Sep 2004, Charles Harris wrote:
>> eric jones wrote:
>>> Where should these live?
>>> monte carlo and markov chain might fit in scipy.stats?
>> How about in monte_carlo or some such? I think there is too much 
>> stuff put in odd places. Why is zeros in optimize? Makes no sense, 
>> but there it is.  I don't think now is the time to change all the 
>> directories around, but I hope we give some thought to the 
>> organization before it becomes unmanageable. The Dewey decimal 
>> classification was an achievement I am coming to appreciate.
> I agree that tools provided by Scipy are not organized well with 
> respect to the mathematical subject that they deal with and so finding 
> the needed tool for some specific task may not be always easy. And I 
> agree that this issue should be tackled as early stage as possible in 
> Scipy evolution, otherwise it will get more and more difficult to 
> decide where to put contributions from the society and there is a 
> danger of postponing such decisions to an unreachable future..
> The current organization of Scipy packages is mostly based on underlying
> Fortran/C libraries and that is obviously not the best way to organize
> any high-level scientific tool.
> While Chuck mentioned Dewey decimal classification then there are other
> classification schemes available. For example, MSC 
> (http://www.ams.org/msc/). A nice overview of MSC can be found in
>   http://www.math.niu.edu/~rusin/known-math/index/index.html
> I don't know how well could these classification schemes be used
> for organizing Scipy packages, may be we should take a look how Matlab 
> or Maple or Mathematica deal with organizing their tools.
>> From the maintenance point of view, IMHO, wrappers to external Fortran/C 
> libraries should be refactored from scipy packages to some "lib" 
> package. For example, there would be packages like
>   scipy.lib.blas
>   scipy.lib.lapack
>   scipy.lib.fftpack
>   scipy.lib.minpack
>   scipy.lib.cephes
>   scipy.lib.odepack
>   scipy.lib.quadpack
>   scipy.lib.fitpack
>   scipy.lib.minpack
>   scipy.lib.superlu
>   scipy.lib.amos
>   scipy.lib.cdflib
>   etc

I like this idea too. 

Right now, we have just been putting the library interfaces in the same 
top-level domain as the packages, but I think it does make more sense to 
put them in a .lib sub-package which other top-level routines can then 

I like this naming discussion.  We have not had enough of it in the 
past. I guarantee the names and divisions that Pearu, I and Eric have 
chosen have been more out of convenience and "getting something" working 
then any great thought.  I agree we should do this sooner than later.  
And I think we should move to SVN too.

I think it would be wise to use some sort of standard convention.  
Something like MSC is good, or the NIST classification GAMS.  

Right now, we have been sort of using the MATLAB and MAPLE approach 
which is group stuff together and give it a package name.   MATLAB has 
the notion of toolboxes.  We could break things up like they do, but I 
kind of like the idea of using a more standard convention that is used 
by others as well.


More information about the Scipy-dev mailing list