Re: [Rd] stopifnot

> Martin Maechler > on Mon, 3 Jun 2019 18:14:15 +0200 writes: > Suharto Anggono Suharto Anggono > on Thu, 30 May 2019 14:45:22 + writes: > Suharto Anggono Suharto Anggono > on Thu, 30 May 2019 14:45:22 + writes: >> Here is a patch to function

Re: [Rd] stopifnot

Martin > -------- > On Mon, 15/4/19, Suharto Anggono Suharto Anggono wrote: > Subject: Re: [Rd] stopifnot > To: "Martin Maechler" > Cc: r-devel@r-project.org > Date: Monday, 15 April, 2019, 2:56 AM

Re: [Rd] stopifnot

)) names(cl) <- NULL return(eval(cl, envir=envir)) } Subject: Re: [Rd] stopifnot To: "Martin Maechler" Cc: r-devel@r-project.org Date: Monday, 15 April, 2019, 2:56 AM Also, in current definition of function 'stopifnot' in R 3.6.0

Re: [Rd] stopifnot

xample of use of 'stopifnot' inside a function, where error message from 'stopifnot' includes call since R 3.5.0. Such an example is in https://stat.ethz.ch/pipermail/r-devel/2017-May/074303.html . On Mon, 1/4/19, Martin Maechler wrote: Subject

Re: [Rd] stopifnot -- eval(*) inside for()

p the entire 'for' loop. The slowdown can be less than in R 3.5.x. On Mon, 1/4/19, Martin Maechler wrote: Subject: Re: [Rd] stopifnot -- eval(*) inside for() Cc: r-devel@r-project.org Date: Monday, 1 April, 2019, 5:00 PM >>>>&

Re: [Rd] stopifnot

> Suharto Anggono Suharto Anggono via R-devel > on Sun, 31 Mar 2019 15:26:13 + writes: [.] [ "eval() inside for()" not giving call in error message .] [.] > "Details" section of 'stopifnot' documentation in current R 3.6.0 alpha >

Re: [Rd] stopifnot -- eval(*) inside for()

> Suharto Anggono Suharto Anggono via R-devel > on Sun, 31 Mar 2019 15:26:13 + 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 "

Re: [Rd] stopifnot

If stop(simpleError(msg, call = if(p <- sys.parent()) sys.call(p))) were used in 'stopifnot', just "Error" would be given in this case. wrote: Subject: Re: [Rd] stopifnot To: r-devel@r-project.org Date: Thursday, 7 March, 2019,

Re: [Rd] stopifnot

TRUE To be the same as in R 3.5.x, the 'else' can be as.call(c(quote(expression), as.expression(exprs))) ---- On Wed, 6/3/19, Martin Maechler wrote: Subject: Re: [Rd] stopifnot @r-project.org Cc: "Martin Maechler" Date: Wednesday, 6 March, 2019, 3:50 PM >>>>> Martin Maechl

Re: [Rd] stopifnot

> Martin Maechler > on Tue, 5 Mar 2019 21:04:08 +0100 writes: > Suharto Anggono Suharto Anggono > on Tue, 5 Mar 2019 17:29:20 + writes: >> Another possible shortcut definition: >> assert <- function(exprs) >> do.call("stopifnot", list(exprs =

Re: [Rd] stopifnot

dd a case for 'cl', like >         else if(is.expression(exprs)) >         as.call(c(quote(expression), exprs)) that seems simple indeed, but at the moment, I cannot see one example where it makes a difference ... or then I'm "blind" .. ??? Best, Martin >

Re: [Rd] stopifnot

On Mon, 4/3/19, Martin Maechler wrote: Subject: Re: [Rd] stopifnot Cc: r-devel@r-project.org Date: Monday, 4 March, 2019, 4:59 PM >>>>> Suharto Anggono Suharto Anggono via R-devel >>>>>    on Sat, 2 Mar 2019 08:28:23 + writes: >>>&

Re: [Rd] stopifnot

(is.null(ni <- names(cl.i)) || length(cl.i) == 3L || > @@ -84,7 +83,12 @@ > "%s are not all TRUE"), > Dparse(cl.i)) > - stop(simpleError(msg, call = sys.call(-1))) > + n <- sys.nframe() > + if((p <- n-3) > 0 && >

Re: [Rd] stopifnot

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@r-project.org Date: Saturday, 2 March, 2

Re: [Rd] stopifnot

<- sys.nframe() + if((p <- n-3) > 0 && + identical(sys.function(p), sys.function(n)) && + eval(expression(!missE), p)) # originally stopifnot(exprs=*) + n <- p + stop(simpleError(msg, call = if(n > 1) sys.call(n-1)))

Re: [Rd] stopifnot

(ni <- names(cl.i)) || length(cl.i) == 3L || > @@ -84,7 +82,11 @@ > "%s are not all TRUE"), > Dparse(cl.i)) > - stop(simpleError(msg, call = sys.call(-1))) > + p <- sys.parent() > + if(p && identical(sys.function(p), stopifnot) && > +

Re: [Rd] stopifnot

+ p <- sys.parent(2) + stop(simpleError(msg, call = if(p) sys.call(p))) } } invisible() On Wed, 27/2/19, Martin Maechler wrote: Subject: Re: [Rd] stopifnot Cc: r-devel@r-project.org Date: Wednesday,

Re: [Rd] stopifnot

> Suharto Anggono Suharto Anggono via R-devel > on Sun, 24 Feb 2019 14:22:48 + writes: >> 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; >

[Rd] stopifnot

>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

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

>> is called with explicit expressions. >> Hence we have >> >> > g <- function(...) stopifnot(...) ; g(1 == 1, 3 < 1) >> Error: ..2 is not TRUE >> >> {and to "fix" this, e.g., with an extra optional argument} would >> lead to more comp

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

argument} would > lead to more complications which I really think we do not want}. > > But the example does show we should keep match.call(). > Martin > > > > > On Thu, 18/5/17, Martin Maechler > > <maech...@sta

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

RUE {and to "fix" this, e.g., with an extra optional argument} would lead to more complications which I really think we do not want}. But the example does show we should keep match.call(). Martin > -------- > On Thu, 18/5/17, Marti

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

the call as is. If 'stopifnot' uses sys.call() instead of match.call() , the following example behaves improperly: g <- function(...) stopifnot(...) g(TRUE, FALSE) On Thu, 18/5/17, Martin Maechler <maech...@stat.math.ethz.ch> wrote: Subject:

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

> Suharto Anggono Suharto Anggono via R-devel > on Tue, 16 May 2017 16:37:45 + writes: > switch(i, ...) > extracts 'i'-th argument in '...'. It is like > eval(as.name(paste0("..", i))) . Yes, that's neat. It is only almost the same: in the

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

On 05/16/2017 09:59 AM, peter dalgaard wrote: On 16 May 2017, at 18:37 , Suharto Anggono Suharto Anggono via R-devel wrote: switch(i, ...) extracts 'i'-th argument in '...'. It is like eval(as.name(paste0("..", i))) . Hey, that's pretty neat! Indeed! Seems like

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

> > on Tue, 16 May 2017 09:49:56 -0500 writes: > On Tue, 16 May 2017, Martin Maechler wrote: >>> Hervé Pagès >>> on Mon, 15 May 2017 16:54:46 -0700 writes: >> >> > Hi, >> > On 05/15/2017 10:41 AM,

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

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 > on Mon, 15 May 2017

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

On Tue, 16 May 2017, Martin Maechler wrote: Hervé Pagès on Mon, 15 May 2017 16:54:46 -0700 writes: > Hi, > On 05/15/2017 10:41 AM, luke-tier...@uiowa.edu wrote: >> This is getting pretty convoluted. >> >> The current behavior is consistent with the

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

On Tue, 16 May 2017, Serguei Sokol wrote: Le 15/05/2017 à 19:41, luke-tier...@uiowa.edu a écrit : This is getting pretty convoluted. The current behavior is consistent with the description at the top of the help page -- it does not promise to stop evaluation once the first non-TRUE is found.

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Le 15/05/2017 à 19:41, luke-tier...@uiowa.edu a écrit : This is getting pretty convoluted. The current behavior is consistent with the description at the top of the help page -- it does not promise to stop evaluation once the first non-TRUE is found. Hm... we can read in the man page :

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

> Hervé Pagès > on Mon, 15 May 2017 16:54:46 -0700 writes: > Hi, > On 05/15/2017 10:41 AM, luke-tier...@uiowa.edu wrote: >> This is getting pretty convoluted. >> >> The current behavior is consistent with the description at the top of >>

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

On 05/15/2017 07:28 AM, peter dalgaard wrote: I think Hervé's idea was just that if switch can evaluate arguments selectively, so can stopifnot(). Yep. Thanks, H. But switch() is .Primitive, so does it from C. I think it is almost a no-brainer to implement a sequential stopifnot if

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Hi, On 05/15/2017 10:41 AM, luke-tier...@uiowa.edu wrote: This is getting pretty convoluted. The current behavior is consistent with the description at the top of the help page -- it does not promise to stop evaluation once the first non-TRUE is found. That seems OK to me -- if you want

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

This is getting pretty convoluted. The current behavior is consistent with the description at the top of the help page -- it does not promise to stop evaluation once the first non-TRUE is found. That seems OK to me -- if you want sequencing you can use stopifnot(A) stopifnot(B) or

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Le 15/05/2017 à 17:44, Martin Maechler a écrit : ... So this needs even more sophistication, using withCallingHandlers(.) and maybe that really get's too sophisticated and no more "readable" to 99.9% of the R users ... ? I'd say the current version is of minimal sophistication to reach both the

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

> Serguei Sokol > on Mon, 15 May 2017 16:32:20 +0200 writes: > Le 15/05/2017 à 15:37, Martin Maechler a écrit : >>> Serguei Sokol >>> on Mon, 15 May 2017 13:14:34 +0200 writes: >> > I see in the archives that

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

However, it doesn't look much of a hassle to fuse my suggestion into the current stopifnot: Basically, just use eval(as.name(paste0("..",i))) instead of ll[[i]] and base the initial calculation of n on match.call() rather than on list(...). -pd > On 15 May 2017, at 17:04 , Martin Maechler

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

> peter dalgaard > on Mon, 15 May 2017 16:28:42 +0200 writes: > I think Hervé's idea was just that if switch can evaluate arguments selectively, so can stopifnot(). But switch() is .Primitive, so does it from C. if he just meant that, then "yes, of course"

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Le 15/05/2017 à 15:37, Martin Maechler a écrit : Serguei Sokol on Mon, 15 May 2017 13:14:34 +0200 writes: > I see in the archives that the attachment cannot pass. > So, here is the code: [... MM: I needed to reformat etc to match closely to

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

I think Hervé's idea was just that if switch can evaluate arguments selectively, so can stopifnot(). But switch() is .Primitive, so does it from C. I think it is almost a no-brainer to implement a sequential stopifnot if dropping to C code is allowed. In R it gets trickier, but how about this:

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

> Serguei Sokol > on Mon, 15 May 2017 13:14:34 +0200 writes: > I see in the archives that the attachment cannot pass. > So, here is the code: [... MM: I needed to reformat etc to match closely to the current source code which is in

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

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 =

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Hello, I am a new on this list, so I introduce myself very briefly: my background is applied mathematics, more precisely scientific calculus applied for modeling metabolic systems, I am author/maintainer of few packages (Deriv, rmumps, arrApply). Now, on the subject of this discussion, I must

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

> Hervé Pagès > 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

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

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 there is at least another way to go than 'dots <-

Re: [Rd] stopifnot() does not stop at first non-TRUE argument

Not sure why the performance penalty of nonstandard evaluation would be more of a concern here than for something like switch(). If that can't/won't be fixed, what about fixing the man page so it's in sync with the current behavior? Thanks, H. On 05/03/2017 02:26 AM, peter dalgaard wrote: The

[Rd] stopifnot() does not stop at first non-TRUE argument

Hi, It's surprising that stopifnot() keeps evaluating its arguments after it reaches the first one that is not TRUE: > stopifnot(3 == 5, as.integer(2^32), a <- 12) Error: 3 == 5 is not TRUE In addition: Warning message: In stopifnot(3 == 5, as.integer(2^32), a <- 12) : NAs

Re: [Rd] stopifnot() suggestion

On Thu, 2 Mar 2006, Martin Maechler wrote: BDR == Prof Brian Ripley [EMAIL PROTECTED] on Thu, 2 Mar 2006 06:45:39 + (GMT) writes: BDR stopifnot() is not intended for use by end-users, but for tests in BDR packages. and additionally for function writers aka 'programmeRs'. I

Re: [Rd] stopifnot() suggestion

Wouldn't it be better to do something like stopifnot(all(!is.na(x)), all(!is.na(y)), x, y) rather than have stopifnot() go checking for NAs? I agree the message is strange but if having non-NA values is really a condition, then why not just put it in the call to stopifnot()? -roger Dan

Re: [Rd] stopifnot() suggestion

BDR == Prof Brian Ripley [EMAIL PROTECTED] on Thu, 2 Mar 2006 06:45:39 + (GMT) writes: BDR stopifnot() is not intended for use by end-users, but for tests in BDR packages. and additionally for function writers aka 'programmeRs'. I think we have argued that R has