From: Eric Rudd Newsgroups: comp.os.msdos.djgpp Subject: Re: Code to Fix sinh() in libm.a Date: Fri, 22 May 1998 11:49:04 -0500 Organization: CyberOptics Lines: 47 Message-ID: <3565AC7F.C1DCD557@cyberoptics.com> References: <3564F35C DOT A0FBA509 AT cartsys DOT com> Reply-To: rudd AT cyberoptics DOT com NNTP-Posting-Host: rudd.cyberoptics.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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