Date:	Thu, 10 Jun 1999 09:14:11 -0500
From:	Eric Rudd <rudd AT cyberoptics DOT com>
Subject:	Re: libm sources from cyberoptics
To:	djgpp-workers AT delorie DOT com
Message-id:	<375FC833.9F9C49D2@cyberoptics.com>
Organization:	CyberOptics
MIME-version:	1.0
X-Mailer:	Mozilla 4.05 [en] (Win95; U)
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990609113455 DOT 11862J-100000 AT is>
	<375EB600 DOT 979DA70D AT cyberoptics DOT com> <199906092042 DOT QAA09698 AT envy DOT delorie DOT com>
	<375EE2A8 DOT FDAF0475 AT cyberoptics DOT com> <199906092201 DOT SAA10186 AT envy DOT delorie DOT com>
Reply-To:	djgpp-workers AT delorie DOT com

DJ Delorie wrote:

> > It gets generated by (-1.)*(+0.), for instance.
>
> If that's the case, we should treat -0 just like +0.

I'm beginning to think that we ought to return sqrt(-0.) = +0. without
error, as Eli has suggested, since -0. can so easily occur in
computations, and especially since -0. compares equal to +0.  (In other
words, there's no portable way for the caller to trap a -0. argument to
sqrt).

The only other functions I can think of where a distinction is made
between +0. and -0. are the log functions.  Currently log(+0.) returns
-INF with a range error, and log(-0.) returns NaN with a domain error.
I wonder if I should treat log(-0.) the same as log(+0.).  The
difference in error handling between log and sqrt, of course, is that
sqrt(+0.) is perfectly reasonable, but log(0.) should generate an error,
regardless of the sign of 0.

For atan2(0., 0.), the C9x draft specifies various fanciful numeric
results, depending on the signs of the zero arguments, but I return NaN
in all such cases, so the signs are irrelevant there.

-Eric Rudd

- Raw text -