This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 3 years ago.
I am using a Math.Round function to round the decimal numbers with a precision of 3 digits, but for some equations it gives a wrong result.The code given below gives me a wrong result.It gives 1.428 but the expected result is 1.429
Math.Round(28.57 * 5.0 / 100, 3, MidpointRounding.AwayFromZero)
I got the right answer by just putting 5.0 / 100 in a bracket.The code given below gives 1.429
Math.Round(28.57 * (5.0 / 100), 3, MidpointRounding.AwayFromZero)
I don't understand why it is happening like this. Can you explain this?
Usually, floating-point numbers may not have an "exact" representation for the number, so they loose precision.
For your example, if you tried to subtract the values in both expressions, you will get a very very small result.
Related
This question already has answers here:
Round up from .5
(7 answers)
Closed 1 year ago.
There are a number of threads about this question. None seems to answer the simple question: why does R round incorrectly and how can I let it round correctly?
Correct rounding to the i-th decimal x considers the i+1-th decimal. If it is 5 or larger then x is is set to x+1. If it is 4 or smaller then x is returned. For example 1.45 is rounded to the first decimal as 1.5. 1.44 is rounded 1.4. However, in R
> round(1.45,1)
[1] 1.4
But
> round(1.46,1)
[1] 1.5
So it changes the convention to 'if the i+1th decimal is 6 or larger, then x is set to x+1'. Why? And how can I change this to the convention I am familiar with?
Most decimal fractions are not exactly representable in binary double precision
Learned here: https://stat.ethz.ch/R-manual/R-devel/library/base/html/Round.html
Section "Warnings":
Rounding to decimal digits in binary arithmetic is non-trivial (when digits != 0) and may be surprising. Be aware that most decimal fractions are not exactly representable in binary double precision. In R 4.0.0, the algorithm for round(x, d), for d > 0, has been improved to measure and round “to nearest even”, contrary to earlier versions of R (or also to sprintf() or format() based rounding).
This question already has answers here:
Why are these numbers not equal?
(6 answers)
Closed 2 years ago.
I came across a strange thing in R programming. When I simulate a sequence and want to judge whether the element is less than 0.5,
t=(1:1440)/1440
x=(t[720]-t[648])/0.1
x
#output:[1] 0.5
x<1/2
#output:[1] TRUE
x=0.5
x<1/2
#output:[1] FALSE
The two results are completely opposite and obviously the second result is what I want. Can anybody help me?
Floating point arithmetic is not exact in R, and the value you expect to be numerically exact to 0.5 may in fact be slightly more (or less). One possible workaround here would be to use rounding:
t <- (1:1440)/1440
x <- (t[720]-t[648]) / 0.1
round(x, 1) < 0.5
This question already has answers here:
How can I disable scientific notation?
(4 answers)
Why are these numbers not equal?
(6 answers)
Closed 3 years ago.
I have just started with R and am stuck on this bug.
fuel_efficiency<-c(28.2, 28.3, 28.4, 28.5, 29.0)
mean=28.48
deviation<-(fuel_efficiency-mean)
deviation
sum(deviation)
I have written this code to subtract the mean from the elements of the fuel efficiency vector to get the deviation vector. Then am trying to get the sum of the updated deviation vector.
The sum answer should return 0 but instead gives something like -3.552714e-15
The deviation vector is printed properly as expected.
#[1] -0.28 -0.18 -0.08 0.02 0.52
This are just rounding errors, -3.552714e-15 is a very, very small number:
Computers are notoriously bad at handling decimal numbers, (one could even say they are just not able to do it exactly). To overcome this R provides a function to check for equality:
all.equal(sum(deviation), 0)
This returns:
[1] TRUE
format(sum(deviation), scientific = FALSE)
Your answer is very close to zero. It's a rounding error. R uses IEEE 754 double-precision floating point numbers. Read more here: https://en.wikipedia.org/wiki/Double-precision_floating-point_format
This question already has answers here:
Why are these numbers not equal?
(6 answers)
Closed 3 years ago.
I have been trying to make a contribution to the data.table package by adding the round function to the ITime class, when i came across a rather odd discrepancy produced by the round function. Behind the scenes, an object of class ITime is just an integer vector with pretty formatting, and thus unclass(object) provides an integer vector.
Rounding this integer vector to the nearest minute can thus be done like this:
x <- as.ITime(seq(as.POSIXct("2020-01-01 07:00:00"), as.POSIXct("2020-01-01 07:10:00"), "30 sec"))
round(unclass(x) / 60L) * 60L
# or
round(as.integer(x) / 60L) * 60L
Here is where the problem comes...
When I do this operation, I would expect any instance of unclass(x) / 60 that ends with .5 to be rounded up. However, that is not the case!
I have tried the example on both Windows and Mac on two different computers with the same result. Does anyone have an idea as to why this would happen?
** FYI I know that this particular problem can be solved differently: unclass(x) %/% 60L. But my interest is in why the round function does not work as expected.
?round:
‘round’ rounds the values in its first argument to the specified
number of decimal places (default 0). See ‘Details’ about “round
to even” when rounding off a 5.
[...]
Note that for rounding off a 5, the IEC 60559 standard (see also
‘IEEE 754’) is expected to be used, ‘_go to the even digit_’.
Therefore ‘round(0.5)’ is ‘0’ and ‘round(-1.5)’ is ‘-2’. However,
this is dependent on OS services and on representation error
(since e.g. ‘0.15’ is not represented exactly, the rounding rule
applies to the represented number and not to the printed number,
and so ‘round(0.15, 1)’ could be either ‘0.1’ or ‘0.2’).
This question already has answers here:
Round up from .5
(7 answers)
Sometimes rounding number are not consistent [duplicate]
(2 answers)
Closed 3 years ago.
R fails to round the number "126.5". I discovered this by accident.
round(125.5) # = 126, correct
round(126.5) # = 126, wrong
round(127.5) # = 128, correct
I expect that the output of round(126.5) to be 127, but the actual output is 126. R rounds other numbers correctly (see above). Does anybody know what the problem is and how can I fix it?
From documentation ?round -
Note that for rounding off a 5, the IEC 60559 standard is expected to
be used, ‘go to the even digit’. Therefore round(0.5) is 0 and
round(-1.5) is -2. However, this is dependent on OS services and on
representation error (since e.g. 0.15 is not represented exactly, the
rounding rule applies to the represented number and not to the printed
number, and so round(0.15, 1) could be either 0.1 or 0.2).