Re: "A diagram of C23 basic types"

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Mon, 28 Apr 2025 16:27:38 +0300, Michael S wrote:
 

IMHO, a need for a common name for IEEE binary128 exists for quite some
time. For IEEE binary256 the real need didn't emerge yet. But it will
emerge in the hopefully near future.

 
A thought: the main advantage of binary types over decimal is supposed to
be speed. Once you get up to larger precisions like that, the speed
advantage becomes less clear, particularly since hardware support doesn’t
seem forthcoming any time soon. There are already variable-precision
decimal floating-point libraries available. And with such calculations, C
no longer offers a great performance advantage over a higher-level
language, so you might as well use the higher-level language.
 
<https://docs.python.org/3/library/decimal.html>

When working with such (low for me) precisions dynamic allocation
of memory is major cost item, frequently more important than
calculation.  To avoid this cost one needs stack allocatation.
That is one reason to make them built-in, as in this case
compiler presumably knows about them and can better manage
allocation and copies.

Also, when using binary underlying representation decimal rounding
is much more expensive than binary one, so with such representation
cost of decimal computation is significantly higher.  Without
hardware support making representation decimal makes computations
for all sizes much more expensive.

Floating point computations naturally are approximate.  In most
cases exact details of rounding do not matter much.  It basically
that with round to even rule one get somewhat better error
propagation and people want to have a fixed rule to get
reproducible results.  But insisting on decimal rounding
normally is not needed.  To put it differently, decimal floating
point is a marketing stint by IBM.  Bored coders may code
decimal software libraries for various languages, but it
does not mean that such libraries have much sense.

--
                              Waldek Hebisch