>>>>> "kawabe" == kawabe <keita.kawabe@mpq.mpg.de> writes:
kawabe> Hello Ray, thanks for your reply.
kawabe> Hmmm, maybe my question was not clear enough.
kawabe> Anyway, unfortunately I think you're misunderstanding the
kawabe> situation. Let me give you another couple of examples to
kawabe> see what's wrong.
kawabe> (C7) j0(x)-bessel_j(0, x);
kawabe> (D7) 0
kawabe> This means that, on algebraic level, the first parameter in
kawabe> bessel_j(v, z) is interpreted as the order and the second
kawabe> is the argument (which is consistent with the documentation).
kawabe> Then, when evaluating to the floating point, the same thing
kawabe> is interpreted as the argument.
kawabe> (C10) float(j0(1)-bessel_j(0,1));
kawabe> (D10) .7651976865579666
kawabe> (C11) j0(1)-j1(0);
kawabe> (D11) .7651976865579666
kawabe> I hope this helps you to see the problem.
Sorry, I misunderstood the question. Yes, it's a bug, probably caused
by my undecidedness of whether to change the order of the args for
bessel or not.
This patch should fix it. It will be applied soon.
Ray
Index: bessel.lisp
===================================================================
RCS file: /cvsroot/maxima/maxima/src/bessel.lisp,v
retrieving revision 1.22
diff -u -r1.22 bessel.lisp
--- bessel.lisp 2 Jun 2003 16:04:38 -0000 1.22
+++ bessel.lisp 13 Jun 2003 15:12:28 -0000
@@ -475,7 +475,7 @@
(fillarray (nsymbol-array '$besselarray) jvals)
(aref jvals n))
(t
- (let* ((j ($bessel order (- arg)))
+ (let* ((j ($bessel (- arg) order))
(s1 (cis (- (* order pi))))
(s2 (* #c(0 2) (cos (* order pi)))))
(slatec:dbesy (- (float arg)) alpha (1+ n) jvals)
@@ -947,7 +947,7 @@
;; We have numeric order and arg and $numer is true, or
;; we have either the order or arg being floating-point,
;; so let's evaluate it numerically.
- ($bessel order arg))
+ ($bessel arg order))
((and (integerp order) (minusp order))
;; Some special cases when the order is an integer
;;