3 ms·

> But the results may change depending on: > - programming language As I mentioned in my comment, this is part of the myth. most programming languages have th

> But the results may change depending on: > - programming language As I mentioned in my comment, this is part of the myth. most programming languages have the exact same semantics regarding floating point and if you port an algorithm between them you will get identically deterministic results. this is true for at least c/c++, java, c#, python, javascript, and many more. - libraries used and their versions As I mentioned in my comment, this is the only true part of the myth. sqrt should be safe, but trig functions will be different. for games, a lot of them use there own "fast" versions anyway, so not a problem. - underlying silicon nothing to worry about here. All modern CPUs have identical IEE754 semantics (except intel 32 bit which I addressed in my original comment) - whether SIMD is used Again, nothing to worry about here, whether it is hand coded SIMD assembly, or compiler generated, you will always get identical and portable results. the compiler is obligated to ensure this for autogenerated SIMD. - FPU flags not relevant on any system from the last 10 years - compiler flags (example: ffast-math affects many things behind the scenes, as does /fp:fast, including things that dramatically affect accuracy like the use of approximate reciprocal instructions) ffast-math by definition introduces imprecise semantics so simply don't use it - bugs affecting all of the above compilers (and CPUs!) may have been buggy decades ago but in the modern age floating point is extensively tested. I would be very surprised to see a floating point related bug in a compiler or programming language from the last 10 years

benibela 5y ago
I still have these problems > - programming language I decided to not use C, because it is unsafe, and write all my code in Pascal. Now the FreePascal double parsing does not work correctly For one, it always uses 80-bit float. Even if parsing a double, then it rounds the 80-bit float to double after parsing, so the last bit is usually wrongly rounded. They refuse to fix it, because it is easier to maintain just one 80-bit float parsing function than multiple parsing functions for different types. >- libraries used and their versions So I moved to someone's double parsing library. It just did not work. It simply lacked the algorithms required for full double precision parsing But they were happy to fix it >- FPU flags After fixing it, that double parsing library still did not work ... on 32-bit Although the library was implementing the correct operations. Turned out FreePascal compiles 64-bit using SSE, and 32-bit using FPU which was set to 80-bit precision In reverse, formatting the double as string is also hard and ambiguous. FreePascal usually prints two decimal digits more than required (in the new implementation. They still had a broken implementation a handful years ago). I wrote my own implementation that prints the shortest decimal using arbitrary precision arithmetic, but that is really slow. (I tried to use a library, but that did not have enough precision, and after they tried to fix it, it is completely broken.)

benibela 5y ago

I still have these problems > - programming language I decided to not use C, because it is unsafe, and write all my code in Pascal. Now the FreePascal double parsing does not work correctly For one, it always uses 80-bit float. Even if parsing a double, then it rounds the 80-bit float to double after parsing, so the last bit is usually wrongly rounded. They refuse to fix it, because it is easier to maintain just one 80-bit float parsing function than multiple parsing functions for different types. >- libraries used and their versions So I moved to someone's double parsing library. It just did not work. It simply lacked the algorithms required for full double precision parsing But they were happy to fix it >- FPU flags After fixing it, that double parsing library still did not work ... on 32-bit Although the library was implementing the correct operations. Turned out FreePascal compiles 64-bit using SSE, and 32-bit using FPU which was set to 80-bit precision In reverse, formatting the double as string is also hard and ambiguous. FreePascal usually prints two decimal digits more than required (in the new implementation. They still had a broken implementation a handful years ago). I wrote my own implementation that prints the shortest decimal using arbitrary precision arithmetic, but that is really slow. (I tried to use a library, but that did not have enough precision, and after they tried to fix it, it is completely broken.)