Re: RfD: IEEE-FP

Andrew Haley wrote:
> Ed <nospam@xxxxxxxxxxx> wrote:
>> Andrew Haley wrote:
>>> Ed <nospam@xxxxxxxxxxx> wrote:
>>>
>>>> I am not in favour of any forth f/p extension that labours under
>>>> the misconception that essentially error conditions
>>>> ("nan"s/"inf"s) are equivalent to numbers.
>>> This is mostly about floating-point hardware. Current Forth
>>> floating-point software that runs on IEEE-compatible hardware is
>>> exposed to NaN and Inf, but has no standard way to deal with them.
>>> The hardware has NaN and Inf, so any proposal that allows us to
>>> control the hardware must deal with NaN and Inf.
>
>> How you are proposing to deal with nan/inf is where the problem lies.
>
> Any floating-point hardware that is IEEE-compatible is already
> "labouring under the misconception" that NaNs/Infs are part of the set
> of floating-point values. That's just how the hardware works: all
> we're proposing is a set of levers that allow you to control that
> hardware.

A telling point. And IIUC, they are in most desktop/workstation
hardware because IEEE 754 has essentially won the day.

It might help allay Ed's concerns to consider why NaNs/Infs are
in IEEE 754.

If I interpret Kahan correctly, the reason is the exceptions.
I've tried to lay that out by appending quotes from the link
Andrew gave a while back:

http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

Here's an executive summary, which I hope doesn't distort
Kahan's intent.

1. Exceptions are not errors.

2. The two exceptions relevant here are Invalid Operation and
Divide-by-Zero.

3. For each exception, the default behavior is to raise a flag,
substitute a default value, and resume execution without
stopping. The default values for the two exceptions
mentioned are Nan and +/-Infinity.

4. With the default values, IEEE math is algebraically closed,
producing defined results for all operations. If that were
not the case, the exceptions would *have* to be (rather than
*allowed* to be) trapped, or avoided altogether, making it
hard to keep program control, forcing one to deal with them
at inconvenient points, even when they are harmless. The use
of defined outputs (like Nans/Infs) and flags instead allows
more rational control.

-- David


-------------------------------------------------------------
Quotes from http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

p. 1: (Abstract)
"Java's floating-point arithmetic is blighted by five
gratuitous mistakes:

"3. Infinities and NaNs unleashed without the protection of
floating-point traps and flags mandated by IEEE Standards
754/854 belie Java's claim to robustness."

p 20:
"IEEE 754 specifies five flags, one named for each exception:
Invalid Operation, Overflow, Division-by-Zero, Underflow,
Inexact Result

"A flag is a type of global variable raised as a side-effect
of exceptional floating-point operations. Also it can be
sensed, saved, restored and lowered by a program. When
raised it may, in some systems, serve an extra-linguistic
diagnostic function by pointing to the first or last
operation that raised it."

p. 21:
"Java, like C++ , misuses the word "Exception" to mean what
IEEE 754 calls a "Trap."

"Java has no words for the five floating-point Events that
IEEE 754 calls "Exceptions": Invalid Operation, Overflow,
Division-by-Zero, Underflow, Inexact Result

"These events are not errors unless they are handled badly.

"They are called "Exceptions" because to any policy for
handling them, imposed in advance upon all programmers by the
computer system, some programmers will have good reasons to
take exception.

"IEEE 754 specifies a default policy for each exception, and
allows system implementors the option of offering programmers
an alternative policy, which is to Trap (jump) with
specified information about the exception to a
programmer-selected trap-handler. We shall not go into traps
here; they would complicate every language issue without
adding much more than speed, and little of that, to what
flags add to floating-point programming. (...)

"IEEE 754 specifies five flags, one named for each exception:
Invalid Operation, Overflow, Division-by-Zero, Underflow,
Inexact Result

"A flag is a type of global variable raised as a side-effect
of exceptional floating-point operations. Also it can be
sensed, saved, restored and lowered by a program. When
raised it may, in some systems, serve an extra-linguistic
diagnostic function by pointing to the first or last
operation that raised it.

"IEEE 754 specifies a default policy for each of these kinds
of floating-point exception:

i Signal the event by raising an appropriate one of the
five flags, if it has not already been raised.
ii (Pre)substitute a default value for what would have been
the result of the exceptional operation

[Here he gaves a table showing the default values, including
NaN for Invalid Operation and +/-infinity for
Divison-by-Zero.]

iii Resume execution of the program as if nothing exceptional
had occurred.

"With these default values, IEEE 754's floating-point becomes
an Algebraically Completed system; this means the computer's
every algebraic operation produces a well-defined result for
all operands."

p. 22:
"Why should computer arithmetic be Algebraically Completed?"

"Otherwise some exceptions would have to trap. Then robust
programs could avert loss of control only by precluding those
exceptions (at the cost of time wasted pretesting operands to
detect rare hazards) or else by anticipating them all and
providing handlers for their traps. Either way is tedious
and, because of a plethora of visible or invisible branches,
prone to programming mistakes that lose control after all."
.

Relevant Pages

  • Re: RfD: IEEE-FP
    ... PROPOSAL FOR AN OPTIONAL IEEE 754, ... FLOATING-POINT WORD SET ... for the special numbers and exceptions is specified by Annex ...
    (comp.lang.forth)
  • Re: Need of "Precise Exceptions"
    ... either in the hardware or with some ... For IEEE (floating-point) arithmetic, the key point is that the IEEE 754 ... (possibly with some software support) ...
    (comp.arch)
  • Re: cobol data format!!! urgent!!!
    ... Like most standard committees, the 10967 folk take the attitude 'if ... support it in hardware i.e. all except IBM and Unisys. ... A mandated IEEE 754 implementation ... "Two subsections are dedicated to the floating-point divide, ...
    (comp.lang.cobol)
  • Re: IEEE-FP 0.5.2 - Exception handling
    ... > event they wish to throw the exceptions. ... DPANS94 IEEE 754-2008 ... -43 floating-point result out of range overflow ... compilation/interpretation probably needs to be defined now. ...
    (comp.lang.forth)
  • Re: D3DCREATE_FPU_PRESERVE effects
    ... The main issue is if someone enables floating-point exceptions or changes the rounding-modes globally. ... The default native C++ CRT environment is to use double-precision, round-to-nearest, generate specials not exceptions. ... By default Direct3D 9 switches the calling thread's FPU to single-precision mode globally since for most of the history of Direct3D the only software that used it were games and this gives a significant performance increase. ... Note that Direct3D 10 and 11 do not modify the control word globally like this, leaving it up to the application. ...
    (microsoft.public.win32.programmer.directx.graphics)