>>>>> "Richard" == Richard Fateman <fateman@cs.berkeley.edu> writes:
Richard> No comment on the conditions issue..
Richard> I don't know why bessel_j doesn't return numbers.
Because I typed bessel_j[0](x) instead of bessel_j(0,x). The former
isn't the 0'th order Bessel function anymore.
Richard> On CLOS and bigfloat and other number types...
Richard> I've thought about this in the past at various times, and it is
Richard> not likely that I will recall all the issues off the top of my head,
Richard> but here are a few.
Richard> 1. You can't overload the built-in operators like + and * with CLOS.
Richard> This means that the "most natural" extension of CL to bigfloats is
Richard> unavailable. This may not matter if you use PLUS instead of + etc.
Actually, I can since everything is in the "MAXIMA" package, so I can
shadow CL's + and *. But I'd rather not do that. I'm already
confused by maxima sometimes using the same names as the CL functions,
but with slightly different behavior.
Richard> 2. It is not so clear how to combine stuff. For example,
Oh, you read more into this than I meant. I was only looking for a
way of making it easier for me to write numeric code in Lisp for
maxima. I think CLOS would make it a bit easier by allowing me to use
the same code. Consider this from ellipt.lisp:
(flet ((ascending-transform (u m)
(let* ((root-m (cl:sqrt m))
(mu (/ (* 4 root-m)
(cl:expt (1+ root-m) 2)))
(root-mu1 (/ (- 1 root-m) (+ 1 root-m)))
(v (/ u (1+ root-mu1))))
(values v mu root-mu1)))
This would be a valid algorithm if u and m were bigfloats, or complex
bigfloats. By using CLOS, and appropriate definitions for the basic
ops and functions, I wouldn't have to write anymore code.
As it is now, I'd have to write a version for bigfloats. Then a
messier version for complex bigfloats.
Richard> bigfloats of different precision. Rational + float could be
Richard> made into a rational. It could be made into a float unless it overflows.
I think the bigfloat code already handles the case of bigfloats of
different precision. I think I would follow CL's rules of numeric
contagion so rational+bigfloat is a bigfloat, and so on.
Ray