>>>>> "Stavros" == Stavros Macrakis <stavros.macrakis@verizon.net> writes:
>> I favor the policy of turning numerical work over to Lisp when ever
>> possible. Other than possible bugs in the numerical functions in Lisp,
>> what are arguments against doing this?
Stavros> I agree entirely that we should turn numerical work over to the
Stavros> underlying Lisp whenever possible, but we should keep the
Stavros> implementation-independent version somewhere in the source (though not
Stavros> normally used) in order to: a) preserve future portability to platforms
Stavros> which may not have all these functions built-in; b) as a backup if there
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> are bugs in the underlying Lisp versions; c) to have cross-checks
I favor getting rid of all of that code and complain loudly to your
Lisp provider. If you can't trust it to run plain Lisp numeric code,
why should Maxima? There's no excuse these days for these kinds of
errors.
Stavros> PS In Maxima 5.5, the cross-check goes the other way: it is the
Stavros> **bfloat** acosh (and xacosh) that is grossly wrong because of the
Stavros> fpplus problem already reported and fixed by Ray Toy. The machine acosh
Stavros> is good to the last bit.
I think all of the bfloat routines need to be examined. For example
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.
We should do better than this....
Ray