
IEEE 754 Floating Point Type in C++ - signa11
https://kkimdev.github.io/posts/2018/06/15/IEEE-754-Floating-Point-Type-in-C++.html
======
obl
As fun as the template contraptions can be, is anyone realistically compiling
C code with the abstract C machine from the standard as their target ?

All other things being equal, I guess it's a plus to conform to the letter of
the standard, except they are not.

It's much more productive to pick a few practical compilers/architectures as
your target and allow yourself to work within the assumptions they provide
you.

I'm sure some people will disagree but I'd much rather enable no-strict-
aliasing and be on my way than trying to figure out if I actually abide by the
convoluted standard rule, since, after all, it does not mandate the existence
of this option.

~~~
userbinator
Absolutely. The same goes for portability: trying to write code that can run
on any platform ever created or ever will be created is a futile effort. There
are so many other things more important than that, and chances are if you do
end up needing your code to run on a "weird" platform, the standard is the
least of your concerns. The standard is merely a "lowest common denominator".

Relevant Linus Torvalds quote:

"There are competent people on standards bodies. But they aren't _always_
competent, and the translation of intent to English isn't always perfect
either. So standards are not some kind of holy book that has to be revered.
Standards too need to be questioned."

------
jancsika
> The type double provides at least as much precision as float, and the type
> long double provides at least as much precision as double.

We need a maliciously compliant compiler (mcc) that does stuff like set float,
double, and long double all to 32-bit.

~~~
shawn
*33 bit

~~~
FreeFull
With an 11-bit char type?

~~~
std_throwaway
*13 bit

~~~
FreeFull
But, 33 bits isn't a multiple of 13 bits

------
rightbyte
Whats wrong with "double_t"?

Excessive template magic is just confusing. If you compile for a embedded
platform there is a platform specific header anyway where you would put
#define BIGGEST_FLOAT_TYPE double" or something.

~~~
pjc50
For a long time on the most popular platform, Intel 32-bit, double _wasn 't_
IEEE754 64-bit float by default. It was 80-bit internally, causing weird
discrepancies. A description:
[https://stackoverflow.com/questions/3206101/extended-80-bit-...](https://stackoverflow.com/questions/3206101/extended-80-bit-
double-floating-point-in-x87-not-sse2-we-dont-miss-it)

(Entertainingly, all this template machinery doesn't seem to detect this
issue, making it a bit of a waste of time)

~~~
shaklee3
Pretty sure that's still the case, right?

~~~
simonbyrne
Not generally: most compilers make use of the SSE instruction set which
doesn't have extended precision. Occasionally old versions of gcc on 32-bit
machines will still use the old x87 instructions (which do have extended
precision), but these are becoming increasingly rare in the wild.

------
TheAceOfHearts
Rather tangential, and someone correct me if I'm wrong... I'm genuinely open
to changing my views on this.

You know what's fucked up? To the best of the knowledge you can't get the
official IEEE 754 spec without paying a decent amount of money.

Why do we support the IEEE when pulling this kind of crap? Tons of standards
are open! Like WHATWG, W3C, and IETF. Am I unreasonable for expecting
standards documents to be free and open? I'm not an implementer, but being
able to reference the spec is incredibly valuable in identifying what kind of
behavior I can reasonably expect when developing something. If I'm researching
something in a professional setting I can get my job to pay for it, but I
don't really wanna pay for specs when I'm just poking around for fun.

Having a paywall behind specs also makes them nigh inaccessible for people
from less privileged countries. There's no way a kid from, say, India or Latin
America would be able to afford tons of these specs.

I'm certainly not an expert on the subject, but couldn't someone create an
open "fork" of the IEEE 754 spec and have people refer to that instead?

~~~
pjmlp
You also cannot get any ISO standard without paying, including C and C++.

Yes the draft versions are available, but you cannot be 100% sure that the
final one isn't changed.

~~~
andrewaylett
TBH I suspect in any given case, the differences between the last draft and
the final text are smaller than those between the final text and reality.
Especially since the implementers were probably working from the draft.

I actually think it's quite an ingenious mechanism for making money from the
people who have it while not hindering the people who don't.

------
simonbyrne
No kidding: this is a problem with signed integers as well: C allows signed
magnitude, ones' complement, and two’s complement representations, but no
mainstream compiler supports anything other than two's complement.

> In short, the only machine the author could find using non-two’s complement
> are made by Unisys. Nowadays they emulate their old architecture using x86
> CPUs for customers who have legacy applications which they’ve been unable to
> migrate.

\- [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p090...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html#survey)

~~~
skookumchuck
The same goes for bytes being any size. No compiler supports that outside of
some specialized DSPs, and essentially no C software would even work on such
machines unless it was specifically written for them.

------
nitwit005
Or you could just document that code will only function with specific hardware
and compiler settings, and move on.

------
Kenji
I think the standard is, once again, bonkers about this. In practice float is
32 bit and double is 64 bit and both adhere to the IEEE754 standard. I have
yet to see a platform that implements floating point numbers and float and
double are something else. The standard should just mandate that floating
point numbers be IEEE754 compliant because that is the de-facto standard
anyway.

~~~
greglindahl
There's a ton of hardware and software that uses IEEE754 data formats but the
actual arithmetic isn't IEEE754. It would be a disaster for C++ to prohibit
this. Also, the IEEE 754 standard does include extended precision formats like
Intel's 8087 80-bit format.

~~~
tspiteri
While it does include many sizes, I don't think 80-bit is included. The sizes
mentioned in IEEE754-2008 are 16, 32, 64 and then multiples of 32 that are
greater or equal to 128 (96 is _not_ included).

~~~
greglindahl
Here's a whole Wikipedia section about extended formats:
[https://en.wikipedia.org/wiki/Extended_precision#IEEE_754_ex...](https://en.wikipedia.org/wiki/Extended_precision#IEEE_754_extended_precision_formats)

Now I totally agree that people should almost always not be storing these
things on disk or passing them across the network, but they were RECOMMENDED
by the IEEE committee, and that's why Intel and Motorola implemented them. A
kinda bad idea, bad implementation choices, but recommended.

~~~
tspiteri
You're right, I confused the interchange formats with extended and extendable
precisions. And the standard only recommends the extended and extendable
precisions "for extending the precisions used for arithmetic beyond the basic
formats", not for interchange.

