[SciPy-dev] genetic algorithm, number theory, filter design,zero finding
pearu at scipy.org
pearu at scipy.org
Tue Apr 9 14:04:00 CDT 2002
On Tue, 9 Apr 2002, Chuck Harris wrote:
> Good enough. Would packaging things up with distutils be a good way to
Yes. In fact it is the only way to go. However, you may want to look how
packaging is done in scipy for its different submodules. Scipy uses
scipy_distutils that is derived from distutils. For more information, see
> Also, are there any documentation guidelines? I assume that more
> might be wanted than goes in """...""".
Not that I know of. We need to work out these guidelines. I think we
should also consider PEP 287 while doing this:
> For testing, I'm guessing that there might be two kinds: first, to
> check that the routines operate correctly on a given platform and
> second, to check that the routines do what they are supposed to do.
I don't see the difference.
> Are there any testing guidelines?
Yes, there are. See
These guidelines hold for most of its parts except scipy_test module
part that is now moved to scipy_base/testing.py
And note that all guidelines are a bit outdated due to fast development of
scipy. If something seems to be inconcistent or is not working according
to these guidelines then the best place to look is the source of scipy
modules. And of course, scipy-dev can be helpful.
> > > Number Theory : These were used for analysing arrays of
> > antennas used
> > > in radar interferometry. They are also useful in integer
> > programming,
> > > cryptography, and computational algebra.
> > >
> > > Reduction of a matrix to Hermite normal form
> > > Reduction of a matrix to Smith normal form
> > > LLL basis reduction
> > > LLL basis reduction - deep version
> > > Gram-Schmidt orthogonalization
> > I am not sure where these should go when considering the current scipy
> > state. As you mention, they are parts of different fields from what we
> > have in scipy now. I think they should be parts of the corresponding
> > packages that may not exist as of yet. Personally, I am very
> > interested in
> > CA stuff.
> These routines really need exact rational arithmetic in the general
> case. The floating point versions here just happen to be 'good enough'
> in many situations. Are there any plans to bring exact arithmetic into
> scipy or numpy?
I don't think that numpy is a proper place for this.
And I don't think that anything useful should be under one
umbrella such as SciPy.
What I think is that Computational Algebra in Python should be a separate
I have been experimenting with CA for Python almost two years trying
out various approaches. Using Python 2.2 one can do serious symbol
manipulations but pure Python implementation seems to be impractical -
Python is too slow. Currently the most appropiate CA library seems to be
GiNaC (www.ginac.de) to be wrapped to Python. I have already done that but
the project is currently freezed until Boost.Python V2 becomes usable
so that Python 2.2 new features can be fully exploited.
But if only exact arithmetic is needed for your modules then gmpy is the
best thing to consider because it wraps a very fast GMP library and it
can be made available also for Windows platforms.
> > > Zero finders: General use and fun. Bisection best for some special
> I took a quick look at the Fortran code for the version of solve in
> the minimization package. It seems to be a multidimensional form of
> Newton's method, really the only way to go in higher dimensions unless
> the function is holomorphic. The routines here are for the one
> dimensional case and should be more robust in this situation. If any
> one has a more general idea of what goes on in the current zero
> finder, I would like to hear about it.
Some comments about Powell's hybrid method used by minpack/hybrd.f can be
found, for example, in
> > > Genetic algorithm: Used in digital filter design to optimize for
> > > coefficient truncation error. I looked at galib and found
> > it easier to
> > > roll my own, but didn't try for any great generality. I
> > think it would
> > > be good to include uniform crossover and to pull the
> > fitness function
> > > out of the genome --- in a tournament, fitness can depend on the
> > > population. Perhaps it can all be made simpler.
> > galib seems to be developed more than 6 years and I would
> > expect it to be
> > rather mature, though, I have not used it myself. May be a
> > wrapper to such a library would be more appropiate for a longer term.
> > Though the licence may be an issue, galib seems to be GPL compatible.
> I was sort of hoping for a ga guru to comment.
OK. Do we have one in this list?
I made my comment from the SciPy point of view as in addition to possible
license issues we must be careful when including new software to scipy: it
must be most efficient available and it most be actively maintained
preferably by the specialists of the field, and also in future.
More information about the Scipy-dev