Mail Archives: djgpp/1998/05/22/14:31:21
Nate Eldredge wrote:
> What about this idea: create another library which provides all the same
> functions, but is fast instead of being ANSI-compliant. Perhaps call it
> libfm.a. Then things that wanted ANSI could use -lm (or alternatively
> libm's functions could be plopped directly into libc), while game
> programmers etc. could use -lfm.
> I realize it would be more work, but it could give the best of both
> worlds.
I think I can make the library fully ANSI-compliant, but fast enough
that there would be no need for -lfm. There are some fast integer tests
one can do to sort out the bad arguments with maybe 20% overhead, and I
don't think that's enough of a time hit to justify making a separate
library -- they would replace the existing routines in libc. The libm
library will still be distributed for those who want the most meticulous
error-handling, and are willing to put up with the extra execution time.
The current libm has some accuracy problems, but they were in some
assembler routines that appeared to me not to have been part of the
original libm package, and they have been omitted from the new libm
source that I have seen.
The current discussion I'm having with Eli Zaretskii is over whether to
also flag infinite results as range errors. My viewpoint is that
although this has traditionally been done, the ability of IEEE 754
floats and doubles to represent infinity, and the ability of the
coprocessor to use infinity in subsequent arithmetic renders this no
longer an error.
Eli's argument is that it is prudent to flag infinite results, since
application code may not do this, and that it may signal that there's
something wrong.
There are actually a lot of judgment calls involved in writing a
floating-point library, and I certainly can't get a consensus on all of
them. However, I'd like to get some feedback from the newsgroup as to
whether other DJGPP'ers think that infinity-reporting via errno is
important in a faster alternative to libm.
A bit of relevant information: in v2.01 of DJGPP, overflow and
divide-by-zero exceptions are masked. Thus, if you compute 1./0. or
1.E200*1.E200, you will get infinity and the program won't crash, but
you can test for zero divides and overflows by the _status87() function.
-Eric Rudd
rudd AT cyberoptics DOT com
- Raw text -