Path: utzoo!attcan!uunet!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: Questions about NCEG
Message-ID: <3158@goanna.cs.rmit.oz.au>
Date: 5 Jun 90 07:50:12 GMT
References: <1990May30.205436.11534@twinsun.com> <13028@smoke.BRL.MIL> <8924@celit.fps.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 44

In article <8924@celit.fps.com>, ps@fps.com (Patricia Shanahan) writes:
> The problems with IEEE 754 nonstandard mathematics have real high level
> language implications. For example, there is a deep assumption that,
> for any two expressions x and y of arithmetic types, "x > y" is either true
> or false. This is embedded in the structure of the "if - then - else"
> construct. A truly logical high level language use of IEEE 754 would have
> to make explicit allowance for the possibility that "x > y" is neither
> true nor false, but meaningless because x and y are not ordered relative
> to each other.

Pop!  (That was a credibility bubble bursting.)
The comparisons >, >=, <, and <= are required by IEEE 754
to return true or false in the cases where you would expect
them to return true or false, and when it is not possible
to determine the ordering (e.g. Infinity < Infinity) the
IEEE 754 standard requires an exception.  A program that uses
IEEE 754 arithmetic *CAN* rely on x > y being either true or
false.  The standard also recommends providing _additional_ operators
(e.g. for C we might have !> meaning less, equal, or unordered), but
that's only a recommendation, not a requirement.

So IEEE 754 arithmetic does _exactly_ what you're asking for.

> The current position on the FPS Model 500 is that we use IEEE format floating
> point, but run by default with all infinity and NaN generating operations
> trapped, and treat both zero representations as being true zero. This gets
> the benefits of a standard format, while conforming to the usual rule that
> it is best to report an error at the first point in the execution of the
> program that it is detectable. 

Except for treating -0 and +0 as identical, that's absolutely fine according
to the standard.  (There must, to be fully conformant, be a mode in which
NaNs and Infinities are returned, but nobody said that mode had to be fast.
Patching up the results in a system-supplied signal handler is just fine.)
In the absence of Infinities, there are two ways of generating and recognising
-0:  the copysign() function and friends, which are in the appendix and are
therefore not required, and decimal<->binary conversion.  If you haven't got
copysign() and friends (and you are recommended but not required to) and you
have divide by zero trapping instead of producing infinities, there is no
arithmetic operation (in the usual sense) that can tell the difference.

-- 
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists.  However, no example could be found to include here."