From: gpk AT physics DOT att DOT com
Date: Tue, 3 Nov 92 09:00:50 EST
Original-From: physics!gpk (Greg Kochanski)
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Mea Culpa, But...

>in the past.  One of the first ones I examined is incorrect; specifically,
>libsr/m/src/tanh.c.
>
>#include <math.h>
>
>double tanh(double x)
>{
>  const double ebig = exp(fabs(x));
>  const double esmall = 1.0/ebig;
>  return (ebig - esmall) / (ebig + esmall);
>}
>
>This makes tanh(x) an even function of x.  It should be odd.

David Ronis is quite correct here.  I submitted the change and messed it up.

>The problem can be removed by getting rid of the fabs(x),
Yes!
>or you can do something like you've done in the sinh function; e.g.,
>double tanh(double x)
>{
>
>  if(x>=0.0){ 
>    const double epos=exp(x); 
>    return (epos-1.0/epos)/2.0; 
>  }
>  else { 
>    const double eneg=exp(-x); 
>    return (1.0/eneg-eneg)/2.0; 
>  }
>}
NoNONONONONONO!!!    That isn't tanh().  It is precisely sinh().
Note that it goes to infinity for large arguments, while tanh()
approaches one as the argument gets large.

>In addition, I noticed that in asinh.c you do a test x>0, where x is a
>double.  This is probably picky, but shouldn't it be x>0.0? Does it
>matter?
Nope.  It doesn't matter, assuming the compiler is anywhere near correct.
For most operators, including >=, the "usual arithmetic conversions" apply.
This involves upgrading the (loosely speaking) smaller type in an expression
to the type of the larger.  That means the integer 0 gets converted to
a double 0.0.    This is in both C++ (Annotated Reference Manual section
4.5), the ANSI C standard, and K&R C.

Greg Kochanski