> 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 'st
thing
like 'is.language' or 'expr.is.language' or similar..
Could we get any other readers' opinions ?
Martin
>
> On Mon, 15/4/19, Suharto Anggono Suharto Anggono
wrote:
> Subject: Re: [Rd] stopifnot
>
(exprs)
- )) # or fail ..
+ ))
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
, it is
sys.call(sys.parent(1L)) , only if sys.parent(1L) is not 0. The two may differ
only for 'stopifnot' that is called via 'eval' or the like.
I think it is good if the documentation also includes an example of use of
'stopifnot' inside a function, where e
lso,
'tryCatch' (or 'withCallingHandlers' ...) can wrap 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()
> 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
>
(
> 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 " eval(
like in R before
version 3.5.0, feels better to me. 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
se' clause for 'cl' gives
call("expression", exprs) .
For
do.call(stopifnot, list(exprs = expression())) ,
the whole expression object is taken as one.
do.call(stopifnot, list(exprs = expression(1==1, 2 < 1, stop("NOT GOOD!\n"
Error in do.call(stopifnot, list(exprs = expression(1 == 1, 2 < 1, stop(&quo
> 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 = substitute(
> If so, maybe add 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" ..
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 + w
f(is.call(cl.i) && identical(cl.i[[1]], quote(all.equal)) &&
> (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)))
>
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
stop(simpleError(msg, call = sys.call(-1)))
+ n <- sys.nframe()
+ if((p <- n-3) > 0 &&
+ identical(sys.function(p), sys.function(n)) &&
+ eval(expression(!missE), p)) # originally stopifnot(exprs=*)
+ n <- p
+ stop
or decently written 'all.equal(*)':
> if(is.call(cl.i) && identical(cl.i[[1]], quote(all.equal)) &&
> (is.null(ni <- names(cl.i)) || length(cl.i) == 3L ||
> @@ -84,7 +82,11 @@
> "%s are not all TRUE"),
> Dparse(cl.i))
> - stop(simpleError(msg,
tical(sys.function(p), stopifnot) &&
+ !eval(expression(missE), p)) # originally stopifnot(exprs=*)
+ p <- sys.parent(2)
+ stop(simpleError(msg, call = if(p) sys.call(p)))
}
}
invisible()
--
> 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;
> .
>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-
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
a very good idea anyway, because stopifnot has to assume it
> 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 argumen
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
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:
> 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
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
>
> 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
> 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.
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
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
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.
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
> 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
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
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
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
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
> 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
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
> 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
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
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:
> 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.
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
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
> 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
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
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
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
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
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
> "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
stopifnot() is not intended for use by end-users, but for tests in
packages. If the writers of package tests are not aware of the perils of
using == or != with numbers, then it is good that they get reminded.
And we do have isTRUE for use with it.
On Wed, 1 Mar 2006, Dan Davison wrote:
> On
On Wed, 1 Mar 2006, Roger D. Peng wrote:
> 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
>
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 Davi
If an expression is passed to stopifnot() which contains missing values,
then the resulting error message is somewhat baffling until you are used
to it, e.g.
> x <- y <- rep(TRUE, 10)
> y[7] <- NA
> stopifnot(x, y)
Error in if (!(is.logical(r <- eval(ll[[i]])) && all(r)))
stop(paste(deparse(mc[
55 matches
Mail list logo
