Re: "A diagram of C23 basic types"

[ 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