Mail Archives: djgpp/1998/05/18/12:16:52
Eli Zaretskii wrote:
> I agree that using coprocessor-specific features might help, sometimes
> help a lot. But the tricky part is to do that without breaking
> ANSI/IEEE compatibility, since even 80-bit numbers can generate
> exceptional results, like with sqrt(-1). So some testing of the
> arguments and the results is still required, in order to set errno or
> call matherr.
If the tests are biased in favor of high speed for normal arguments at
the expense of error-handling speed, they can be pretty quick.
> FYI: I have found the latest version of libm sources on the net, and
> I'm slowly working on adapting them to DJGPP, hopefully for v2.02.
> This version has some accuracy-related fixes in low-level functions
> such as expm1, but otherwise it hasn't change much.
I had noticed that their old expm1 routine was pretty bad. They simply
computed exp(x) and then subtracted one. The relative accuracy of that
scheme is terrible for arguments near zero. This was, I believe, the
origin of the problems with sinh() that started this whole thread.
> I can make this version available for you if you want.
I would appreciate receiving either the new libm code or the URL.
However, when I saw the problem with expm1, I began to regard the entire
libm package with suspicion, and decided that it would be easier to
continue polishing my own routines than to subject the libm code to the
meticulous scrutiny needed to catch more problems like that. But the new
libm routines may be useful as a cross-check, and to see if they have
any ideas worth using.
I have a question regarding the state of the coprocessor control
register. I noticed that in DJGPP v2.01, overflows are masked. Since the
IEEE floating-point formats are capable of representing infinity, this
is appropriate. Thus, overflow to infinity is handled as gracefully as
underflow to zero. The question I have is whether this state of the
control word can be counted on in future versions of DJGPP, or if I must
treat infinite results as errors. The ANSI C standard does not appear to
resolve this question. For instance, in 7.5.4.1 (for the exp()
function), it only says that "a range error occurs if the magnitude of x
is too large." If infinities are allowed, then no argument will be "too
large". Furthermore, in 7.5.4.4 (the log() function), it states that "a
range error *may* occur if the argument is zero." (emphasis mine) I take
this to mean that a range error is not *required* for infinite results.
But none of this will work if I can't count on the state of the x87
control register.
-Eric Rudd
rudd AT cyberoptics DOT com
- Raw text -