Mail Archives: djgpp/1998/05/23/16:30:20
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 -