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

2017-05-20 Thread Martin Maechler
t;> 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 complications which I really think

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

2017-05-19 Thread William Dunlap via R-devel
t} 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 > > wrote: > >

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

2017-05-19 Thread Martin Maechler
Error: ..2 is not TRUE {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

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

2017-05-18 Thread Suharto Anggono Suharto Anggono via R-devel
th '...'. It just returns 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 wrote:

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

2017-05-18 Thread Martin Maechler
> 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 case of illegal 'i' the sw

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

2017-05-16 Thread Hervé Pagès
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 this topic is even more co

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

2017-05-16 Thread Martin Maechler
> > 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, luke-tier...@uiowa.edu wrote: >> >> This is gett

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

2017-05-16 Thread peter dalgaard
> 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! -pd > > Just mentioning other things: > - For 'n', > n <- nargs() > can be used.

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

2017-05-16 Thread Suharto Anggono Suharto Anggono via R-devel
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 16:28

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

2017-05-16 Thread luke-tierney
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 description at the top of

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

2017-05-16 Thread luke-tierney
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

2017-05-16 Thread Serguei Sokol
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 : ‘stopifn

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

2017-05-16 Thread Martin Maechler
> 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 >> the help page -- it do

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

2017-05-15 Thread Hervé Pagès
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 droppi

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

2017-05-15 Thread Hervé Pagès
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 sequen

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

2017-05-15 Thread luke-tierney
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 stopifnot(A

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

2017-05-15 Thread Serguei Sokol
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

2017-05-15 Thread Martin Maechler
> 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 the attachment cannot pass. >> > So, here is th

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

2017-05-15 Thread peter dalgaard
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 wr

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

2017-05-15 Thread Martin Maechler
> 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" (but not so interesti

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

2017-05-15 Thread Serguei Sokol
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 the current source code

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

2017-05-15 Thread peter dalgaard
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

2017-05-15 Thread Martin Maechler
> 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 https://svn.r-project.

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

2017-05-15 Thread Serguei Sokol
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 = cu

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

2017-05-15 Thread Serguei Sokol
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 sa

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

2017-05-15 Thread Martin Maechler
> 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 is actually a primitiv

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

2017-05-03 Thread Hervé Pagès
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 <- match.call(expand.dots=FA

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

2017-05-03 Thread Hervé Pagès
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

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

2017-05-03 Thread peter dalgaard
The first line of stopifnot is n <- length(ll <- list(...)) which takes ALL arguments and forms a list of them. This implies evaluation, so explains the effect that you see. To do it differently, you would have to do something like dots <- match.call(expand.dots=FALSE)$... and then ex

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

2017-05-02 Thread Hervé Pagès
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 introduced