Does Ruby have a bug in its rounding? Why does it behave like this:
>> [1.14, 1.15, 1.16].map{|x| "%.1f" % x}
=> ["1.1", "1.1", "1.2"]
>> [1.4, 1.5, 1.6].map{|x| "%.0f" % x}
=> ["1", "2", "2"]
as in, why does 1.15 get rounded to 1.1, but 1.5 gets rounded to 2? At the very least, isn't this inconsistent? the behaviour is the same in ruby 1.9.1 and ruby 1.8.7.
Take a look at my answer to this question
Why does Perl's sprintf not round floating point numbers correctly?
This may be the same thing
You're using floating point numbers. Floating point numbers aren't precise. See http://en.wikipedia.org/wiki/IEEE_754-2008 for an introduction in the standard.
The short version is: NEVER use floats for anything where you need precision in any way!
It's useful to recall and also quite ironic to contemplate, but floating point numbers only represent exactly: (a) a few fractions or (b) all integers.
So, to have an exact representation a fraction must be composed of (negative) powers of two. So, the following fractions are the only ones between .01 and .99 that are exactly represented:
0.25
0.50
0.75
In other words, FP is perfectly accurate when dealing with integers. Go figure.
Related
Here what's bringing me trouble:
irb> (0.5).round # => 1 YES
irb> (0.075).round(2) # => 0.08 YES
irb> (9.075).round(2) # => 9.07 WHY???
What is going on? How come the result isn't 9.08?
Floating point is tricky. The decimal 9.075 can't be exactly represented as a float. This isn't specific to ruby.
The rounding algorithm in most cases (not including nans and the like) works by multiplying the number by the appropriate power of 10, rounding, and then dividing by that same number. That multiplying by 10 results in some loss of precision.
Floating point number can not represent all number precisely. I advise to read Floating Point - Representable numbers, conversion and rounding.
Since Ruby 2.2 you can use prev_float and next_float to see which are the cloased representable floating points to a given number:
9.075.prev_float
#=> 9.074999999999998
9.075.next_float
#=> 9.075000000000001
As you see 9.075 is between to 9.075000000000001 and 9.074999999999998, therefore the mean is at 9.0749999999999995 and therefore 9.075 rounds down to 9.07.
This has to deal with the way ruby deals with Float. If you convert to Rational it rounds to the closest number : (0.075).to_r.round(2) #=> (7/100) and 9.075.to_r.round(2) #=> (907/100)
More details on the floating point logic (logic used to internaly store floats) : https://en.wikipedia.org/wiki/Floating_point
Weird..
$ (9.95*100).to_i
=> 994
And then,
$ (9.95*100).round.to_i
=> 995
It seems like the floating point value is (approximately) 9.9499999... and
to_i
chops the decimal value, hence the 994.
But does anyone know why?
Read more about the problems with accuracy here: https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
Short version: Never use floats as representation for currencies.
Your call to #round is rounding it "up" from (its internal representation of 9.95, which is a number slightly inaccurate and just below it). So that one works, whereas calling straight #to_i just (always) truncates, so it sees 994.99999 and truncates it down to 994. With Ruby 1.9.x+ it shows this more plainly (for better or worse), so you can see what is going on.
>> 9.95*100
=> 994.9999999999999
>> (9.95*100).round
=> 995
Why is the following operation leading me to this value:
14.99 + 1.5 = 16.490000000000002
I would expect it to be 16.49. How can I avoid those extra decimals?
That's how floating point arithmetic works. If you want a rounded number that's still a Float object, you can do
result.round(2) #=> 16.49
or if you just need a string:
"%0.2f" % result
This is not due to Ruby, but because of the way floating point numbers are represented in a computer (according to the IEEE 754 standard).
In short, some floating point numbers just can't be represented exactly in a computer. If you need better precision, you can try the BigDecimal class.
ree-1.8.7-2010.02 :003 > (10015.8*100.0).to_i
=> 1001579
ree-1.8.7-2010.02 :004 > 10015.8*100.0
=> 1001580.0
ree-1.8.7-2010.02 :005 > 1001580.0.to_i
=> 1001580
ruby 1.8.7 produces the same.
Does anybody knows how to eradicate this heresy? =)
Actually, all of this make sense.
Because 0.8 cannot be represented exactly by any series of 1 / 2 ** x for various x, it must be represented approximately, and it happens that this is slightly less than 10015.8.
So, when you just print it, it is rounded reasonably.
When you convert it to an integer without adding 0.5, it truncates .79999999... to .7
When you type in 10001580.0, well, that has an exact representation in all formats, including float and double. So you don't see the truncation of a value ever so slightly less than the next integral step.
Floating point is not inaccurate, it just has limitations on what can be represented. Yes, FP is perfectly accurate but cannot necessarily represent every number we can easily type in using base 10. (Update/clarification: well, ironically, it can represent exactly every integer, because every integer has a 2 ** x composition, but "every fraction" is another story. Only certain decimal fractions can be exactly composed using a 1/2**x series.)
In fact, JavaScript implementations use floating point storage and arithmetic for all numeric values. This is because FP hardware produces exact results for integers, so this got the JS guys 52-bit math using existing hardware on (at the time) almost-entirely 32-bit machines.
Due to truncation error in float calculation, 10015.8*100.0 is actually calculated as 1001579.999999... So if you simply apply to_i, it cuts off the decimal part and returns 1001579
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
>> sprintf("%.16f", 10015.8*100.0)
=> "1001579.9999999999000000"
And Float#to_i truncates this to 1001579.
Why does round() do a better job than the printf type of string formatting?
ruby-1.9.2-p0 > "%.0f" % 14.5
=> "14"
ruby-1.9.2-p0 > "%.0f" % 14.5000001
=> "15"
ruby-1.9.2-p0 > 14.5.round
=> 15
Just because you've learned in school that .5 is always rounded up does not mean that's the only correct way to do it. There are quite a number of different rounding modes; what you're looking at is most likely "round to even", which rounds .5 towards the even integer; this has the advantage of not producing an overall upwards bias like always rounding up does.
High-quality math libraries like Ruby Flt generally provide a way to explicitly choose the rounding mode.
"Better job"? No, not if you care about things averaging out. Hence, round towards even.