On Thu, 20 Nov 2003, Robert Dodier wrote:
> CY wrote:
>
> > Is the relevant file the one here?
> > http://www.math.iastate.edu/burkardt/f_src/quadpack/quadpack.html
> > Does fortran 90 cause problems? (I don't think a free F90
> > compiler exists for Linux?)
>
> Hmm, so that makes at least three versions of Quadpack...
> There are two at Netlib -- one is part of SLATEC and the
> other is not. I don't know what, if any, are the differences
> between the two. As usual with Netlib source code, there is
> no clear statement of terms of use in the non-SLATEC version.
> However, there is a statement in SLATEC which says SLATEC
> is in the public domain.
>
> I would be inclined to use the SLATEC version, in the absence
> of bug reports or whatever that suggest some other version has
> been further developed. A translation is a derived work, but
> since the original is in the public domain, the copyright of
> the translation belongs to the translator.
I think the history of SLATEC is that it was mostly a port of existing
packages to F77 combined with cleanup of error handling, mechanisms to get
machine parameters, and documentation. Weak parts of SLATEC include
EISPACK, LINPACK, and the FFT code which should be replaced with LAPACK
and a current FFT package. There are only a few machine-dependent
routines in SLATEC: the machine parameter routines and a couple routines
in the xerror package:
$ grep '^C\*\*\*PURPOSE' d1mach.f fdump.f i1mach.f pimach.f r1mach.f
xerhlt.f
d1mach.f:C***PURPOSE Return floating point machine dependent constants.
fdump.f:C***PURPOSE Symbolic dump (should be locally written).
i1mach.f:C***PURPOSE Return integer machine dependent constants.
pimach.f:C***PURPOSE Subsidiary to HSTCSP, HSTSSP and HWSCSP
r1mach.f:C***PURPOSE Return floating point machine dependent constants.
xerhlt.f:C***PURPOSE Abort program execution and print error message.
(pimach returns the value of pi to machine precision)
In practice you can often get away with just replacing xermsg.f, which
is the routine most often used by the library, so fdump and xerhlt
are not needed.
There have been various attempts to write somewhat portable versions
of the machine constant routines. If you limit yourself to current
RISC and microprocessor machines this gets simpler, especially as
SLATEC doesn't have the concept of denormals and gradual underflow.
I was involved in the discussion of the machine parameter handling for
the R stats. package. R uses a lisp engine, so the same design should
be useful for maxima. The main issue was whether to compile in
the constants or use a run-time method. Since there are cases where
different versions of a .dll changed the settings of the f.p. unit,
we went with the dynamic approach.
The xerror package lets you keep count of various errors/warnings
during a long computation, so is intended for use in large batch
calculations, but probably isn't what you want if you are calling
SLATEC routines from maxima.
A proper port of one component of SLATEC should make it easier to
port other components. Also, many newer packages (LAPACK) are
mostly compatible with SLATEC conventions.
If you want a way to use maxima from a matrix language, R should be
considered. It is a more "modern" language than Matlab/Octave, and has a
much larger user base. The most fundamental difference is that R has a
concept of "NA" (missing data) separate from NaN's. I suspect the lisp
heritage will make working with R more appealing than working with octave.
--
George N. White III <aa056@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia, Canada