Say I am using boost or the built-in float or double mathematical libraries of my C++ compiler.

I distribute the program.

Will the execution of my C++ program on different machines given different floating point results given that the FPU is CPU specific and AMD may not return exactly the same thing as Intel or ARM.

Should I use fixed-point algorithms to circumvent this possibility?

Would the answer be different if my program was written in something other than C++?

  • 1
    $\begingroup$ This is a question about code portability, not numerical stability. Numerical stability is a property of algorithms, not implementations. $\endgroup$ Sep 15, 2014 at 19:55

1 Answer 1


As long as you execute the same machine code on the different machines and as long as the settings for the floating point unit are identical, you will get identical results. However, you cannot execute the same machine code on both Intel and ARM, so this answer is only hypothetic. Even on different Intel processors you have to take special care that exactly the same machine code gets executed. Some third party libraries like Intel-MKL use different machine specific code on different processors, and other libraries like FFTW measure speed at runtime, and select different algorithms (and hence different code) based on the outcome of these measurements.

Sometimes the compiler is able to inline a certain function (for example your rounding logic), and then you can end up with different results for identical input to that function at different parts of your code. Another very real non-reproducability for distributed floating point computations are potential reductions are the end of the computation. Because the result here depends on the order of the reduction steps, it is very easy to end up with slightly non-repreducible results.

I have run into the issues in the past, but never considered this to be a reason to switch to fixed-point algorithms. For robustness problems of "computational geometry" related code on the other hand, I consider integer or fixed point arithmetic to be an appropriate solution.

Should I use fixed-point algorithms to circumvent this possibility?

In conclusion, there are several issues related floating point numbers, and even some problems where floating point numbers are not the most appropriate solution, but in general floating point arithmetic is still the way to go. So no, you should not abandon floating arithmetic in general, but only in the specific cases where it causes unsurmountable robustness problems.

  • 2
    $\begingroup$ Even running the same machine code could yield different results at different times. Some runtime libraries set FP flags (like rounding mode) differently from what they were. So your program could execute some C++ code, load a Delphi COM object, then run the same C++ code again (with the same inputs) and get a different result from the previous time. $\endgroup$
    – Gabe
    Jun 9, 2014 at 8:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.