I kind of disagree here.
Instead of inserting LAPACK source into the Maxima source, how about
pointing to a few binary forms, one for each plausible host environment,
with a suitable interface. Perhaps we could even point to matlisp, which
apparently solves the problem of the foreign function interface for cmucl
and allegro.
So what is needed is CLISP and GCL. Or just say that LAPACK is not available
for certain implementations. (The set of features of Maxima in my version
of Allegro CL is missing other pieces, like plotting; on the other hand, it
has voice output as an option. LAPACK need not be universal.)
If someone wants LAPACk for GCL, it would require coming up with suitable
interface code and suitable binary (.dll, .so, .lib ??). It seems to me that
this is a GCL project, suitable for someone to do who knows almost nothing
about maxima. Perhaps it should be a CFFI implementation for GCL.
There are many other programs in netlib that could potentially be of
interest to maxima users, and for someone on this list to speculate on what
is most useful and spend time converting or interfacing such a program --
without an application in mind -- seems to have the potential for a major
distraction. If the same person could, instead, figure out a way of
improving maxima in a way that is more nearly unique -- ie provides a
symbolic mathematical facility that is not available in netlib or any other
programming framework... or perhaps is only available in proprietary form in
Mathematica or Maple... that seems to me to be more productive.
If people are lacking in ideas of what symbolic facility might be possible,
there are items in this mailing list that have come up. Or alternatively,
just browse through the (Free, online) mathematica or maple documentation
and find something neat that maxima does not yet do. And either mimick the
design, or perhaps improve on it.
Or look at the potential project list for a class in algebraic manipulation
are posted near the end of this document...
http://www.cs.berkeley.edu/~fateman/282/hand1.pdf
My suggestion though: if you have no more math background than a year of
freshman calculus, your chance of making a thoughtful contribution will be
considerably lower than if you have a more sophisticated background in math.
This background can be obtained through studying some of the literature or
"the competition". While enthusiasm and energetic programming effort are
necessary, they are rarely sufficient to overcome a naive design of symbolic
math facilities.
RJF
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Leo
> Sent: Saturday, December 23, 2006 7:04 AM
> To: maxima at math.utexas.edu
> Subject: Re: [Maxima] LAPACK with maxima
>
> * Robert Dodier (2006-12-22 23:21 -0700) said:
> ^^^^^^^^^^^^^
> > On 12/22/06, Raymond Toy <raymond.toy at ericsson.com> wrote:
> >
> >> It's just very big, that's all. I haven't and don't plan on
> >> creating interfaces to all the functions. Eigenvalue/eigenvector
> >> and SVD seem useful, so I've done those.
> >>
> >> Perhaps it can be a share or contrib package, but I'm not even sure
> >> it should be checked into maxima at all.
> >
> > If you mean some or all of LAPACK -- yes, I believe it should be
> > committed to cvs.
>
> Is this similar to what http://matlisp.sourceforge.net/ does?
>
> >
> > I believe it is important and widely used, so it should in a
> > subdirectory of src (not share). We can work on creating interfaces
> > apart from just getting the f2cl output loaded into Maxima
> >
> > Thanks for working on this problem,
> >
> > Robert
>
> --
> Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F)
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>