Date: Tue, 15 Oct 2019 11:23:00 +0000
Thiago Macieira via Std-Proposals:
> They are not broken. Neither int nor double are.
>
> If you need specific format or bit-width, then you use the one with that in
> the name. If you don't and you can just live with whatever size the compiler
> wants to give you, use that.
>
All modern compiled (and some (most?) VM-based) languages give users
fixed layout because it is important to know so you have understanding
what is going on.
> Then do what everyone else does and start with floatN and modify it from
> there. Granted, I know your naming extends from P1468, but that is one
ugly
> 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?
> 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.
> std::floatN_iec559_t makes much more sense then.
It doesn't specify if it's binary or decimal.
> No need to be so dramatic. The fundamental types are not broken, they're
> just flexible. They don't set specifics in stone because every platform is
> different, has different capabilities, efficient storage, access and
> calculation capabilities. A general purpose language needs that
flexibility
> for typical situations but also needs to give the user control over
> representation when they have a specific reason (though there is most
> certainly work to be done on *that* front).
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.
> They are not broken. Neither int nor double are.
>
> If you need specific format or bit-width, then you use the one with that in
> the name. If you don't and you can just live with whatever size the compiler
> wants to give you, use that.
>
All modern compiled (and some (most?) VM-based) languages give users
fixed layout because it is important to know so you have understanding
what is going on.
> Then do what everyone else does and start with floatN and modify it from
> there. Granted, I know your naming extends from P1468, but that is one
ugly
> 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?
> 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.
> std::floatN_iec559_t makes much more sense then.
It doesn't specify if it's binary or decimal.
> No need to be so dramatic. The fundamental types are not broken, they're
> just flexible. They don't set specifics in stone because every platform is
> different, has different capabilities, efficient storage, access and
> calculation capabilities. A general purpose language needs that
flexibility
> for typical situations but also needs to give the user control over
> representation when they have a specific reason (though there is most
> certainly work to be done on *that* front).
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.
Received on 2019-10-15 06:25:44