<p>Hi all,</p>
<p>I am currently interested in floating point determinism in golang - especially cross platform.
As golang adheres to the IEEE-Standard, this should be a given, with the exception of possibilities like compiler optimisations and/or different libraries (e.g. for square roots) which are imported from C.</p>
<p>Unfortunately I couldnt find much about that topic - does any of you know more about it?</p>
<hr/>**评论：**<br/><br/>epiris: <pre><p>I'm sure you have a underlying motivation for asking which you probably should include. But a direct answer would be yes, Go implements the baseline recommendations in <a href="https://golang.org/pkg/builtin/#float64" rel="nofollow">ieee-754</a>. But you will want to probably read up on Go specification (its short and simple) around numeric conversions I'm sure they will become relevant in real world usage of them.</p></pre>therealfakemoot: <pre><p>As I understand the situation, Golang will compile numeric code involving floats to IEEE-754 compliant code on the architectures that support it; architectures that do not support IEEE-754 or offer "different"-precision operations are a little more open ended. Golang's <a href="https://golang.org/pkg/math/big/" rel="nofollow">math.big</a> library offers arbitrary precision Floats and in theory that code might be compiled to use special instruction sets on CPUs that support it.</p>
<p>Disclaimer: Not a Golang core developer or CPU architect.</p>
<p>Perhaps your question could be more meaningfully answered if you narrowed down your query. What exactly is the problem you're having, or trying to solve? Do you have some sample code to look at? A minimal reproducing case would be helpful as a starting point.</p></pre>Poe_Account_Whatever: <pre><p>I do not have code yet, I am still in the "gathering options" phase.
I will need my code to run perfectly reproducible with the exact same output on multiple different pcs.</p>
<p>My current options are:
1) Implement everything using fixed point arithmetic. Would be lots of extra work I would like to avoid.
2) Make use of fp-determinism in golang (if it exists).
A big problem with fp determinism is, that while the same calculation always gets the same result in ieee-754, a compiler might make optimisations. (a+b)+c != a+(b+c) after all (when floats are considered).</p>
<p>As it stands now, I will write some test-suite to check if fp-operations are deterministic in golang.
Something like a guarantee / test from someone else would have helped here and is what I was going for when asking the question.</p></pre>therealfakemoot: <pre><p>That's a tough one. A lot of the appeal ( or perhaps even the "point" ) of Golang is that it allows you to think at a high level and the Golang language and compiler deal with abstracting it down into an efficient program on-metal.</p>
<p>Perhaps inlining ASM code would provide a suitable amount of control over your mathematical operations; I have no direct knowledge of the feature so I may be off base. The Golang ASM is an 'abstracted'/generalized version of ASM that ALSO gets compiled down more intelligently.</p>
<p>Another option might be to write your numerical code in C and leverage that from your Golang project. I imagine you can very strictly control handling at the C level. I'm not sure exactly what your project involves but hypothetically, if you just define add, subtract, divide, multiply, modulo, and then leverage those "fundamentals" in your Go code you could provide determinism, i.e. once you have add() and divide() you could write a fp-deterministic avg() function in <em>Golang</em> allowing for type safety and the associated optimizations without losing your determinism.</p>
<p>Most of this is wild-ish speculation, I've got little experience worrying about things like this but I would like to think I've got a decent grasp of abstracting your project into meaningful, useful components.</p>
<p>Edit: I also forgot that you can embed FORTRAN in your Golang code as well; that may be an avenue worth pursuing. I found <a href="https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/" rel="nofollow">this</a> article that waxes quite poetic about all the potential pitfalls and conditions involved in fp-determinism.</p></pre>PaluMacil: <pre><p>That article was a lot to make it through, but the writing is very easy to understand, and the information was quite interesting!</p></pre>
