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

Perry Greenfield perry at stsci.edu
Tue Sep 28 12:52:02 CDT 2004

On Sep 27, 2004, at 7:29 PM, Charles Harris 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.
I have a feeling that no matter what classification system is used, so 
long as it
is purely hierarchical people are going to expect to find an item in 
another area.
Some things naturally associate with more than one category. Picking a 
good system
is important, but alone is unlikely to eliminate user frustration in 
finding things.
I suspect that being able to find tools through keyword associations or 
some other
means that allows classifying the tool in more than one way will also 
be necessary.
Mind you, this doesn't need to be reflected in the package structure, 
just that there
is a way of searching for the tool using alternate associations 
(through web forms,
a script, or whatever). I think that the documentation system (embedded 
in doc strings
or similar) should enable this sort of search.


More information about the Scipy-dev mailing list