🚀 go-pugleaf

In <9106010224.AA28532@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:

>          Also as has already been pointed out there is a software cost
>due to such features as 0*x no longer being 0.  In some cases this will
>have a performance impact in that compilers will generate inferior code.

As a compiler writer who has worked with IEEE systems, I don't know
why, at least in any area with an important impact on performance.
The reason for the IEEE definition (0*Inf=NaN) is that zero may
represent a result merely close to zero, and Inf really represents a
very large number -- I can pick representatives of these sets which
multiplied together give me a true result in the representable range
(not zero or Inf).  If I see a literal zero while compiling (the only
case I can think of when the compiler does anything that might care
about what 0*x equals), I feel quite free to assume that it is really
zero, in which case 0*x is really zero even for very large x.  So I
will do the same thing I would have for non-IEEE.  (This is the only
case I'm aware of where IEEE defines 0*x != x.)

>          As far as round to nearest goes, this does provide a real
>benefit.  I am not totally convinced it's worth the cost but a case can
>made.  The case for the round to even (when halfway) seems much more
>dubious.  I believe this represents a substantial portion of the cost
>(comments?) and the additional benefits seem quite tenuous.  I don't
>see any good reason for the other 3 modes.

Round to +/- infinity give you the floor and ceiling functions, which
come up frequently, for example in many transcendental function
algorithms.

>          I said:
>>arithmetic may compute a totally bogus result with no error indication
>>(other than the setting of an overflow bit which nobody looks at).  On
>>other systems the error is usually more obvious.

IEEE also provides for trapping bogus results if the
appropriate flags are set -- then you don't need to look at the
overflow bit.  Of course, if you're using an IBM RS/6000, this goes
many times slower, so perhaps you don't consider this an option...

>          I guess I was a bit obscure here.  On IBM hex systems when
>floating overflow occurs the default behavior is for an error message
>to be printed which includes a traceback pointing to the offending
>instruction.  Execution then continues (with the max floating number as
>a fixup) but will terminate if more than a small number (5?) of over-
>flows occur.  I was under the impression that this was typical behavior
>for pre-IEEE systems.  Is that not the case?

It is the case.  It's also perfectly achievable behavior for IEEE
systems if exceptions are trapped.  This has nothing to do with the
IEEE standard.  Instead, it's probably a result of default Unix
software behavior, which is not to trap in most implementations.
Of course, you don't have much choice on an RS/6000...

>          I consider this behavior much friendlier than typical IEEE
>behavior which is to run to completion then output infs and nans (or
>worse plausible but wrong numbers) with no indication of where the
>error occurred.

Much friendlier than non-trapping behavior on any FP system, that is...

>          It seems to me that the existence of infs in IEEE is in-
>creasing the likelihood of obtaining plausible-looking garbage.

No, not trapping increases that likelihood.  Given that you're not
trapping, the existence of Infs and NaNs makes it somewhat more likely
that you'll get reasonable results (though personally I'd prefer the
traps).

>          79 bits is clearly an absurd length for a floating point
>format (the same is true of the 43 bit single extended format).

An interesting statement.  Are you of the "only powers of two are real
numbers" persuasion?