On 3/18/07, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> tanh(1.0d3)
> gives a stack overflow error in wxmaxima 0.7.1
Maxima punts to CL:TANH for floating point evaluation of tanh.
This is established by the hash table created in src/trigi.lisp;
search for "frob %tanh". (Bigfloats take another route.)
Looks like GCL and Clisp have trouble with tanh for large arguments.
GCL 2.6.7: (tanh 1.0f3), (tanh 1.0e3), (tanh 1.0d3), and (tanh 1.0l3)
all trigger "Can't print a non-number" which probably means TANH
returned inf or nan, and then barfed trying to display the result.
I don't know how that became a stack overflow in Maxima.
Clisp 2.38: (tanh 1.0f3) and (tanh 1.0e3) both trigger a floating point
overflow error. (tanh 1.0d3) and (tanh 1.0l3) yield 1.0d0 and
1.0l0, which is correct enough for me.
I guess someone should file bug reports for GCL and Clisp.
> The computation of tanh(x) by using exp(x) is a bad idea.
I guess we need to relay this notion to the GCL and Clisp projects.
I don't have any interest in having Maxima create private definitions
of the math library functions (unless we really, really must).
FWIW
Robert