3 ms·

> Huh? Modern compilers don't do that. Depends on what you're calling "invalid" I suppose. > The exception is if you explicitly ask for such sketchy optimizat

> Huh? Modern compilers don't do that. Depends on what you're calling "invalid" I suppose. > The exception is if you explicitly ask for such sketchy optimizations with the `-ffast-math` flag, MSVC defaults to /fp:precise which doesn't round doubles after every operation (you have to opt out of this optimization with /fp:strict.) This can and does cause problems with e.g lockstep networking where you need consistent results on both sides of the pipe, when one end is accumulating in 80-bit registers and the other end is accumulating in 64-bit. http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx Maybe you don't consider this "invalid", or don't consider the latest MSVC compiler "modern", but if either of these is your argument, I'd argue you're writing off the article over minor quibbles of semantics - not over it being "flagrantly wrong."

Joky 12y ago
"invalid" is relative to a spec. You are writing in a language (usually) that specify what guarantee you get.
- MaulingMonkey 12y ago
  Specs have holes and ambiguities. And C++ in general likes to avoid guarantees to my frustration. In this case, we're not even guaranteed which specs apply. In this case, the C++ standard references the C standard contains the (optional/normative) Annex F referencing the IEC 60559 standard (which has the same content as IEEE 754). Annex F defines float and double in terms of the IEC 60559 single & double formats... and the standard C++ operators in terms of their IEC 60559 counterparts... and recommends long double be implemented as an extended double format (such as the 80-bit format commonly used by x86.) Annex F also mentions allowed optimizations, disallowed optimizations (involving various corner cases, rounding modes, implementation defined signaling exceptions, etc. ad infinitum). I don't see temporarily handling a double as an IEC 60559 Extended Double format anywhere on the allowed optimizations list, but I can't tell for certain if it runs afoul of any of the specifically disallowed optimizations of Annex F either. I'm guessing /fp:strict is meant to imply strict compliance with some standard, but MSDN talks about /fp:precise maintaining enough precision to be within "strict ANSI compliance" as well (under Annex F? Or perhaps they mean within Annex E's epsilon precision requirements...) MSVC (2008-2013) doesn't appear to define __STDC_IEC_559__ which would definitively bind it to Annex F, but it does define std::numeric_limits<...>::is_iec559 = true for float/double/long double, which at least binds it to IEC 60559...

Joky 12y ago

"invalid" is relative to a spec. You are writing in a language (usually) that specify what guarantee you get.

MaulingMonkey 12y ago
Specs have holes and ambiguities. And C++ in general likes to avoid guarantees to my frustration. In this case, we're not even guaranteed which specs apply. In this case, the C++ standard references the C standard contains the (optional/normative) Annex F referencing the IEC 60559 standard (which has the same content as IEEE 754). Annex F defines float and double in terms of the IEC 60559 single & double formats... and the standard C++ operators in terms of their IEC 60559 counterparts... and recommends long double be implemented as an extended double format (such as the 80-bit format commonly used by x86.) Annex F also mentions allowed optimizations, disallowed optimizations (involving various corner cases, rounding modes, implementation defined signaling exceptions, etc. ad infinitum). I don't see temporarily handling a double as an IEC 60559 Extended Double format anywhere on the allowed optimizations list, but I can't tell for certain if it runs afoul of any of the specifically disallowed optimizations of Annex F either. I'm guessing /fp:strict is meant to imply strict compliance with some standard, but MSDN talks about /fp:precise maintaining enough precision to be within "strict ANSI compliance" as well (under Annex F? Or perhaps they mean within Annex E's epsilon precision requirements...) MSVC (2008-2013) doesn't appear to define __STDC_IEC_559__ which would definitively bind it to Annex F, but it does define std::numeric_limits<...>::is_iec559 = true for float/double/long double, which at least binds it to IEC 60559...