title: Coercing floating-point to be deterministic in .NET?
body: <p>I've been reading a lot about floating-point determinism in .NET, i.e. ensuring that the same code with the same inputs will give the same results across different machines. Since .NET lacks options like Java's fpstrict and MSVC's fp:strict, <a href="https://stackoverflow.com/a/6685966/154766">the consensus seems to be</a> that there is no way around this issue using pure managed code. The C# game AI Wars has settled on using <a href="https://stackoverflow.com/a/616015/154766">Fixed-point math</a> instead, but this is a cumbersome solution.</p>
  
  <p>The main issue appears to be that the CLR allows intermediate results to live in FPU registers that have higher precision than the type's native precision, leading to impredictably higher precision results. An <a href="http://blogs.msdn.com/b/davidnotario/archive/2005/08/08/449092.aspx" rel="noreferrer">MSDN article by CLR engineer David Notario</a> explains the following:</p>
  
  <blockquote>
    <p>Note that with current spec, it’s still a language choice to give
    ‘predictability’. <strong>The language may insert conv.r4 or conv.r8
    instructions after every FP operation to get a ‘predictable’ behavior.</strong>
    Obviously, this is really expensive, and different languages have
    different compromises. C#, for example, does nothing, if you want
    narrowing, you will have to insert (float) and (double) casts by hand.</p>
  </blockquote>
  
  <p>This suggests that one may achieve floating-point determinism simply by inserting explicit casts for every expression and sub-expression that evaluates to float. One might write a wrapper type around float to automate this task. This would be a simple and ideal solution!</p>
  
  <p>Other comments however suggest that it isn't so simple. <a href="https://stackoverflow.com/a/8795656/154766">Eric Lippert recently stated</a> (emphasis mine):</p>
  
  <blockquote>
    <p>in some version of the runtime, casting to float explicitly gives a
    different result than not doing so. When you explicitly cast to float,
    the C# compiler <strong>gives a hint to the runtime</strong> to say "take this thing
    out of extra high precision mode if you happen to be using this
    optimization".</p>
  </blockquote>
  
  <p>Just what is this "hint" to the runtime? Does the C# spec stipulate that an explicit cast to float causes the insertion of a conv.r4 in the IL? Does the CLR spec stipulate that a conv.r4 instruction causes a value to be narrowed down to its native size? Only if both of these are true can we rely on explicit casts to provide floating point "predictability" as explained by David Notario.</p>
  
  <p>Finally, even if we can indeed coerce all intermediate results to the type's native size, is this enough to guarantee reproducibility across machines, or are there other factors like FPU/SSE run-time settings?</p>