Hacker News Reader

Comment by Kenji | Hacker News Reader

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.

View on HN

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