I haven't seen anyone mentioning it, but I wonder if -ffloat-store fixes this?
GNU GCC does not round floating-point divisions to the nearest value
71–80 of 87 posts
Re: GNU GCC does not round floating-point divisions to the nearest value
#72The thread comments didn't dissapoint: > someone defended gcc > someone attacked it > someone who just started learning C or C++ made a comment > someone mentioned clang did it right > someone mentioned Rust
and I got downvoted for not contributing meaningfully to the topic! The set is full
Re: GNU GCC does not round floating-point divisions to the nearest value
#73I believe the issue is that some of this ends up evaluated at compile-time, and the compiler really has no idea how to do rounding correctly at that point. When implementing floating point tests for an x86 emulator, we had to create a macro that would ensure that the calculation was done at runtime rather than at compile time for this exact reason: https://github.com/ish-app/ish/blob/18176b6931d69bdabe48f137... . If…
> If anyone knows how to control floating point rounding in C reliably, I'd be interesting in hearing it
I skimmed over that code and it seems that hack is required because a) you're not happy with what the compiler does with a double b) insisting on using a "double" type.
It's easy to get your own semantics for numbers in C, it's not easy to do so while insisting on using C's own types whose behavior are contrary to what you want.
If you want your own floating point semantics why not make a struct with a significand & base and pass that around? Something like that is how established numbers-in-C-without-native-C-semantics libraries do it, e.g. GMP.
Re: GNU GCC does not round floating-point divisions to the nearest value
#74The worst of this is that internal 80 bit x87 registers are truncated to 64 bit when written to memory. You have essentially no control over when this happens from the language level. It meant that floating point code was all rather undefined and you got different results on different compilers. As someone who has had to write multi platform numerical code I'm very thankful it's gone from AMD64.
Re: GNU GCC does not round floating-point divisions to the nearest value
#75rust (default settings, amd64) gets 0.501782303180000055
Does Rust still uses LLVM? If so, I'd tend to expect a result similar to Clang.
Re: GNU GCC does not round floating-point divisions to the nearest value
#76Earlier quoted context omitted.
Stuff like Kahan summation breaks horribly with -ffast-math, because if you assume that sum is associative the error term, which is ((s+x)-s)-x, simplifies to zero. https://en.m.wikipedia.org/wiki/Kahan_summation_algorithm
That's where you dust off volatile.
Sadly true. That's the only portable way I found to implement something akind to a Kahan sum so that no compiler / flag would destroy it.
Re: GNU GCC does not round floating-point divisions to the nearest value
#77An example where this matters -- a new Mario 64 trick on the Virtual Console version because summing round-towards-zero numbers over a sine wave cycle produces a small delta which builds up over a couple of days to make a jump possible https://www.kotaku.com.au/2018/06/the-mario-64-trick-that-ta...
Fun idea: If the universe is a simulation, then maybe dark energy is just a rounding error bug.
Re: GNU GCC does not round floating-point divisions to the nearest value
#78An example where this matters -- a new Mario 64 trick on the Virtual Console version because summing round-towards-zero numbers over a sine wave cycle produces a small delta which builds up over a couple of days to make a jump possible https://www.kotaku.com.au/2018/06/the-mario-64-trick-that-ta...
Fun idea: If the universe is a simulation, then maybe dark energy is just a rounding error bug.
According to Wikipedia:
..dark energy contributes 68% of the total energy..
Re: GNU GCC does not round floating-point divisions to the nearest value
#79As I understand it, the IEEE floating point standards do not require exact rounding for binary to decimal conversions. See What Every Computer Scientist Should Know About Floating-Point Arithmetic https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h... The behavior appears to be consistent with the standard. Keep in mind that GCC needs to provide the same result irrespective of the architecture it runs on and…
Look for the heading, “The IEEE Standard” in “What Every Computer Scientist Should Know About Floating-Point Arithmetic,” then scroll down to the subheading “Operations.” That section begins, “The IEEE standard requires that the result of addition, subtraction, multiplication and division be exactly rounded. That is, the result must be computed exactly and then rounded to the nearest floating-point number (using round to even).”
A few paragraphs later, it adds, “There is not complete agreement on what operations a floating-point standard should cover. In addition to the basic operations +, -, × and /, the IEEE standard also specifies that square root, remainder, and conversion between integer and floating-point be correctly rounded. It also requires that conversion between internal formats and decimal be correctly rounded (except for very large numbers).”
I will admit that I worked as a programmer for several years without knowing that. I learned it from a former physics professor who has now moved on to become a quant with a hedge fund. He usually didn’t worry much about it, but when he needed to be sure a particular calculation was as accurate as possible, he’d start counting individual operations and stay away from particular function calls.
Re: GNU GCC does not round floating-point divisions to the nearest value
#80Earlier quoted context omitted.
I don't think any serious compiler for AMD64 is using x87 - it's ancient history. You would have to go deliberately far out of your way to encounter this problem.
If you use long double on x86-64 Linux, you're using x87. Though that has none of the problems discussed here, as there's no rounding when spilling regs to memory.
I think using long double counts as going 'deliberately far out of your way'.