🚀 go-pugleaf

References:



Last week, I made a posting to the net where I described what I thought might
be a bug in LSC ver. 2.01, namely, that the tangent function didn't work
properly.  After I did something nasty like take sin(infinity), the tangent
function would just return something funny with any argument it was called
with.

Well, after investigating further, it seems that yes, there IS a bug in LSC's
tangent function.  I discovered this by reading through the source code for
the math library, which THINK kindly provides.  This is what they have:

double tan(x)
double x;
{
	elems68k( &x, FOTANX );

	if ( SANEglobalenv.invalid || ( x == inf.plusdouble ) )
	{
		errno = ERANGE;
		x = max.plusdouble;
	}

	return(x);
}

Note that after calling the tan function in the Mac's transcendental functions
package, they check if the invalid bit is on in the SANE global env. word,
and if it's on, they return a large number.  HOWEVER, THIS BIT MAY ALREADY
HAVE BEEN SET BEFORE CALLING THE TAN FUNCTION!!! So, the elems68k(&x, FOTANX)
call will return the correct value, but LSC will return the wrong value to the
user.

For example, this bit of code would cause a problem:

a=1; b=0; c=a/b;
printf("%f\n", sin(c));  /* taking sin(INF) will set the invalid bit */
printf("%f\n", tan(0));  /* the wrong answer will be returned, since the
							invalid bit is set */
							
What LSC should have done is save the SANE environment word  before calling
elems68k( &x, FOTANX ), cleared the invalid bit, and then restored the environ-
ment word after the check.

OK, so this may not be the most earth-shattering news, but it is a bug
nevertheless, and I thought I'd inform people about it, so that they wouldn't
experience the problem too.

One final thing - I'm still using LSC ver. 2.01, and this bug may have already
been corrected in ver. 2.11.  If so, I'm sorry for dumping on LSC.  In any case,

I love LSC, and I always recommend it to friends.

					Ben Waldman
					waldman@endor.harvard.edu