IEEE 754 Floating Point Type in C++ | Hacker News Reader

IEEE 754 Floating Point Type in C++

kkimdev.github.io

65 pointssigna1139 comments

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.

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."

> is anyone realistically compiling C code with the abstract C machine from the standard as their target

There are a lot of people that try. The nasty issue I've seen with the C standard is that most things work even if you bend the rules, until they suddenly don't and deviate in a weird way when you least expect it. Say you were porting software like this to a different compiler/architecture: how happy would you be to have to track down that floating point operations were broken because the author made assumptions about where the code would be running?

> 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.

*33 bit

With an 11-bit char type?

*13 bit

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

That's a cool idea. Although in reality it is probably better that they just standardise the sizes and implementations of types to the ones that 99.999999999999% of computers actually use.

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.

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-...

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

Pretty sure that's still the case, right?

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.

A little tangential: POSIX reserves the suffix _t for itself [1].

[1] https://www.gnu.org/software/libc/manual/html_node/Reserved-...

> Whats wrong with "double_t"?

/checks the spec

Hmm, a type that might be like double or might be like long double or might be implementation defined, depending on a "FLT_EVAL_METHOD", knowing that double and long double still are also implementation defined

What problem does double_t even solve then?

It's maybe the type with most precision according to whoever wrote the header at the chip manufacturer , so you can use it to do a calculation with hardware types with the least amount of error on the platform, maybe.

My point is, if IEEE 754 is a problem, you probably need to check things yourself anyway and can't trust whoever wrote numerical_limits at the chip manufacturer and that it applies to your platform without e.g. adding interrupt handlers etc. So you can't trust this template anyways.

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?

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.

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.

ISO/IEC lists their publicly available standards at the address below.

[1]: http://standards.iso.org/ittf/PubliclyAvailableStandards/

There's sci-hub and libgen, precisely for people like you. Hobbyists who would/could never in a million years buy the standards.

but I don't really wanna pay for specs when I'm just poking around for fun.

Then you don't, and just search the Internet harder. ;-)

They all use SciHub, LibgeN, and the like.

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...

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.

That's why there's a proposal for requiring two's complement integers in the next version of the standard for C.

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

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.

Plenty of platforms doesn't behave IEEE:ish when you go NaN and Inf, which this template collection doesn't check anyways.

You would have to catch FPU interrupts and do the overflow/underflow/whatever yourself. So using this project would just lead to false positives.

> which this template collection doesn't check anyways.

it does. It checks for iec559 support which implies nan / inf / denormal support.

Ye, but whoever wrote is_iec559 might have added written in the manual that you need to provide the interrupt handlers yourself or link in the manufacturers math lib?

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.

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).

Here's a whole Wikipedia section about extended formats: https://en.wikipedia.org/wiki/Extended_precision#IEEE_754_ex...

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.

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.

The standard doesn't have to prohibit anything, merely define names for types which are guaranteed to be conformant. Even if they redefine float and double, you could always have platform-specific names for weird types.

Conformant to the bit formats or conformant to the accuracy guarantees? I was mostly talking about the latter.

Intel's non-SSE floating point is 80 bits. Which had been a problem for some.

That would prevent experimentation with different types.

Not really - it's already a defacto standard so if you want to experiment with custom types and expect to just change `float` to 48 bits or whatever you should expect a lot of existing code to break, even if the standard says it shouldn't.

It's just too much effort to code to the actual standard and not worth it when essentially all computers use the same sizes and implementations of types.

Reply on news.ycombinator.com