Mail Archives: djgpp-workers/2000/05/13/17:10:18
> From: "Dieter Buerssner" <buers AT gmx DOT de>
> 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.
- Raw text -