I think there was a similar discussion to this when I raised the issue of
interpreting the sort order for an object versus its underlying type. In
this anyNA example it is the is.na for the object versus the is.na for the
type, whereas in the discussion below, which Gabriel Becker raised, it was
> Harvey Smith
> on Wed, 1 May 2019 03:20:55 -0400 writes:
> Inside of the anyNA() function, it will use the legacy any(is.na()) code
if
> x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(),
but
> it is also TYPEOF(x) == REALSXP. Therefore, it will s
On Wed, May 1, 2019 at 7:45 AM Harvey Smith wrote:
>
> Inside of the anyNA() function, it will use the legacy any(is.na()) code if
> x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but
> it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster
> ITERATE_BY_REGIO
Inside of the anyNA() function, it will use the legacy any(is.na()) code if
x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but
it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster
ITERATE_BY_REGION, which is typically 5x faster in my testing.
Is the OBJECT(
