Re: "A diagram of C23 basic types"

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

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.

As mentioned elsethread, I was referring to the real value.
1.0/3.0 as a C expression yields a value of type double, typically
0.333333333333333314829616256247390992939472198486328125 or
0x1.5555555555555p-2   (Unless FLT_RADIX is a multiple of 3, which
pretty much never happens.)

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.

Again, by 1/3 I meant the real number that is the mathematical result of
that formula, and of 2/6, and of 1-2/3, not the formula itself.

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.[***]

Which is convenient only because we happen to use decimal notation
when writing numbers.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */