similar to: Bug report: override stopifnot() ?

Hello, On Mon, Mar 12, 2018 at 09:30:59AM -0700, William Dunlap wrote: > Why don't you use > stopifnot( all(m1 == m2) ) > ? good question. Even though I use aseert np.all(m1 == m2) when working with NumPy, I got accustomed to the "handy shortcut" that I can omit all() with R vectors and matrices. Then I got trapped with the thing I reported. On a second thought,

Why don't you use stopifnot( all(m1 == m2) ) ? Bill Dunlap TIBCO Software wdunlap tibco.com On Mon, Mar 12, 2018 at 8:15 AM, Stepan Kasal <kasal at ucw.cz> wrote: > Hello, > I stumbled over a problem: > stopifnot(m1 == m2) > > It works with vector or matrix, but does not work for classes from Matrix > package. > > In the source of stopifnot(), there is

Please stop this line of queries/"suggestions/speculations and read the relevant docs **carefully**. For example, from ?"==" "Note Do not use == and != for tests, such as in if expressions, where you must get a single TRUE or FALSE. Unless you are absolutely sure that nothing unusual can happen, you should use the identical

Hello, in order to compile sppex on my Fedora, I had to do the following changes. Please consider installing them to the main tree. Thanks for your work, Stepan Kasal --- /usr/src/redhat/SPECS/Speex.spec 2006-02-15 13:13:48.000000000 +0100 +++ /usr/src/redhat/SPECS/Speex.spec.new 2006-05-10 11:00:25.000000000 +0200 @@ -6,7 +6,7 @@ Name: %name Version: %ver Release: %rel -Copyright: BSD

Hello, I'm setting up a new server on 5.4 and noticed this in the perl.spec file: * Mon Jul 21 2008 Stepan Kasal - 4:5.8.8-14.el5 - add two patches, which... - Resolves: #435505, #431041 - remove %%define threading, the non-threading variant is not supported, Related: 435376 That comment wasn't there when I set up a server on 5.2 a few months back and the %define threading option

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[[i + : missing value where TRUE/FALSE needed A minor change to

>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

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: Stopifnot <- function(...) { n <- length(match.call()) - 1 for (i in 1:n) { nm

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

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

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 by coercion to integer range > a [1] 12 The details section in its man

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,

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 first line of stopifnot is > > n <- length(ll <- list(...)) > >

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

Hi, I found the following issue in r-devel (2019-01-02 r75945): `foo<-` <- function(x, value) { bar(x) <- value * x x } `bar<-` <- function(x, value) { stopifnot(all(value / x == 1)) x + value } `foo<-` <- compiler::cmpfun(`foo<-`) `bar<-` <- compiler::cmpfun(`bar<-`) x <- c(2, 2) foo(x) <- 1 x # should be c(4, 4) #> [1] 3 3 If the functions

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

I am using a variant of stopifnot a lot. can I suggest that base R extends its functionality? I know how to do this for myself. this is a suggestion for beginners and students. I don't think it would break anything. first, I think it would be more useful if it had an optional character string, so users could write stopifnot( is.matrix(m), "m is not a matrix" ) this would

>>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Mon, 15 May 2017 16:54:46 -0700 writes: > Hi, > On 05/15/2017 10:41 AM, luke-tierney at 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

On 03/01/2019 3:37 p.m., Duncan Murdoch wrote: > I see this too; by bisection, it seems to have first appeared in r72943. Sorry, that was a typo. I meant r75943. Duncan Murdoch > > Duncan Murdoch > > On 03/01/2019 2:18 p.m., I?aki Ucar wrote: >> Hi, >> >> I found the following issue in r-devel (2019-01-02 r75945): >> >> `foo<-` <-

Dear R-users, Could someone please explain why the message printed by function stopifnot2, see below, is different from that of stopifnot itself? Thank you for your help, Vadim > stopifnot2 <- function(...) stopifnot(...) > stopifnot(F) Error: F is not TRUE > stopifnot2(F) Error: ..1 is not TRUE > version _ platform i386-pc-mingw32 arch i386 os