From murdoch@dunc@n @end|ng |rom gm@||@com  Sat Jan  1 21:03:49 2022
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Sat, 1 Jan 2022 15:03:49 -0500
Subject: [Rd] Documentation for floor, ceiling & trunc
In-Reply-To: <CADbDLZkcaK+2E_KA6+NwBhXDYhKjF-KbR9YXtzt6DjDDjH7Hyg@mail.gmail.com>
References: <CADbDLZkcaK+2E_KA6+NwBhXDYhKjF-KbR9YXtzt6DjDDjH7Hyg@mail.gmail.com>
Message-ID: <5d3c433a-9711-e1a2-64cc-dadc2a4cc347@gmail.com>

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



[Rd] Documentation for floor, ceiling & trunc
Duncan Murdoch