[SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
oliphant at ee.byu.edu
Thu Sep 30 23:26:19 CDT 2004
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.
> functions/ special
> linalg/ linalg, sparse
> interpolation/ interpolate
> optimization/ optimize, ga
> calculus/ integrate
> diffeq/ integraltransforms/ fftpack
> probstat/ stats
> datahandling/ io
> graphics/ xplt, gplt, plt
> service/ gui_thread
> 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
> 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
More information about the Scipy-dev