Hmm, yes, this is probably wrong. E.g., we are likely to get inconsistencies
out of boundary cases like this
> a <- na.omit(airquality)
> sum(a)
[1] 37495.3
> sum(a[FALSE,])
Error in FUN(X[[i]], ...) :
only defined on a data frame with all numeric variables
Or, closer to an actual use case:
Peter et al,
I had the same thought, in particular for any() and all(), which in as much
as they should work on data.frames in the first place (which to be
perfectly honest i do find quite debatable myself), should certainly work
on "logical" data.frames if they are going to work on "numeric" ones
>From my side: it would be great if you (or R core) could prepare a patch, it
>would probably take me quite a bit longer than you since I don't have
>experience creating patches for R.
Best, Martin
On Sun, Oct 18, 2020, at 21:49, Gabriel Becker wrote:
> Peter et al,
>
> I had the same thought,
I happened to notice that this header file uses
#import
This is the first time I came across the preprocessor directive #import;
the first thing I found about it is this Q&A suggesting it's not portable
nor standard C:
https://stackoverflow.com/q/39280248/3576984
On the other hand, this exact
On Mon, Oct 19, 2020 at 5:02 AM Michael Chirico
wrote:
>
> I happened to notice that this header file uses
>
> #import
>
> This is the first time I came across the preprocessor directive #import;
> the first thing I found about it is this Q&A suggesting it's not portable
> nor standard C:
The Co
