Re: Making Lemonade (Floating-point format changes)

On 5/21/2024 12:49 AM, Thomas Koenig wrote:

BGB <cr88192@gmail.com> schrieb:
 

Granted, they are not necessarily the option one would go if they wanted
"cheapest possible FPU that is still good enough to be usable".
>
Though, the point at which an FPU manages to suck badly enough that one
needs to resort to software emulation to make software work, is probably
a lower limit.
>
>
Luckily, "uses 754 formats, but with aggressive cost cutting" can be
"good enough", and so long as they more-or-less deliver a full width
mantissa, and can exactly compute exact-value calculations, most
software is generally going to work.

 This will require extensive testing and possibly modification for
a lot of software ported to such a system.  This will drive up
the total cost, presumably far more than any hardware savings.
 

Possibly, but one needs to strike a balance here...
If programs start breaking, one has maybe gone too far.

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

 An example of a more interesting question is
    if (a >= 0.) {
     if (b >= 0) {
       if (a + b < a) {
         printf("We should never get here!\n);
abort();
       }
     }
   }

Errm, I was promoting the idea of cost-cut floating point, not blatantly broken floating point...
In my testing, some things may be too small to notice:
   Rounding irregularities;
   Subnormals quietly treated as zeroes (and underflow giving zero);
   ...
But, some things are more likely to be noticed:
   Numerical drift (such as may result from hard-wired truncate);
   Exact integer calculations not giving exact integer results (*1);
   Exponent overflow or underflow giving garbage values;
   ...
Granted, one can argue that inexact routing may result in N-R failing to fully converge, and loops which use N-R and expect it to converge to an exact value may get stuck in an infinite loop.
*1: Both JavaScript VMs, and Quake's "progs.dat" VM, are prone to break if this one doesn't hold (both have a habit of storing integer data in floating point values).
Though, even with a multiplier that discards the low-order results, it may still give exact answers for multiplies where both operands are less than 2^32 (since, in this case, the low order results will always give 0, and discarding 0s doesn't change the result).
...