Why are the following all "numeric"
?
class(ceiling(3))
class(ceiling(3L))
class(ceiling(3.1))
class(floor(2))
class(floor(2L))
class(floor(2.1))
This seems like one arithmetic operation where the result is unambiguously an integer (unlike, say, exponentiation), regardless of inputs (it's an error to pass a complex number).
I tried poking around for an answer related in the underlying C
code but didn't really get anywhere.
I also learned that, while "%/%"(x,y)
should also always be an integer, the class
of the results depends on the input types, e.g. 5%/%2
, 6%/%2
and 6%/%2L
are all numeric
, but 5L%/%2L
and 6L%/%2L
are both integer
(something about this is mentioned in ?Arithmetic
); this doesn't really make sense to me either, but at least it's documented.
Is there a simple reason for returning numeric
objects from ceiling
and floor
? If it were about inefficiency due to re-casting (which seems may be the case for integer division), I would expect class(ceiling(3L))
to be "integer"
, so what's going on?
I don't know if this is why ceiling
was designed to return numeric
, but the following example shows the limitations ceiling
would have if it actually returned an integer:
options(digits = 15)
.Machine$integer.max + 1.4
#[1] 2147483648.4
ceiling(.Machine$integer.max + 1.4)
#[1] 2147483649
as.integer(ceiling(.Machine$integer.max + 1.4))
#[1] NA
#Warning message:
#NAs introduced by coercion
That said, there is no good reason that I see why ceiling
doesn't return an integer when given an integer input.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With