similar to: stopifnot

Another possible shortcut definition: assert <- function(exprs) do.call("stopifnot", list(exprs = substitute(exprs), local = parent.frame())) After thinking again, I propose to use ??? ? ? stop(simpleError(msg, call = if(p <- sys.parent()) sys.call(p))) - It seems that the call is the call of the frame where stopifnot(...) is evaluated. Because that is the correct context, I

My points: - The 'withCallingHandlers' construct that is used in current 'stopifnot' code has no effect. Without it, the warning message is the same. The overridden warning is not raised. The original warning stays. - Overriding call in error and warning to 'cl.i' doesn't always give better outcome. The original call may be "narrower" than 'cl.i'. I

>>>>> Suharto Anggono Suharto Anggono >>>>> on Tue, 5 Mar 2019 17:29:20 +0000 writes: > Another possible shortcut definition: > assert <- function(exprs) > do.call("stopifnot", list(exprs = substitute(exprs), local = parent.frame())) Thank you. I think this is mostly a matter of taste, but I liked your version using eval()

Instead of if(!is.null(names(cl))) names(cl) <- NULL , just names(cl) <- NULL looks simpler and the memory usage and speed is not bad in my little experiment. -------------------------------------------- Subject: Re: [Rd] stopifnot To: r-devel at r-project.org Date: Saturday, 2 March, 2019, 3:28 PM [...] A revised patch (also with simpler 'cl'): --- stop.R 2019-02-27

Here is a patch to function 'stopifnot' that adds 'evaluated' argument and makes 'exprs' argument in 'stopifnot' like 'exprs' argument in 'withAutoprint'. --- stop.R 2019-05-30 14:01:15.282197286 +0000 +++ stop_new.R 2019-05-30 14:01:51.372187466 +0000 @@ -31,7 +31,7 @@ .Internal(stop(call., .makeMessage(..., domain = domain))) }

Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version. options(error = expression(NULL)) library(compiler) enableJIT(0) f <- function(x) for (i in 1) {x; eval(expression(i))} f(is.numeric(y)) # Error: object 'y' not found fc <- cmpfun(f) fc(is.numeric(y)) # Error: object 'y' not found

>From https://github.com/HenrikBengtsson/Wishlist-for-R/issues/70 : ... and follow up note from 2018-03-15: Ouch... in R-devel, stopifnot() has become yet 4-5 times slower; ... which is due to a complete rewrite using tryCatch() and withCallingHandlers(). >From https://stat.ethz.ch/pipermail/r-devel/2017-May/074256.html , it seems that 'tryCatch' was used to avoid the following

On Mon, 1 Apr 2019, Martin Maechler wrote: >>>>>> Suharto Anggono Suharto Anggono via R-devel >>>>>> on Sun, 31 Mar 2019 15:26:13 +0000 writes: > > > Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' > > inside 'for' makes compiled version behave like > > non-compiled version. > > Ah.. ... thank

While you are fiddling with stopifnot(), please consider changing the form of the error thrown so that it includes the caller's call. The change would be from something like stop( <<the message>> ) to stop(simpleError( <<the message>>, sys.call(-1))) For the following code f <- function(x, y) { stopifnot(x > y) x - y } g <- function(x,

>From an example in http://www.uni-muenster.de/ZIV.BennoSueselbeck/s-html/helpfiles/nargs.html , number of arguments in '...' can be obtained by (function(...)nargs())(...) . I now realize that sys.call() doesn't expand '...' when the function is called with '...'. It just returns the call as is. If 'stopifnot' uses sys.call() instead of match.call() , the

switch(i, ...) extracts 'i'-th argument in '...'. It is like eval(as.name(paste0("..", i))) . Just mentioning other things: - For 'n', n <- nargs() can be used. - sys.call() can be used in place of match.call() . --------------------------- >>>>> peter dalgaard <pdalgd at gmail.com> >>>>> on Mon, 15 May 2017 16:28:42

>>>>> Suharto Anggono Suharto Anggono >>>>> on Thu, 30 May 2019 14:45:22 +0000 writes: >>>>> Suharto Anggono Suharto Anggono >>>>> on Thu, 30 May 2019 14:45:22 +0000 writes: > Here is a patch to function 'stopifnot' that adds 'evaluated' argument and makes 'exprs' argument in 'stopifnot'

By not using 'withCallingHandler' or 'tryCatch', the state is like 'stopifnot' in R 3.4.x. If 'stopifnot' becomes faster than in R 3.4.x when the expressions given to 'stopifnot' are all TRUE, it is because 'match.call' is not called. Credit is to https://github.com/HenrikBengtsson/Wishlist-for-R/issues/70 for the idea. Speaking about

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

In current definition of function 'stopifnot' in stop.R in R 3.6.0 beta (https://svn.r-project.org/R/branches/R-3-6-branch/src/library/base/R/stop.R) or R devel (https://svn.r-project.org/R/trunk/src/library/base/R/stop.R), if 'exprs' is specified, cl[[1]] is quote(stopifnot) . To be more robust, quote(base::stopifnot) may be used instead. Also, in current definition of function

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

With f <- function(x) for (i in 1) x fc <- cmpfun(f) (my previous example), error message of fc(is.numeric(y)) shows the originating call as well, while error message of f(is.numeric(y)) doesn't. Compiled version behaves differently. Even with f <- function(x) for (i in 1) {x; eval(expression(i))} fc <- cmpfun(f) , error message of fc(is.numeric(y)) shows the originating call in R

>>>>> Suharto Anggono Suharto Anggono via R-devel >>>>> on Sun, 31 Mar 2019 15:26:13 +0000 writes: > Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' > inside 'for' makes compiled version behave like > non-compiled version. Ah.. ... thank you for detecting that " eval() inside for()" behaves specially

>>>>> Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> >>>>> on Thu, 18 May 2017 16:27:09 +0000 writes: >> From an example in >> http://www.uni-muenster.de/ZIV.BennoSueselbeck/s-html/helpfiles/nargs.html >> , number of arguments in '...' can be obtained by > (function(...)nargs())(...) .

On 'factor', I meant the case where 'levels' is not specified, where 'unique' is called. > factor(c(complex(real=NaN), complex(imaginary=NaN))) [1] NaN+0i <NA> Levels: NaN+0i Look at <NA> in the result above. Yes, it happens in earlier versions of R, too. On matching both NA and NaN, another consequence is that length(unique(.)) may depend on order.