Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Tue, 21 May 2024 04:09:11 -0500
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <v2hobr$h5oc$1@dont-email.me>
References: <abe04jhkngt2uun1e7ict8vmf1fq8p7rnm@4ax.com>
 <memo.20240512203459.16164W@jgd.cix.co.uk> <v1rab7$2vt3u$1@dont-email.me>
 <20240513151647.0000403f@yahoo.com> <v1to2h$3km86$1@dont-email.me>
 <20240514221659.00001094@yahoo.com> <v234nr$12p27$1@dont-email.me>
 <20240516001628.00001031@yahoo.com> <v2cn4l$3bpov$1@dont-email.me>
 <v2d9sv$3fda0$1@dont-email.me> <20240519203403.00003e9b@yahoo.com>
 <v2etr0$3s9r0$1@dont-email.me> <20240520113045.000050c5@yahoo.com>
 <v2ff99$3vq7q$1@dont-email.me> <20240520153630.00000b5a@yahoo.com>
 <v2g529$4fn7$1@dont-email.me>
 <be08fc860572f2ea80b6d3530161aefd@www.novabbs.org>
 <v2guog$ctck$1@dont-email.me> <v2hcm3$f1pd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 21 May 2024 11:09:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="46cc854e5f55f7c187177de16fb06ef0";
	logging-data="562956"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5JIh+O1AGaiPxxSMhLHrI4qpf1QsQPMM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6msJcYtvv9Ej9+WWDNdp79VY5fo=
Content-Language: en-US
In-Reply-To: <v2hcm3$f1pd$1@dont-email.me>
Bytes: 4177

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).

....