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

[Travis Oliphant]

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 
call.

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.  
http://gams.nist.gov/serve.cgi

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.


-Travis