Is There an Error in Round Function in R

Rounding error in R?

This is a combination of two extremely Frequently A'd Qs.

finite floating-point precision: this R FAQ 7.31, see e.g. Why are these numbers not equal? . The value gets rounded to 178379.5. It won't help if you set options(digits=22) to print numbers to more decimal places; the precision has been lost because (as you suggested) R only stores values up to 53 binary/22ish decimal digits of precision.
round to even: R "rounds to even", see Is there an error in round function in R? . That means the value will be rounded up.

This is not about printing precision.

If you had used fewer '9's, you would have seen what you expected (which would be a combination of R's limited printing precision plus the expected rounding)

> x <- 178379.49
> 
> x
[1] 178379.5  ## prints as .5, but full precision is present
> round(x)
[1] 178379

Error in either `/` or round functions from base R

?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’).

Problem with round() function in .Rmd exercise file

TL;DR: Use fmt(Value, 2) instead of round(Value, 2). This avoids problems with scientific notation (and uses rounding away from zero). See ?fmt for more details.

The reason for the error is actually not the round() function per se, but the fact the R by default uses scientific notation for numbers with a certain number of significant digits (factory-fresh default in R is scipen = 7). Furthermore, the knitr package (employed in the background by R/exams) tries to format this scientific notation nicely. So instead of 12000.56 the knit() function includes 1.200056 × 10<sup>4</sup> in the Markdown file. You can see this when you run xweave("example.Rmd") and then inspect the resulting example.md file. And then the subsequent processing of the exsolution tag hence has problems to convert this back to a number, hence the warning.

To avoid this you could increase the scipen limit within the R code of the exercise, e.g., options(scipen = 999). But this is very technical and tedious. This is one of the reasons why we have written the fmt(...) function that carries out various convenience tasks that have to do with formatting of numbers within R/exams exercises.

rounding up error in R with data type error

Its hard to tell from your question, but first convert your variables to numeric like this:

mtcars$mpg <- as.numeric( as.character( mtcars$mpg))

And is this what you mean by rounding up

ceiling( mtcars$qsec )
round( mtcars$disp , -1  )

Round function no longer works with mice output

I don't know exactly why this would have changed, but the NEWS file for mice says in version 3.8

There is now a more flexible pool() function that integrates better with the broom and broom.mixed packages.

It makes sense that row names would have been changed to a term column instead, as this is more compatible with tidyverse machinery (like broom and broom.mixed).

You can ask R to round all but the first column:

ss <- summary(pool(model), conf.int = TRUE, exponentiate = TRUE)
ss[-1] <- round(ss[-1],2)
ss
##          term estimate std.error statistic     df p.value  2.5 %  97.5 %
## 1 (Intercept)   670.98      0.48     13.69 143.68    0.00 262.19 1717.15
## 2 Sepal.Width     0.80      0.15     -1.44 143.36    0.15   0.59    1.09

If you like tidyverse you could

mutate_if(ss,is.numeric, round, 2)