4
$\begingroup$

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++?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ This is a question about code portability, not numerical stability. Numerical stability is a property of algorithms, not implementations. $\endgroup$
    – David Richerby
    Commented Sep 15, 2014 at 19:55
  • $\begingroup$ The case of "long double" floating point type (in c, not 100% sure about c++ but the compilers are usually the same!) is interesting here, and I use the different implementations on various platforms to my advantage! On x86-64 architectures (and also ix86 I think) you get an 80-bit hardware float. On 32-bit ARM (e.g. Raspberry Pi) you get 64-bit hardware float, but on 64-bit ARM you get 128-bit software floats. Each of these precisions suits one mode of operation or another of my ODE simulation software, so I use the appropriate hardware for each use case. $\endgroup$
    – m4r35n357
    Commented Sep 19, 2023 at 11:47

1 Answer 1

Reset to default
6
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • 3
    $\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
    Commented Jun 9, 2014 at 8:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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