similar to: New matrix function

The link you posted used the same inputs as in my example. If that is not what you meant maybe a different example is needed. Regards. On Fri, Oct 11, 2019 at 2:39 PM Pages, Herve <hpages at fredhutch.org> wrote: > > Has someone looked into the image processing area for this? That sounds > a little bit too high-level for base R to me (and I would be surprised > if any mainstream

On Fri, 11 Oct 2019 10:45 Duncan Murdoch, <murdoch.duncan at gmail.com> wrote: > On 11/10/2019 6:44 a.m., Morgan Morgan wrote: > > Hi All, > > > > I was looking for a function to find a small matrix inside a larger > matrix > > in R similar to the one described in the following link: > > > > >

Also note that the functionality discussed could be regarded as a generalization of matrix multiplication where * and + are general functions and in this case we have * replaced by == and + replaced by &. On Fri, Oct 11, 2019 at 10:46 AM Gabor Grothendieck <ggrothendieck at gmail.com> wrote: > > Using the example in the link here are two one-liners: > > A <-

How do you prove usefulness of a feature? Do you have an example of a feature that has been added after proving to be useful in the package space first? Thank you, Morgan On Fri, 11 Oct 2019 13:53 Michael Lawrence, <lawrence.michael at gene.com> wrote: > Thanks for this interesting suggestion, Morgan. While there is no strict > criteria for base R inclusion, one criterion relevant

Has someone looked into the image processing area for this? That sounds a little bit too high-level for base R to me (and I would be surprised if any mainstream programming language had this kind of functionality built-in). H. On 10/11/19 03:44, Morgan Morgan wrote: > Hi All, > > I was looking for a function to find a small matrix inside a larger matrix > in R similar to the one

thanks for the tip Jan. However it would be nice if I didn't have to handle this myself for all of my packages. (and teach my students how to do that) BTW I tried to disable staged installation, and the issue still happens: th798 at cmp2986 MINGW64 ~/projects/max-generalized-auc (master) $ R_INSTALL_STAGED=FALSE R --vanilla -e

I tend to avoid using as.<type> functions on lists, since they act oddly in several ways. E.g, if the list "L" consists entirely of scalar elements then as.numeric(L) acts like as.numeric(unlist(L)) but if any element is not a scalar there is an error. as.character() does not seem to make a distinction between the all-scalar and not-all-scalar cases but does various things with

On 06/08/2018 10:15 AM, Michael Lawrence wrote: > There probably should be an abstraction for this. In S4Vectors, we > have extractROWS(). FWIW the code in S4Vectors that does what your subset_ROW() does is: https://github.com/Bioconductor/S4Vectors/blob/04cc9516af986b30445e99fd1337f13321b7b4f6/R/subsetting-utils.R#L466-L476 (This is the default "extractROWS" method.) Except

by() does not always return a list. In Gabe's example, it returns an integer, thus it is coerced to a list. as.list() means that it should be a VECSXP, not necessarily with "list" in the class attribute. Michael On Tue, Jan 30, 2018 at 2:41 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: > Hi Gabe, > > Interestingly the behavior of as.list() on by objects seem to

I have a use case where I would like to create an SEXP around an existing buffer that is managed by R, thus avoiding a copy operation. If I have something like: void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n))); ... additional maniupulation ... SEXP x = somefunc(SXPTYPE, n, p); // ???? Is there a "placement" constructor available? (I have arranged for the corresponding

Totally agree with that. H. On 5/15/20 10:34, William Dunlap via R-devel wrote: > I agree: paste(collapse="something", ...) should always return a single > character string, regardless of the value of recycle0. This would be > similar to when there are no non-NULL arguments to paste; collapse="." > gives a single empty string and collapse=NULL gives a zero long

On 01/20/2018 08:24 AM, William Dunlap via R-devel wrote: > I believe that for a list as.character() applies deparse() to each element > of the list. deparse() does not preserve NA-ness, as it is intended to > make text that the parser can read. > >> str(as.character(list(Na=NA, LglVec=c(TRUE,NA), > Function=function(x){x+1}))) > chr [1:3] "NA" "c(TRUE,

Hello R-devel, Best wishes in the new year. I am writing to kindly request new R function so NA_real_ can be more easily detected. Currently if one wants to test for NA_real_ (but not NaN) then extra work has to be done: `is.na(x) & !is.nan(x)` Required functionality is already at C level so to address my request there is not that much to do. Kevin Ushey made a nice summary of current R C api

I have a df with a vector v. For each element of the vector, I want to know whether the i-2nd element is the same as the ith element. For example: given v=c(A,C,D,C) the result should be: FALSE,FALSE,FALSE,TRUE. I attempted something using indexing in a for loop such as (bad, incorrect example): for (i in v){ if [i]==[i-2] print T else print F } However, this is obviously wrong. Can someone

There is still the situation where **both** 'sep' and 'collapse' are specified: > paste(integer(0), "nth", sep="", collapse=",") [1] "nth" In that case 'recycle0' should **not** be ignored i.e. paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE) should return the empty string

Hi, On 07/23/2017 11:43 AM, Davide Piffer wrote: > I have a df with a vector v. For each element of the vector, I want to > know whether the i-2nd element is the same as the ith element. For > example: > given > v=c(A,C,D,C) the result should be: > FALSE,FALSE,FALSE,TRUE. > > I attempted something using indexing in a for loop such as (bad, > incorrect example): >

Hi Martin et al, On Thu, May 21, 2020 at 9:42 AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > >>>>> Herv? Pag?s > >>>>> on Fri, 15 May 2020 13:44:28 -0700 writes: > > > There is still the situation where **both** 'sep' and 'collapse' are > > specified: > > >> paste(integer(0),

>>>>> mb706 >>>>> on Sun, 18 Oct 2020 22:14:55 +0200 writes: >> 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 Basically, just 1. svn co https://svn.r-project.org/R/trunk R-devel 2.

I agree with Herve, processing collapse happens last so collapse=non-NULL always leads to a single character string being returned, the same as paste(collapse=""). See the altPaste function I posted yesterday. Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, May 22, 2020 at 9:12 AM Herv? Pag?s <hpages at fredhutch.org> wrote: > I think that > >

>>>>> Michael Chirico >>>>> on Sun, 15 Sep 2019 20:52:34 +0800 writes: > Finally read in detail your response Gabe. Looks great, > and I agree it's quite intuitive, as well as agree against > non-recycling. > Once the length(n) == length(dim(x)) behavior is enabled, > I don't think there's any need/desire to have