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:	<Pine DOT SUN DOT 3 DOT 91 DOT 980520121106 DOT 24974C-100000 AT is>
	<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
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

In article <3565AC7F DOT C1DCD557 AT cyberoptics DOT com>,
	Eric Rudd <rudd AT cyberoptics DOT com> 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

- Raw text -