>>>>> "Stavros" == Stavros Macrakis <stavros.macrakis@verizon.net> writes:
>> 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. :-)
Stavros> When there's already code in place that could help us port to a
Stavros> non-Common Lisp system, I think we should leave it. You might be able
Stavros> to find a decent Lisp on (say) a PDA without its being a full Common
Stavros> Lisp....
I think the code is getting sufficiently Common Lispy that this is
going to be hard if that decent Lisp isn't a full Common Lisp.
Besides, the functions aren't really gone---they're still in CVS for
that determined person to dig up and make work in his decent Lisp
system on a PDA.
Stavros> I certainly agree that you should complain to your Lisp provider if
Stavros> there are bugs. But it's nice to know you can fall back on something
Unfortunately that means yet another thing to maintain.
Stavros> else. I just discovered (and reported), for instance, that GCL 2-3.6
Stavros> can't evaluate (acosh -1.0).
Yeah, gcl has (had?) lots of little bugs like this. (And long ago,
CMUCL had problems with sinh for small args.)
Stavros> The Common Lisp standard also chooses different branches in some cases
Stavros> than Maxima does. I suspect that most of this is just Maxima being
Stavros> sloppy, but someone's got to look into it.... Ideally, we'd like
Stavros> numerical evaluation, simplification, Taylor, and rectform/polarform
Stavros> (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.
Stavros> Umm, both you and Maxima need to be a bit more careful here... the
Stavros> correct answer is 1.000000000016667B-5 (which by the way lisp::sinh gets
Stavros> right). What is going on here is that bfloat doesn't have a specific
What was I doing? Of course, you're right! (And if lisp::sinh is from
gcl, it gets it right probably because I sent a patch for gcl for this
long ago. It uses the series for small x. :-) )
Stavros> sinh routine, and uses the exponential form, which is not numerically
Stavros> well-behaved near sinh(0). In fact, it does the same thing
Stavros> (logarc/exponentialize) for a whole series of functions:
Stavros> csc sec cot sinh cosh tanh csch sech coth
Stavros> asin acos acsc asec acot asinh acosh atanh acsch asech acoth
Stavros> Someone will have to look at these one by one to see which might have
Stavros> numerical evaluation issues....
Yep. The sleazy way out is to just bump up fpprec for the computation
and then reduce it for the final result.
Ray