This question already has answers here:
ruby floating point errors
(3 answers)
Closed 10 years ago.
I am having an issue with adding floating point numbers to time in ruby. In the example below, how is t2 not equal to 2013-02-15T01:17:17.996000000?
irb(main):094:0> t1.strftime("%Y-%m-%dT%H:%M:%S.%N")
=> "2013-02-15T01:16:47.785000000"
irb(main):095:0> t2 = t1 + 30.211
=> 2013-02-15 01:17:17 -0700
irb(main):096:0> t2.strftime("%Y-%m-%dT%H:%M:%S.%N")
=> "2013-02-15T01:17:17.995999999"
This is mainly about floating-point arithmetic.
Try 1.4 - 1.3 in the ruby shell.
What Every Computer Scientist Should Know About Floating-Point Arithmetic
This has been discussed before. You should check the following thread:
ruby floating point errors
Related
This question already has answers here:
Why does floating-point arithmetic not give exact results when adding decimal fractions?
(31 answers)
Closed 6 years ago.
Given 3^5 (3**5 or 3*3*3*3*3) = 243.
Why/how does Ruby do the following:
n = 243
Math.log(n,3)
returns:
4.999999999999999
Math.log(243)/Math.log(3)
returns:
4.999999999999999
3**Math.log(n,3)
returns:
242.99999999999977
That last one really gets me. Something is going wrong here? I'm missing something? Both?
Thanks!
Values are not wrong, this is because floating point precision is limited.
This question already has answers here:
ruby floating point errors
(3 answers)
Closed 7 years ago.
Can someone explain to me why:
33.8 * 100 # => 3379.999999999995
but
23.8 * 100 # => 2380.0
Floating-point numbers cannot precisely represent all real numbers, and floating-point operations cannot precisely represent true arithmetic operations, this leads to many surprising situations.
I advise to read: https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
You may want to use BigDecimal to avoid such problems.
This question already has answers here:
Why is division in Ruby returning an integer instead of decimal value?
(7 answers)
Closed 8 years ago.
Hi I have the following question:
When I put (1+7/100) in ruby it gives 1.
This is very strange because normally this is how I calculate a 7% increase in Excel.
But when I put (1+7.0/100) it gives me 1.07 which is the correct answer I expected.
Why is ruby doing this? And how do you solve this issue in your calculations in ruby?
This has nothing to do with rounding.
Ruby does division differently on float than it does on an integer.
If you divide integers, you will always get an integer result.
If you divide with floats (or a mixture of integer and float), you will always get a float result.
Remember your order of operations, too. Ruby is going to handle the division before it handles the addition.
7/100 = 0 so 1+0 = 1
7.0/100 = 0.07 so 1+0.07 = 1.07
This question already has answers here:
Float precision in ruby
(2 answers)
Closed 8 years ago.
When I add two floats in an irb console, the result is not as expected
10.43 + 4.56 # should be 14.99
But the actual result is
irb(main):001:0> 10.43+4.56
=> 14.989999999999998
What causes this?
This is expected behavior. Floats are not guaranteed precision because, in short, computers are binary systems (as of 2013) and cannot correctly represent fractional values. This is why you get "unexpected" results, when in reality this is how it will work until there is a non-binary machine that can correctly represent fractional values.
This question already has answers here:
Addition error with ruby-1.9.2 [duplicate]
(2 answers)
Closed 4 years ago.
Whats wrong here? (ruby version: 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.0]
x = 523.8
w = 46.9
xm = x + w
assert_equal w, (xm - x) # FAILS with: <46.9> expected but was <46.89999999999998>
From The Floating-Point Guide:
Why don’t my numbers, like 0.1 + 0.2 add up to a nice round 0.3, and
instead I get a weird result like 0.30000000000000004?
Because internally, computers use a format (binary floating-point)
that cannot accurately represent a number like 0.1, 0.2 or 0.3 at all.
When the code is compiled or interpreted, your “0.1” is already
rounded to the nearest number in that format, which results in a small
rounding error even before the calculation happens.
Read the linked-to site for details and ways to get around this.
This is perfectly normal; it is a fact about the lower-level concept of floating point arithmetic rather than Ruby and therefore can occur in any language.
Floating point arithmetic is not exact. Equality should be replaced with closeness along the lines of assert((xm-x).abs < epsilon), where epsilon is some small number like 0.01.
Read this. It describes the way binary representation of floating point numbers work in every language, not just Ruby.
The answer to your question is: No.
(Other answers tell you why, but you didn't ask that. :p)