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

[Charles Harris]

Perry Greenfield wrote:

>
> 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.
>
There is some truth in this. There is also the difference between 
classifying by tool type, --
hammer, saw, etc. -- and classifying by expected use -- boat building, 
house building, etc.
That said, I could see how GAMS would provide a nifty table of contents 
for the documentation.
I also felt relief that I could see where several contributions I would 
like to add would fit in. I have
felt hesitant to introduce new modules, and I feel the current group is 
too narrow.

> Perry
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>