> I think the intent is that maxima will run on a Common Lisp system.
> If some future Common Lisp system is missing these, then it's not a
> Common Lisp, and we should ignore it. :-)
When there's already code in place that could help us port to a
non-Common Lisp system, I think we should leave it. You might be able
to find a decent Lisp on (say) a PDA without its being a full Common
Lisp....
> > are bugs in the underlying Lisp versions; c) to have cross-checks
> complain loudly to your Lisp provider. If you can't trust it to run
> plain Lisp numeric code,...
I certainly agree that you should complain to your Lisp provider if
there are bugs. But it's nice to know you can fall back on something
else. I just discovered (and reported), for instance, that GCL 2-3.6
can't evaluate (acosh -1.0).
The Common Lisp standard also chooses different branches in some cases
than Maxima does. I suspect that most of this is just Maxima being
sloppy, but someone's got to look into it.... Ideally, we'd like
numerical evaluation, simplification, Taylor, and rectform/polarform
(any others?) to be consistent....
> maxima says sinh(1.0b-5) is 1.000000000016266B-5, but a simple
> evaluation with a taylor series says the answer is
> 1.000000000033333B-5.
Umm, both you and Maxima need to be a bit more careful here... the
correct answer is 1.000000000016667B-5 (which by the way lisp::sinh gets
right). What is going on here is that bfloat doesn't have a specific
sinh routine, and uses the exponential form, which is not numerically
well-behaved near sinh(0). In fact, it does the same thing
(logarc/exponentialize) for a whole series of functions:
csc sec cot sinh cosh tanh csch sech coth
asin acos acsc asec acot asinh acosh atanh acsch asech acoth
Someone will have to look at these one by one to see which might have
numerical evaluation issues....