<p>Hi,</p> <p>I try to round 2100.825 to 2100.83 but get always 2100.82. Here is the code </p> <pre><code>package main import ( "fmt" "math" ) func main() { fmt.Println("Expecting 2100.83, but was:", round100(2100.825)) } func round100(x float64) float64 { a := x * 100 _, rem := math.Modf(a) fmt.Println("frac:", rem) if rem >= 0.5 { fmt.Println("ceil") a = math.Ceil(a) } else { fmt.Println("floor") a = math.Floor(a) } return a / 100 } </code></pre> <p>If I modify the number to 1100.825 it is properly rounded to 1100.83.</p> <p>Where is the flaw? And what is the correct implementation of round100?</p> <hr/>**评论：**<br/><br/>ElliottStoneham: <pre><p>The problem is not with your program, it is that the float64 representation of 2100.825 is not exact. Try:</p> <pre><code>fmt.Printf("%4.24g",2100.825) </code></pre></pre>coldDragonBreath: <pre><p>For the lazy <a href="https://play.golang.org/p/YBJeUP73tp" rel="nofollow">playground</a>:</p> <p><em>fmt.Printf("%4.24g",2100.825)</em> yields <em>2100.82499999999981810106</em></p></pre>pdq: <pre><p>Are you trying to work with currency or decimal values?</p> <p>If so, I'd strongly suggest to stay away from floating point (which rounds) and use a decimal-type struct instead, like <a href="https://github.com/shopspring/decimal">https://github.com/shopspring/decimal</a></p></pre>a4st: <pre><p>Yes, you are right, I'm working with currency. I will try out the library you suggest. But I'm still interested why is it only about this "magic" number?</p></pre>coldDragonBreath: <pre><p>It's the classic Programming showcase of why: (0.1 + 0.2 != 0.3)</p> <p>If you want to get into the maths behind it, google and search "IEEE 754"</p></pre>thockin: <pre><p>Yeah, don't use FP for currency. Use the smallest integral unit you care about. E.g. cents or millicents or microcents or ..</p></pre>tmornini: <pre><p>A good decimal package is a far better idea than using integers.</p></pre>a4st: <pre><p>What about using math/big.Rat?</p></pre>joushou: <pre><p>TL;DR: Never use floating point if rounding errors (small or large) are a concern. Accurate math requires integers and safe integer operations (addition, subtraction, multiplication).</p> <p>Floating point can only represent some values precisely due to its design. In its simplified form, a floating point value is calculated as s * b<sup>e,</sup> where s is the significand, e is the exponent and b is the base. In our case, the base is two, turning it the equation into s * 2<sup>e.</sup> You can't express the value 1/3 using when the base is 2, although you can get awfully close if with some crazy large and obscure values of s and e.</p> <p>Also note that using integer operands is not enough, but you may only use "safe" integer operations if you need to maintain an accurate value. A division of integer operations always rounds towards zero—that is, 2/3 yields 0—which is basically a guaranteed rounding error. Likewise, casting a floating point value to an integer also round towards zero.</p></pre>tmornini: <pre><blockquote> <p>Never use floating point if rounding errors (small or large) are a concern. Accurate math requires integers and safe integer operations</p> </blockquote> <p>Or, better yet, a decimal package.</p></pre>tmornini: <pre><p>The way floating point values work is that they take a big number range, and break it up into as many buckets as there are bits in the representation.</p> <p>So, as a thought experiment -- because this is NOT the way it's actually done, simplification to aid in understanding -- imagine you had a 3 bit floating point number that represented values between -75 and 75.</p> <p>The first bit represent positive or negative. I'll use 0 for positive values, 1 for negative values.</p> <p>The ONLY values representable would be:</p> <pre><code>011 = 75.0 010 = 50.0 001 = 25.0 000 = 0.0 100 = -18.75 101 = -37.5 110 = -56.25 111 = -75.0 </code></pre> <p>And here's the point: those are the ONLY numbers that can be represented in this "floating point" system.</p> <p>If you use 32 bit floats, 2<sup>32</sup> numbers are representable. With 64 bit floats, 2<sup>64</sup> numbers are representable.</p> <p>As far as floats are concerns, all numbers that do not happen to be represented, simply don't exist!</p> <p>Here's a concrete example in the <a href="https://play.golang.org/p/-oENvtuLSB" rel="nofollow">Go Playground</a></p></pre>mjibson: <pre><p>In addition to the shopspring package already posted, <a href="https://godoc.org/github.com/cockroachdb/apd" rel="nofollow">apd</a> is another decimal package that does <a href="https://godoc.org/github.com/cockroachdb/apd#example-Context-Quantize" rel="nofollow">similar things</a>, but also supports various <a href="https://godoc.org/github.com/cockroachdb/apd#pkg-constants" rel="nofollow">kinds of rounding</a>.</p></pre>gobdgobd: <pre><p>Seems to work for me if I add this after your Modf line</p> <pre><code>rem, _ = strconv.ParseFloat(fmt.Sprintf("%.1f", rem), 64) </code></pre></pre>
