Excellent reason, Duncan. R does not have an unlimited integer type as in
Python so truncating or rounding activities can well produce a result that
would be out of bounds.
If someone really wants an array of integers, other than efficiency reasons,
they could process the output from something like floor carefully to see if
all number returned were less than .Machine$integer.max (and similarly for
negatives in the other direction) and then have the option to make a vector
of as.integer(whatever) for later uses. If any numbers where out of the
range, they could presumably do other things like make then NA or Inf or
switch to some larger integer format they can find or create. Of course, any
such alterations may well not work well if fed to anything not expecting
them.
Now consider the purpose of the R functions round(), floor(), ceiling() and
trunc() and perhaps even signif() taken as a group. Clearly some of them can
be used only in a floating point context as rounding something to three
significant digits beyond the decimal point will not usually result in an
integer. Sure, some of them are normally used in real life to mean round it
to the nearest integer and in those cases it could be reasonable to have a
function with a restricted domain that maps into the restricted integer
range. You can make your own such function easily enough.
-----Original Message-----
From: R-devel <r-devel-boun...@r-project.org> On Behalf Of Duncan Murdoch
Sent: Saturday, January 1, 2022 3:04 PM
To: Colin Gillespie <csgilles...@gmail.com>; r-devel@r-project.org
Subject: Re: [Rd] Documentation for floor, ceiling & trunc
On 01/01/2022 2:24 p.m., Colin Gillespie wrote:
> Hi,
>
> The documentation for floor, ceiling and trunc is slightly ambiguous.
>
> "floor takes ... and returns a numeric vector containing the largest
> integers ..."
>
> My initial thought was that floor() would return a vector of integers.
That would be described as "an integer vector". I think the docs are pretty
consistent about this: if an output is described as "a numeric vector",
that's the type you get. ("numeric" and "double" refer to the same type in
R. This naming inconsistency is discussed in the ?double help page.)
> Instead, it returns a vector of doubles, i.e c(1L, 2L) vs c(1, 2)
>
> * Could the docs be changed
> * Would it be worth returning integers instead?
The range of inputs is much larger than the range of 32 bit integers, so
this would just make things more complicated, and would mean that code that
cares about the difference between numeric and integer would need extra
tests.
For example 3e9 + 0.1 is not an integer, and if you take the floor you get
3e9. That number can't be represented in the integer type, but can be
exactly represented as a mathematical integer in the numeric/double type.
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
