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
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
>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,
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
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:
