On Tuesday, 15 October 2019 04:23:00 PDT Lyberta via Std-Proposals wrote:
> > naming scheme (itself derived from an existing emergent convention in
> > literature that float64's natural extention should be called the arbitrary
> > binary128 rather than float128). I have no idea why the word "binary" is
> > used in the name of a float, but the word "float" isn't. Everything is
> > binary. Eh well.
>
> No really. IEEE 754-1985 had "single precision" and "double precision"
> and later versions renamed those to binary32 and binary64 because of
> addition of decimal floating point formats. Float32 and float64 were
> never an official names.
>
> Should "float" be renamed to "single" then?

There's no need to change known naming conventions that everyone is familiar
with. If it were misleading, sure, but it isn't.

> > And they should. They are more legitimate. The compiler knows best for the
> > target machine. When it comes to communication, it's the human's job to
> > coerce it into a different representation. The two are very different
> > scenarios.
>
> Any useful program is connected to the Internet. Maybe by proxy i.e. its
> data is sent over by another program. Knowing exact binary layout is
> crucial.

When transmitting, sure. If the types were standard, I'd have used them in the
CBOR API I wrote, because that's the intent: interoperation over the Internet.

But for local data manipulation, that's not necessary. Take this simple
percentage calculation:

        cout << "Total complete: " << (count * 100. / total) << "%\n";

There's no need to specify that this needs to be calculated using 53 bits of
decimal precision instead of 52. We just need a good enough type that is fast
on the host machine.

> > std::floatN_iec559_t makes much more sense then.
>
> It doesn't specify if it's binary or decimal.

It does if "float is binary" is the convention.

- std::floatN_iec559_t is binaryN
- std::decimalN_iec559_t is decimalN

GCC for example supports many _FloatN types as extensions.

> Again, flexible types are a relic of the past and only useful in
> extremely rare circumstances. Fixed layout is what's needed in 99% of cases.

I disagree. Flexible types are useful in a lot more cases and fixing them to
specific layouts is needed only when interoperating with the world outside the
process.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products