Thank you Simon, this is helpful. I take this is specific to quit(),
so it's a poor choice for emulating crashed parallel workers, and
Sys.kill() is much better for that.
I was focusing on that odd extra execution/output, but as you say,
there are lots of other things that is done by quit() here,
> Dario Strbenac writes:
>
> I have a real scenario involving 45 million biological cells
> (samples) and 60 proteins (variables) which leads to a segmentation
> fault for svd. I thought this might be a good example of why it
> might benefit from a long vector upgrade.
Rather than the full SVD of
If you’re crossproding X by itself, I think passing symmetric = TRUE to
eigen will eke out more speed.
Avi
On Mon, Aug 16, 2021 at 6:30 PM Radford Neal wrote:
> > Dario Strbenac writes:
> >
> > I have a real scenario involving 45 million biological cells
> > (samples) and 60 proteins (variable
To clarify, ?is.na docs say that 'na.omit' returns the object with
incomplete cases removed.
If we take is.na to be the definition of "incomplete cases" then a list
element with scalar NA is incomplete.
About the data.frame method, in my opinion it is highly
confusing/inconsistent for na.omit to ke
Hi Toby,
Right, my point is that is.na being equivalent to "is an incomplete case"
is really only true for atomic vectors. I don't see it being the case for
lists, given what is.na does for lists. This is all just my opinion, but
that's my take: vec[!is.na(vec)] happens to be the same as na.omit(
