>>>>> "Liam" == Liam M Healy <Liam.Healy@nrl.navy.mil> writes:
Liam> #+allegro
Liam> (foreign-functions:def-foreign-call
Liam> ;;; See http://sources.redhat.com/gsl/ref/gsl-ref_7.html#SEC94
Liam> (jacobian-elliptic-function-int "gsl_sf_elljac_e")
Liam> ((u :double)
Liam> (m :double)
Liam> (sn (:array :double)) (cn (:array :double)) (dn (:array :double)))
Liam> :convention :stdcall
Liam> :returning :int)
I assume gsl_sf_elljac_e is declared in C to be
(double u, double m, double* sn, double* cn, double* dn)
So you really have to have an array for this? I'm not familar with
ACL's FFI.
CMUCL's version would be something like
(alien:def-alien-routine ("gsl_sf_elljac_e" jacobian-elliptic-function-int) int
(u double :in)
(m double :in)
(sn double :out)
(cn double :out)
(dn double :out))
I didn't test this, though.
Liam> to do this by hand. Second, if m>1, the elliptic functions are
Liam> undefined. GSL signals an error, but it is handled by default by
A&S gives a transformation for m > 1 to the case where m < 1, but
there are constraints then on the range of u. This is one deficiency
of GSL: it doesn't handle complex elliptic functions. maxima should
strive for this whenever possible and reasonable.
Liam> Having said that, I think using the existing library is the only way
Liam> to go. The suggestions to reimplement in CL, while having a certain
Liam> appeal, are just not practical. We need to leverage the existing
Liam> resources, and reimpmelementaion would take a huge amount of time and
Liam> effort, and on an ongoing basis as well.
I still think f2cl is a decent solution, but I guess I'm in the
minority here. There are Fortran implementations for just about
everything we would want and I suspect that f2cl could convert all of
them correctly.
I think there's more than enough for everyone to do with maxima, the
symbolic math program, instead of maxima, the amazingly fast number
cruncher. I'm more than happy with slow, correct numbers. If I want
fast, I'll use octave, matlab, scilab, or whatever.
Ray