Also, the na.omit method for data.frame with list column seems to be
inconsistent with is.na,
> L <- list(NULL, NA, 0)
> str(f <- data.frame(I(L)))
'data.frame': 3 obs. of 1 variable:
$ L:List of 3
..$ : NULL
..$ : logi NA
..$ : num 0
..- attr(*, "class")= chr "AsIs"
> is.na(f)
na.omit is documented as "na.omit returns the object with incomplete cases
removed." and "At present these will handle vectors," so I expected that
when it is used on a list, it should return the same thing as if we subset
via is.na; however I observed the following,
> L <- list(NULL, NA, 0)
> str
Thank you,
I guess I should convert double to uint64_t instead of int64_t...
The reason why I asked is because bit64 package `bit64::as.integer64(2^63)`
produces different results on my machine vs. another server. This package
converts double to int64_t directly. Looks like this is a bug in the
Dipterix,
this has nothing to do with R. 2^63 is too large to be represented as singed
integer, so the behavior is undefined - to quote from the C99 specs (6.3.1.4):
"If the value of the integral part cannot be represented by the integer type,
the behavior is undefined."
Your subject doesn't
Hi,
I was trying to convert REALSXP to int64_t in C, then found that converting
2^63 is inconsistent across platforms:
On M1 ARM osx, 2^63 (double) bit converting to `int64_t` becomes
9223372036854775807
On x86_64 ubuntu server, 2^63 (double) bit converting to `int64_t` is
-92233720368547758
On Wed, 11 Aug 2021, Martin Maechler wrote:
I'm diverting this from R-help to R-devel,
because I'm asking / musing if and if where we should / could
change R here (see below).
Martin Maechler on 11 Aug 2021 11:51:25 +0200
Tim Taylor .. on 08:45:48 + writes:
>> Manipulating formula
I'm diverting this from R-help to R-devel,
because I'm asking / musing if and if where we should / could
change R here (see below).
> Martin Maechler on 11 Aug 2021 11:51:25 +0200
> Tim Taylor .. on 08:45:48 + writes:
>> Manipulating formulas within different models I notice the
