Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Sun, 29 Jun 2025 05:03:30 +0200
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <103qae2$16tu9$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <20250403150210.000020f8@yahoo.com>
 <86selt8lxv.fsf@linuxsc.com> <20250428162738.00007c1d@yahoo.com>
 <103j290$3bv4a$1@dont-email.me> <8734bm1eqz.fsf@nosuchdomain.example.com>
 <20250626235916.00003314@yahoo.com> <lGi7Q.55256$Ra5f.13001@fx13.iad>
 <87y0teyrg7.fsf@nosuchdomain.example.com> <103kvst$3tgp3$1@dont-email.me>
 <87tt40znsu.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 29 Jun 2025 05:03:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d2ffdc893ce0fc358613caa5c9da1224";
	logging-data="1275849"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19kt1P3y26dpES7p1TUvpji"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:a5nIIt66pfzg0k4c5dvdTiq9ilg=
In-Reply-To: <87tt40znsu.fsf@nosuchdomain.example.com>
X-Enigmail-Draft-Status: N1110

[ Some technical troubles - in case this post appeared already 30
  minutes ago (I don't see it), please ignore this re-sent post. ]

On 28.06.2025 02:56, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 27.06.2025 02:10, Keith Thompson wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> [...]
>>>> But not all decimal floating point implementations used "hex
floating point".
>>>>
>>>> Burroughs medium systems had BCD floating point - one of the advantages
>>>> was that it could exactly represent any floating point number that
>>>> could be specified with a 100 digit mantissa and a 2 digit exponent.
>>>
>>> BCD uses 4 bits to represent values from 0 to 9.  That's about 83%
>>> efficent relative to pure binary.  (And it still can't represent 1/3.)
>>
>> That's a problem of where your numbers stem from. "1/3" is a formula!
>
> 1/3 is also a C expression with the value 0.  But what I was
> referring to was the real number 1/3, the unique real number that
> yields one when multiplied by three.

Yes, sure. That was also how I interpreted it; that you meant (in
"C" parlance) 1.0/3.0.

>
> My point is that any choice of radix in a floating-point format
> means that there are going to be some useful real numbers you
> can't represent.

Yes, sure. Sqrt(2.0) for example, or 'pi', or 'e', or your 1.0/3.0
example. These numbers have in common that there's no finite length
standard representation; you usually represent them as formulas (as
in your example), or in computers as constants in abbreviated form.

In numerics you have various places where errors appear in principle
and accumulate. One of the errors is when transferred from (and to)
external representation. Another one is when performing calculations
with internally imprecise represented numbers.

The point with decimal encoding addresses the lossless (and fast[*])
input/output of given [finite] numbers. Numbers that have been (and
are) used e.g. in financial contexts (Billions of Euros and Cents).
And you can also perform exact arithmetic in the typical operations
(sum, multiply, subtract)[**] without errors.[***]

Nowadays (with 64 bit integer arithmetic)[****] quasi as "standard"
you could of course also use an integer-based fixed point arithmetic
to handle large amounts with cent-value precision arithmetics (or
similar finite numbers of real world entities).

As an anecdotal add-on: There was once a fraud case where someone
from the financial sector took all the (positive) sub-cent rounding
factors from all transactions and accumulated them to transfer them
to his own account. If you know how much money there's transferred
you can imagine how fast you could get a multi-millionaire that way.

[*] But that factor is probably and IMO not that important nowadays.

[**] When you do statistics with division necessary, or things like
compounded interest you cannot avoid rounding at some decimal place;
but that are "local" effects. At this point numerics provides a lot
more stuff (WRT errors and propagation) that has to be considered.

[***] Try adding 10 millions of 10 cents values (0.10) in "C" using
a binary 'float' type; you'll notice a fast drift away from the exact
sum.
c=9296503	f=1000000.062500	value reached with fewer terms
c=10000001	f=1087937.125000	too large value at exact terms

[****] Processor word sizes not that common, let alone guaranteed,
in legacy systems.

> That's as true of decimal as it is of binary.
> (Trinary can represent 1/3, but can't represent 1/2.)
>
> Decimal can represent any number that can be exactly represented in
> binary *if* you have enough digits (because 10 is multiple of 2),
> and many numbers like 0.1 that can't be represented exactly in
> binary, but at a cost -- that is worth paying in some contexts.
> (Scaled integers might sometimes be a good alternative).
>
> I doubt that I'm saying anything you don't already know.  I just
> wanted to clarify what I meant.

Thanks. Yes.

Please see my additions above also (mainly) just as clarification,
especially in the light of some people despising the decimal format
(and also the folks who invented it back then).

Janis