I was told most modern computers follow the same floating point standard, does this mean they will all get the same float answer for a given math operation if the inputs are the same?

I ask because i am researching into making an RTS game on a network, and syncing hundreds of unit's positions sounds like a bad way to go.

So if i send just inputs only, i need to guarentee all clients get the same result by having them run the simulation from those inputs.

I read that older RTS games used fixed point arithmetic, but i don't know if that is still required on modern computers if they all adhere to the same standard? I was also told that although imprecise, the result of floating point is deterministic for the same input (which i presume means any computer following the same standard gets the same imprecise result?).

Do computers still have deviations even if they follow the same float point standard?

I am writing this game in C# not sure if that matters though, thought i'd mention it anyway.

  • Even if they did, I wouldn’t use floats for that – Telastyn Dec 10 '18 at 4:51
  • What do you mean ? Why not? – WDUK Dec 10 '18 at 4:54
  • Use of floats may be undesirable anyway because behaviour might depend on the position on the map. Minecraft's Far Lands were a more notable example: movement, rendering, and terrain generation would get glitchy as you moved far away from the spawn point. – amon Dec 10 '18 at 10:30

Do computers still have deviations even if they follow the same float point standard?

Unfortunately, yes, especially when you use C# (or another JIT compiled language). The problem which occurs here is that the JIT compilation stage on some processor architectures produces code which uses more CPU registers than on other architectures. This can lead to situations where on some machines, extended floating point precision is used for certain operations, whilst on other machines not. This means for every iterative calculation using doubles, there is a chance to produce different accumulated rounding errors.

That is not a hypothetical problem, I have first-hand experience with such deviations in contemporary engineering simulation software, on more or less modern hardware. This issue makes it really hard to create reliable regression tests for complex floating point calculations which produce exactly the same result on all machines involved.

  • This. Some root causes: IEEE Std 754 includes optional "should" clauses (e.g. NaN handling) and permits design alternatives (e.g. underflow detection). In as far as language bindings support the floating-point standard, they may still give leeway to the compiler when evaluating floating-point expressions, e.g. FLT_EVAL_METHOD in ISO C/C++. Transcendental functions (e.g. sin, exp, log) are largely unregulated by both the IEEE floating-point standard and programming language standards. A simple library version upgrade (e.g. a new glibc version) could cause results to differ. – njuffa Dec 10 '18 at 19:21
  • I've hit it myself in a game. The rocket flew fine on my laptop, would not fly on my desktop, completely identical installations. – Loren Pechtel Dec 11 '18 at 6:14

Floating Point Errors

Every floating point number accumulates imprecision as it is used for calculation. This is a simple fact of using an imprecise format to calculate in. The calculations are also sensitive to the order of calculation, commutativity is not guaranteed, ie: (a + b) + c may or may not be the same as a + (b + c).

Additionally processors do not necessarily have the same mantissa length as the memory standard. This can generate interesting behavior as the 32/64/128 bit float occasionally operate as if they have more bits.

Fixed-Point Errors

That being said fixed-point arithmetic can also accumulate errors. The difference is that fixed point numbers are clear about what precision is lost, and depending on the chosen operations can avoid rounding errors altogether. They also are commutative (a + b) + c = a + (b + c).


Which one to use depends entirely on what properties you need.

Floating point numbers:

  • give a vast range of values that become very fine grained close up, and progressively further apart at the extremes.
  • are sensitive to order of calculation
  • accumulate rounding errors over time.
  • can have erratic behaviour due to hardware/memory float size mismatch.

Fixed Point numbers:

  • give a smaller range of numbers with the same distance between any two consecutive numbers.
  • are less sensitive to the order of calculation
  • are clearer about rounding errors
  • can be worked with to minimise/avoid rounding issues.
  • 1
    "fixed point numbers are clear about what precision is lost" - floating points are clear too, the difference is rather fixed point inaccuracies are more intuitive to ordinary life numbering – whatsisname Dec 10 '18 at 5:44
  • 1
    So only fixed point guarantees all computers regardless of hardware etc will experience the same errors/precision loss? – WDUK Dec 10 '18 at 5:47
  • 1
    Essentially, yes, because you can specify that your fixed point numbers are 32 or 64 bits, and they will be on all systems. Floating point numbers may be 32 or 64-bit, but the hardware may actually use 48 or 96 bits to do the calculation and convert to 32 or 64 bits at the end resulting in differences between different types of hardware. – user1118321 Dec 10 '18 at 5:53
  • @whatsisname While the floating point specifications are quite clear, you cannot easily tell me what rounding issues I will encounter in this sum: (a + b * c) / d - e. Excepting obvious issues like NaN, division by zero, or overflow/underflow it is possible for this expression to be incorrect. Add to that the impedence between memory and register in terms of precision and even a simple load/store from memory of the "same" floating point value will change the answer. – Kain0_0 Dec 10 '18 at 7:11
  • @Kain0_0: you're right, I can't easily tell you what I'll encounter, because I am not a floating point expert. That is exactly what is meant when I said "more intuitive to ordinary life numbering". When you say fixed point is "clear" and floating point is not, you make it sound as though floats are just seemingly randomly inaccurate. – whatsisname Dec 10 '18 at 22:04

There’s the question why you would want to guarantee identical results, since identical results give no guarantee at all that your results are useful.

You could have a numerically unstable algorithm that gives two identical but completely nonsensical results in different computers. If there are differences, but results are the same within 13 digits, that is much more trustworthy.

There are very few situations where reproducibility is really important: in a layout engine, or lossless compression/decompression. Using fixed point is very likely to be misguided.

  • I did not downvote your answer, but it seems the case described by the OP is exactly "one of those few situations where reproducibility is really important". In an RTS game, a small rounding error can make the difference between "two objects collided" or not. – Doc Brown Dec 10 '18 at 16:35

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.