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

[Charles Harris]

Travis Oliphant wrote:

> 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
>
I looked at MSC and GAMS. From a purely mathematical view  MSC is nice, 
but a
bit too high level, though it would be nice if lattices and control were 
part of GAMS. I
think GAMS would be the best fit. A few caveats: we might want to expand
or modify the subclassifications, Data seems sort of a catchall, and 
where would such
things as equivalence relations go (Data?). One virtue of such a 
classification scheme
is that it highlights areas that need to be addressed.

> 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
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>