Date: Sat, 13 May 2000 17:21:21 -0400 (EDT) Message-Id: <200005132121.RAA16247@indy.delorie.com> From: Eli Zaretskii To: buers AT gmx DOT de CC: djgpp-workers AT delorie DOT com In-reply-to: <200005131249.PAA15925@is.elta.co.il> (buers@gmx.de) Subject: Re: Math functions References: <200005121101 DOT HAA05022 AT delorie DOT com> (buers AT gmx DOT de) <200005131249 DOT PAA15925 AT is DOT elta DOT co DOT il> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Dieter Buerssner" > Date: Sat, 13 May 2000 13:54:37 +0200 > > > Anyway, the only saving would be a single integer instruction that > > stores a value in errno. > > Unfortunately, it can be much more. You have to test the arguments > for range errors, poles, and special values. For the return value, not for errno, at least not typically. There are only two possible values to set errno to: EDOM and ERANGE, so the tests to decide which one is relevant are not that time-consuming, especially compared to the many cycles gobbled by a typical FPU instruction. > > > So, I think, the easier implementation of my_log is preferrable. It > > > will always return the same values, but won't set errno. > > > This is a step backwards, IMHO. > > I agree, with the errno. But I really cannot see, why the exceptions > are bad. We avoid exceptions to have control on what values are returned in abnormal cases: the value we return is not always the FPU's masked response to the appropriate exception. If you let the FPU to do its thing, you cannot have that kind of control on the return value. > > > Do you prefer, to not raise exceptions? > > > > Yes, absolutely. At least for production code, which is what libc.a > > is for. > > Could you please explain, why you dislike the exceptions. They are more trouble than they help, especially in the DJGPP environment. See the thread about FP exceptions being delivered to the parent program on Windows 9X, for example. > Besides the point, I made for debugging, they > can also be useful in interactive numerical programs. Set a flag in a > signal handler for SIGFPE, that can be checked at strategical places, You can test for NaN's and Inf's at the same places. If you really want fine control on what happens in abnormal cases, link with -lm and write a custom `matherr' function; this is more portable than exceptions, and also easier. Also, most people don't even know how to write a SIGFPE handler that will avoid triggering another SIGFPE when it returns. And on NT you cannot catch SIGFPE at all (I'm not sure what happens on Windows2000). I'm not saying that exceptions are useless: a clever programmer who knows what she is doing can use them to an advantage, sometimes great advantage. But on balance, I think using FP exceptions is better avoided. > > Please post the list of the functions, and let's talk about them. > > Here is a list of my source tree. This looks like a significant part of the missing long double versions that C99 requires. So I think it would be a good step forward to add them to the library. > The long double versions are quite well tested for accuracy (various > test programs, including comparision to 100 digit precision). If you could add at least some of the test programs to djtst, it would be even better. > The first four are "fast" versions, without accurate argument > reduction. Perhaps it would be a good idea to include fast inline versions in some system header, possibly included by math.h under some special compiler switch, such as -ffast-math.