Deutsch   English   Français   Italiano  
<6fb77ac272a1532df3b134ec1e7d53a899a742b9@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: dxf <dxforth@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: "The Best Programming Language for the End of the World"
Date: Sat, 12 Apr 2025 14:43:16 +1000
Organization: i2pn2 (i2pn.org)
Message-ID: <6fb77ac272a1532df3b134ec1e7d53a899a742b9@i2pn2.org>
References: <87bjtn2hct.fsf@gmail.com>
 <2025Apr7.084256@mips.complang.tuwien.ac.at>
 <c7b8e285289ed63448289ee84d1f5b36eab45557@i2pn2.org>
 <nnd$52bd8a99$2cfa4611@2813463487325c8d>
 <05376993a82bd98bd2bb808b6d70d88a0c19891f@i2pn2.org>
 <cbb106be3daee91e2680165287cd6ca6560245b9@i2pn2.org>
 <nnd$4e97017c$71179fa7@ab267a929dfc81b6> <vt5rrb$mr2p$1@dont-email.me>
 <077656b5c422bbcbdf53452c341a0af4700b5fa5@i2pn2.org>
 <vt8eqq$316s1$1@dont-email.me>
 <f4cf5fff1a2239f3b7f6e8ccce00969d0925f1e3@i2pn2.org>
 <vtb62k$1ni2k$1@dont-email.me>
 <7e76f6f1dec1a3bb5a0e8f33eb80089ed47e8e00@i2pn2.org>
 <e5f5c904560a535430fa648d32297a2b@www.novabbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 12 Apr 2025 04:43:17 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4179569"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="XPw7UV90Iy7EOhY4YuUXhpdoEf5Vz7K+BsxA/Cx8bVc";
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <e5f5c904560a535430fa648d32297a2b@www.novabbs.com>
Bytes: 2305
Lines: 20

On 12/04/2025 1:42 am, mhx wrote:
>> This is likely to have been a factor in Intel's decision to use
>> 80-bits internally.
> 
> Maybe they needed 80 bits to print a binary 64-bit float in BCD
> for COBOL compilers.
> However, one needs a few hundred bits to correctly represent a
> binary 56-bit significand in decimal, so maybe it is only enough
> for single-precision floats?

Who does that?

> For sure, high-quality libraries do not rely on 80-bit extended
> precision for decimal output - I remember even the MASM library
> had special code for that.
> ...

I take no precautions limiting output to 15 and 18 digits respectively
for double and extended.  This is floating-point after all and lack of
accuracy at the limits is expected.