Re: Making Lemonade (Floating-point format changes)

On 5/21/2024 12:17 PM, MitchAlsup1 wrote:

BGB wrote:
 

But OTOH, if 1.0+2.0 gives 2.999999, that is, not good enough, so there
>
is a lower limit here.

 1.0 has a fraction of 0
2.0 has a fraction of 0
1.0+2.0 has a fraction with a single HOB set.
all 3 above examples have the hidden bit set.
 Any implementation purporting to be IEEE 754 better not give anything
other than 3.0 !!
 

This is kinda the point.
But, then I realized, probably should have also included:
   5.0-2.0 should also give exactly 3.0
   2.0-5.0 should also give exactly -3.0
   ...
As the issue that can cause this is more common with subtraction (say, if one tries to cut corners by using bitwise inversion for negation and also not bothering with a carry in for the internal adder, ...).
Granted, this does add the cost that one effectively needs to do two copies of the adder, one computing the normal result, and the other a negated result (trying to do a negate after the fact having a much higher latency cost, vs doing both and then selecting which is needed).

Bad example. Even IBM and CRAY arithmetics, with all their problems,
were
not that bad.

There are ways to make the FPU that bad, but as I see it, this is below a minimum limit of acceptability.
Also, both Quake and typical JavaScript interpreters will lose their crap if this sort of thing happens (as in both cases, they may represent bit-flags in floating point numbers and set/clear them with FADD/FSUB, which while questionable, does effectively set a minimum requirement for this...).