https://issues.dlang.org/show_bug.cgi?id=20451
--- Comment #3 from berni44 <[email protected]> --- (In reply to jacob from comment #1) > Comparing floating point numbers with "==" is in itself an error. I know. But the "==" was there first. I tried to fix the issue and when I found out, that the results where indeed the correct results and the (original) problem was because double was compared with real and real produces just better results, I added the cast. This worked for most machines... > You shouldn't be comparing approximation of numbers to see if they are exactly > the same. I agree, but it's not an approximation in this case. (Although I meanwhile solved the original stuff by using approxEqual with a large constant, so actually it's comparing for identity.) > assert(pow(xd, neg2) == cast(real) (1 / (x * x))); // cast(real) for > same type. That won't work on other computers. > // can't just cast(double) here cause pow() returns value on the FPU > // so the conversion never happens otherwise > double a = pow(xd, neg2); > assert(a == cast(double) (1 / (x * x))); I don't understand that. xd is of type F=double and the result of pow() is "Unqual!F" which is also double. FPU or not, the result should behave like a double. When casting another value to double and the results have equal bit patterns, they should be compareable with ==. > You are comparing different types, pow() returns real If it does, this is the bug. > You guessed it writefln() under the hood uses Windows' snprintf(). But hopefully not for long time anymore - see my PR: https://github.com/dlang/phobos/pull/7264 (In reply to jacob from comment #2) > Really real should mean 128-bit float, it is the next logical step over > 80-bit floats. I really, really would be happy if real would be something fixed. Real being something different on every other machine causes a lot of problems. I would even prefer if it would not exist at all, rather than this chaos. --
