[Openmcl-devel] Maxima + Clozure on Windows

Barton Willis willisb at unk.edu
Mon Mar 30 11:03:24 UTC 2009


-----Gary Byers <gb at clozure.com> wrote: -----

>Barton (and anyone else who might know):
>
>1) is doing
>
>bessel_j(3,2.0);
>
>in Maxima equivalanet to doing
>
>(maxima::bessel-j 3 2.0)
>
>in lisp ?

Yes, that is correct.

>2) is the correct answer approximately 0.129 ?  (That's what I get
>in an x86-64 CCL.)

Yes, the correct value is 0.1289432494744. Alternatively, you can skip
maxima::bessel-j and go directly to slatex:desj; for example:

Maxima 5.17post http://maxima.sourceforge.net
Using Lisp Clozure Common Lisp Version 1.3-dev-r11537M-trunk
(WindowsX8632)
(%i1) to_lisp();
Type (to-maxima) to restart, ($quit) to quit Maxima.
MAXIMA> (setf jvals (make-array 4 :element-type
'double-float :initial-element 0.0d0))
#(0.0 0.0 0.0 0.0)
MAXIMA> (slatec:dbesj 2.0 0.0 4 jvals 0)

NIL
NIL
NIL
NIL
0
MAXIMA> jvals
#(0.0 0.0 0.0 0.0)
MAXIMA>

The array jvals should be

  #(0.22389077914123579 0.57672480775687363 0.35283402861563784
  0.12894324947440208)

>If so, then we may have a reproducible test case that demonstrates
>at least one problem; the bad news is that the problem is likely
>in the Maxima function SLATEC::DBESJ. which seems to have been
>automatically translated from Fortran and is rather large (about 17KB
>of source, about 32KB of object code.)  It might be necessary to
>sort of whack at that from both ends in order to expose the bug.

The supporting code in f2cl-lib could also be to blame.

I know that automatically translated function SLATEC::DBESJ isn't a simple
test
case, but it's the best I've been able to do. I'll keep looking.

It's terrific that you all are interested in fixing this bug. Thanks.

Barton




More information about the Openmcl-devel mailing list