Questions about NCEG

[Patricia Shanahan]

In article <13038 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>In article <8846 at celit.fps.com> ps at fps.com (Patricia Shanahan) writes:
>>The issue is even clearer for Fortran.
>
>Thank heavens.
>
>>Fortran users and implementers generally seem to take floating point types
>>far more seriously than typical C users and implementers. If distinguishing
>>-0.0 from 0.0 is such a good thing, why is it so expressly prohibited, not
>>just in early Fortran standards, but in the draft for the next Fortran 
>>standard?
>
>I'm not sure I like this line of argumentation, even though it would
>lead to a conclusion in line with mine.  Certainly there is no guarantee
>that the best possible decisions would be made by the Fortran committee,
>although this particular one does sound good to me.
>

I am not trying to suggest that all decisions made for Fortran should 
automatically be adopted for C. I just think that differences should be
justified on their own merits, not simply by pointing to IEEE 754. I do
not think that the IEEE treatment of zero can be justified.

However, the Fortran community has an admirable track record of writing
numerical software that gets right results within the expected degree
of accuracy of the program across a wide range of floating point formats
and rounding implementations, with major optimization order-of-evaluation
changes. There are exceptions, but the usual rule is easy porting to new
implementations.

>One thing I would like to challenge in this thread is the assumption
>that it is rational to specify conformance to IEEE 754 and/or 854.
>If I had an engineer working for me and upon being requested to
>design a portable format for floating-point representation he had
>come back to me with a specification like IEEE 754, I would fire the
>bastard on the grounds of professional incompetence.  Not only does
>IEEE 754 fail in its primary goal of standardizing the format, but
>it invents a multiplicity of variations plus a new fantasy world of
>nonstandard mathematics, the latter solely for the reason that in
>SOME artificially simple situations, lack of care on the part of
>algorithm designers could be automatically compensated for by
>carrying invalid arithmetic results as the IEEE 754 special values.
>Catering to amateur sloppiness while making life more difficult for
>the careful professional is inexcusable in a technical standard.
>It is insane to insist on conformance to such an abomination.  At
>best, it is a fact of life (especially in the small computer world)
>that has to be somehow coped with, hopefully by the implementor of
>one's programming language.

I totally agree with this. If a calculation is being done whose result
does not affect the final answer, it is a waste of time and possibly 
numerical accuracy. If it does affect the final answer, and it overflows,
it is usually best to stop the calculation immediately and re-think the
treatment of that value. There are a few cases where this is not true,
but I think they are the exception, not the rule. Even where a calculation
should proceed in the face of some out-of-range input, the right solution
is more likely to be to substitute a finite number within the reasonable
range than to go ahead with an infinite result. The best case for proceeding
with an out-of-range input is when smoothing is going to be used to allow
for the possibility that a few input values are totally wrong. Smoothing
methods have an unfortunate tendency to spread infinities over many
surrounding values.

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. I am afraid that any attempt to extend high level languages
to expose IEEE to the user program will have to be inconsistent in one
of several ways.

There is however, from a computer manufacturer point of view, tremendous 
utility in having an industry standard floating point format and rounding
rules. For the forseeable future, we will be able to buy, in just about
any required technology, off the shelf implementations of floating point
hardware that will accept the same internal representation of floating
point numbers.

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. 

>
>>Note that there is nothing about this that prevents a standard conforming
>>Fortran implementation from being based on an IEEE floating point conforming
>>platform. It just requires a little care on the part of the language 
>>implementer to ensure that all zeros are equal to each other and are never
>>printed with minus signs.
>
>It is also probably advisable for implementors faced with 68881 etc.
>FPUs to implement the programming language's negation operation by
>loading a FP register with true_zero then subtracting the expression
>to be negated from the register (leaving a sensible negative in the
>register even when the expression happens to have zero value).

There are actually two solutions to implementing a single, consistent zero,
based on hardware that can yield a negative zero. One is to prevent 
negative zero from occurring. The other is to take care in displaying data
(which is usually less frequent than negation) that the minus sign decision
is based on comparison to zero, not a sign copy. Either solution, applied
consistently, will work. They do yield different results in the face of
explicit sign copy, and equivalence/union between integers and floating
point.

--
	Patricia Shanahan
	ps at fps.com
        uucp : ucsd!celerity!ps
	phone: (619) 271-9940