@MSGID:
<63976a7d-f3d4-4f15-958d-eef28880044cn@googlegroups.com> 6cc972c6
@REPLY:
<657aa16c-50e2-4f21-9c0b-1b9979cfcebfn@googlegroups.com> 09afd677
@REPLYADDR Brad Eckert <hwfwguy@gmail.com>
@REPLYTO 2:5075/128 Brad Eckert
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<e8fedb6c-a47c-4c5f-ac04-7ab6fe70ab16n@googlegroups.com>
<25fcc703-24ac-4a79-9983-d51a8952d90en@googlegroups.com> <95e8c139-b819-4baf-8911-4391002cad8an@googlegroups.com>
<ef4598b4-a89d-46dd-abfc-6da20e9e9601n@googlegroups.com> 1@dont-email.me>
<657aa16c-50e2-4f21-9c0b-1b9979cfcebfn@googlegroups.com>
@RFC-Message-ID:
<63976a7d-f3d4-4f15-958d-eef28880044cn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Monday, September 18, 2023 at 10:34:58 AM UTC-7, Marcel Hendrix wrote:
> On Monday, September 18, 2023 at 6:13:52 AM UTC+2, dxf wrote: 
> [..]
 > > > The 64-bit doubles and 80-bits extended are enough, but
there are algorithms 
> > > that only work when you have twice the width.
> [..]
> > Moore would find a better algorithm.
 > I doubt it. It is not that the whole algorithm switches to 128
bits to avoid the problem. 
> For some equations/problems there can be a mix of very small and very big 
> numbers where floating-point performs badly. By successive refinement the 
> issue can be eliminated, but in its critical operation higher-than-default 
> precision is needed. A typical use-case is throwing a switch. 
> 
> -marcel
I can imagine Tim the Tool Time Guy saying "MORE BITS!".

 As long as we are blue-skying, I would propose that arbitrary
precision floating point as well as arbitrary precision (bignum) integers be
supported in hardware. It would be nice to have IEEE standards for both.
Maybe we will see that someday.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441