search for: stopifnot_new

I see in the archives that the attachment cannot pass. So, here is the code: 8<---- stopifnot_new <- function (...) { mc <- match.call() n <- length(mc)-1 if (n == 0L) return(invisible()) Dparse <- function(call, cutoff = 60L) { ch <- deparse(call, width.cutoff = cutoff) if (length(ch) > 1L) paste(ch[1L], "....&q...

>>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Wed, 3 May 2017 12:08:26 -0700 writes: > On 05/03/2017 12:04 PM, Herv? Pag?s wrote: >> Not sure why the performance penalty of nonstandard evaluation would >> be more of a concern here than for something like switch(). > which is actually a primitive. So it seems that

...rent stopifnot() n <- length(ll <- list(...)) already evaluates _all_ of the arguments in the caller frame. So to do the same only on a part of them (till the first FALSE or NA occurs) cannot be more penalizing than the current version, right? I attach here a slightly modified version called stopifnot_new() which works in accordance with the man page and where there are only two additional calls: parent.frame() and eval(). I don't think it can be considered as real performance penalty as the same or bigger amount of (implicit) evaluations was already done in the current version: > source(&qu...

...ates _all_ of the arguments >> in the caller frame. So to do the same only >> on a part of them (till the first FALSE or NA occurs) >> cannot be more penalizing than the current version, right? >> >> I attach here a slightly modified version called stopifnot_new() >> which works in accordance with the man page and >> where there are only two additional calls: parent.frame() and eval(). >> I don't think it can be considered as real performance penalty >> as the same or bigger amount of (implicit) evaluations was...

...gt; >> in the caller frame. So to do the same only > >> on a part of them (till the first FALSE or NA occurs) > >> cannot be more penalizing than the current version, right? > >> > >> I attach here a slightly modified version called stopifnot_new() > >> which works in accordance with the man page and > >> where there are only two additional calls: parent.frame() and eval(). > >> I don't think it can be considered as real performance penalty > >> as the same or bigger amount of (imp...

...ally get's too sophisticated and no more "readable" to 99.9% of the R users ... ? I now do append my current version -- in case some may want to comment or improve further. Martin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stopifnot_new.R.~3~ URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20170515/4d595547/attachment.ksh>