From: nospam AT lenny DOT dseg DOT ti DOT com (Jesse Bennett) Newsgroups: comp.os.msdos.djgpp Subject: Re: Code to Fix sinh() in libm.a Date: 23 May 1998 20:13:13 GMT Organization: Texas Instruments Lines: 48 Message-ID: <6k7akp$dor$1@superb.csc.ti.com> References: <3564F35C DOT A0FBA509 AT cartsys DOT com> <3565AC7F DOT C1DCD557 AT cyberoptics DOT com> NNTP-Posting-Host: lenny.dseg.ti.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk In article <3565AC7F DOT C1DCD557 AT cyberoptics DOT com>, Eric Rudd writes: [ Nate's excellent suggestion (develop alternate math lib) snipped ] > 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. Numerical algorithms are my bread and butter, and I agree with Eli. Exceptional results, which include Inf as well as NaN, etc, should be flagged. In fact, I prefer that the program terminate with a FP exception, so that I am forced to fix the bug (In my experience Inf's are almost exclusively the result of a coding error). Cases where continuing the computations are the "right" thing to do are rare IMO. There is also an issue with portability with programs which do not handle exceptions (such as div by 0) in the application code. > 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. Yes. > 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. As stated above, I would prefer that the program crash. This is also one of the reasons I prefer using Linux for most of my development work. It will crash on any FP exception that is not trapped by the application code. I also do a fair amount of code development on SGI's which behave exactly as you propose. I find it infuriating trying to track down x/0 bugs on these machines. -- Jesse Bennett, PhD Note for email replys : my first name goes before the @ in my address