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

[Travis Oliphant]

eric jones wrote:

>>> Lattice methods, where do they go? How about useful data structures 
>>> or combinatorics? So on and so forth. I think the upper level GAMS 
>>> categories cover sufficient range that most things can be put into a 
>>> directory without embarrassment. As to the detailed breakdown in the 
>>> GAMS sub-classifications, I am not so sure.
>>
>>
We should do the /lib top-level directory and also put under it nice 
general purpose data structures and other generally useful things that 
don't have another obvious home.


>>
> Here is where the current SciPy modules would likely get lumped in the 
> GAMS hierarchy.
>
> scipy/
>  analysis/
>  numbertheory/
>  functions/           special
>  linalg/              linalg, sparse
>  interpolation/       interpolate
>  rootfinding/
>  optimization/        optimize, ga
>  calculus/            integrate
>  diffeq/              integraltransforms/  fftpack
>  approximation/
>  probstat/            stats
>  simulation/
>  datahandling/        io
>  symbolic/
>  geometry/
>  graphics/            xplt, gplt, plt
>  service/             gui_thread
>  develop/
>  other/               cow, cluster ??, signal  ??
>
>
> (Cluster and signal didn't fit anywhere obvious to me)

I got the name signal from MATLAB's signals toolbox.  

>
> The naming conventions are often quite similar.  The SciPy names are 
> generally shorter which is nice for typing.  Where SciPy has multiple 
> packages [(linalg, sparse), (optimize, ga), etc.], it is likely a good 
> idea.  Like you, I don't want to see a deep nesting in the package 
> structure.
> Looking at this, I don't see any real reason to reorganize top level 
> package names.  Are any of them that bad or misleading?  On the other 
> hand, I do think we should reorganize the functions within them some 
> to fix the places where they are organized based on "build" 
> convenience instead of actual function.  This will probably 
> necessitate the addition of new top level groups and maybe the pruning 
> of one of the current ones.  I've made a Wiki page to keep suggestions 
> that people have:

Some reorganization is probably needed, but I think that more work 
should be done on getting some kind of standard searchable help working 
well, first.  The only draw-back to the .chm idea is that I don't know 
how to make .chm files.


> I used to love "from xxx import *" and swore it was the right way to 
> handle Numeric, etc. since I few "array" and friends as builtin 
> functions...  I guess I've been hanging out with to many computer 
> scientists lately.  Or perhaps it is the few times where I have 
> wondered "where is function xxx [which is broken] coming from?" and 
> struggled through a large codebase to track it down.  We've had a 
> nasty bug or two where one import * unexpectedly clobbered some 
> functions from a previous import *.  In any case, it is a (seldom 
> broken) policy to never use import * in our code bases at Enthought.  
> It is probably a good idea to apply this same policy to SciPy.  Doing 
> so would partially solve the problem you discuss.

I think the current wisdom is to rarely use from import * in package 
code (I would say never but I think it is effective in the __init__ 
files of packages to make names available for the user).  But, often in 
interactive mode and some small scripts one will use from import * quite 
often.

-Travis