Re: obsolete code?

> > classify.c: the functions in that file are obsolete, but
> > might still be used in some obscure library that some people
> > actually use (like the neural net tools in packages/sn28 ).
>
> The alternative is to fix up the library code (if the number
> of uses is limited there). I will look into it.

Might be possible to just move classify.c into sn28 and make
it a dynamically loaded module.

> > dz.c: the main problem with removing dz.c is that all the common
> > mathematical functions, such as sin, cos, log, tan, tanh and such are
> > implemented as DZ.  They would have to be re-implemented as regular
> > DX. I don't think it's worth the trouble, even if the DZ compiler is
> > no longer used.
>
> I have actually done that a while ago in psu-lush.

Oh, OK.

> > One thing that we should perhaps consider is reworking some of the
> > math library, perhaps by relying more heavily on gsl (as in
> > packages/libnum), with higher-level functions.  This may make Lush
> > more convenient as a "desktop calculator" or matlab replacement.
>
> Yes, we should look into that for special functions and
> things like root finding. For linear algebra I think we
> should go with LAPACK and ScaLAPACK, though. It is a
> widely adopted standard and we would have to wait longer
> to see multiprocessor support or improved algorithms
> in GSL.

I might be mistaken, but I believe GSL calls blas/lapack (or
cblas/clapack). The actual functions it calls may depend on which
version of the blas/lapack libraries you have installed
(e.g. libatlas, which comes with Debian/Ubuntu does automatic
parallelization on multi-cpu/multicore machines).

  -- Yann


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php