[R] A stopifnot() nastiness, even if not a bug
William Dunlap
wdun|@p @end|ng |rom t|bco@com
Mon Apr 13 18:57:11 CEST 2020
You can avoid the problem in Martin's example by only giving scalars to
stopifnot(). E.g., using stopifnot(all(x>0)) or stopifnot(length(x)==1,
x>0) instead of stopifnot(x>0). I think having stopifnot call
all(predicate) if length(predicate)!=1 was probably a mistake.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Mon, Apr 13, 2020 at 9:28 AM Hervé Pagès <hpages using fredhutch.org> wrote:
>
>
> On 4/13/20 05:30, Martin Maechler wrote:
> >>>>>> peter dalgaard
> >>>>>> on Mon, 13 Apr 2020 12:00:38 +0200 writes:
> >
> > > Inline...
> > >> On 13 Apr 2020, at 11:15 , Martin Maechler <
> maechler using stat.math.ethz.ch> wrote:
> > >>
> > >>>>>>> Bert Gunter
> > >>>>>>> on Sun, 12 Apr 2020 16:30:09 -0700 writes:
> > >>
> > >>> Don't know if this has come up before, but ...
> > >>>> x <- c(0,0)
> > >>>> length(x)
> > >>> [1] 2
> > >>> ## but
> > >>>> stopifnot(length(x))
> > >>> Error: length(x) is not TRUE
> > >>> Called from: top level
> > >>> ## but
> > >>>> stopifnot(length(x) > 0) ## not an error; nor is
> > >>>> stopifnot(as.logical(length(x)))
> > >>> ## Ouch!
> > >>
> > >>> Maybe the man page should say something about not assuming
> automatic
> > >>> coercion to logical, which is the usual expectation. Or fix
> this.
> > >>
> > >>> Bert Gunter
> > >>
> > >> Well, what about the top most paragraph of the help page is not
> clear here ?
> > >>
> > >>> Description:
> > >>
> > >>> If any of the expressions (in '...' or 'exprs') are not 'all'
> > >>> 'TRUE', 'stop' is called, producing an error message indicating
> > >>> the _first_ expression which was not ('all') true.
> > >>
> >
> > > This, however, is somewhat less clear:
> >
> > > ..., exprs: any number of (typically but not necessarily
> ‘logical’) R
> > > expressions, which should each evaluate to (a logical vector
> > > of all) ‘TRUE’. Use _either_ ‘...’ _or_ ‘exprs’, the latter
> >
> > > What does it mean, "typically but not necessarily ‘logical’"?
> >
> > That's a good question: The '(....)' must have been put there a while
> ago.
> > I agree that it's not at all helpful. Strictly, we are really
> > dealing with unevaluated expressions anyway ("promises"), but
> > definitely all of them must evaluate to logical (vector or
> > array..) of all TRUE values. In the very beginning of
> > stopifnot(), I had thought that it should also work in other
> > cases, e.g., for Matrix(TRUE, 4,5) {from the Matrix package} etc,
> > but several use cases had convinced us / me that stopifnot
> > should be stricter...
> >
> > > The code actually tests explicitly with is.logical, as far as I
> can tell.
> >
> > > This creates a discrepancy between if(!...)stop(...) and
> stopifnot(),
> >
> > yes indeed, on purpose now, for a very long time ...
> >
> > There's another discrepancy, more dangerous I think,
> > as shown in the following
> > {Note this discrepancy has been noted for a long time .. also on
> > this R-devel list} :
> >
> > m <- matrix(1:12, 3,4)
> > i <- (1:4) %% 2 == 1 & (0:3) %% 5 == 0
> >
> > stopifnot(dim(m[,i]) == c(3,1)) # seems fine
> >
> > if(dim(m[,i]) != c(3,1)) stop("wrong dim") # gives an error (but not
> ..)
>
> mmh... that is not good. I was under the impression that we could at
> least expect 'stopifnot(x)' to be equivalent to 'if (!isTRUE(x))
> stop(...)'. I'll have to revisit my use of stopifnot() in many many
> places... again :-/ Or may be just stop using it and use 'if
> (!isTRUE(...))' instead.
>
> H.
>
> >
> >
> > Martin
> >
> > >> as in
> > >> f <- function (x) if (!x) stop(paste(deparse(substitute(x)), "is
> not TRUE"))
> > >> f(0)
> > > Error in f(0) : 0 is not TRUE
> > >> f(1)
> > >> stopifnot(0)
> > > Error: 0 is not TRUE
> > >> stopifnot(1)
> > > Error: 1 is not TRUE
> >
> > > -pd
> >
> >
> > >> If useR's expectations alone would guide the behavior of a
> > >> computer language, the language would have to behave
> > >> "personalized" and give different results depending on the user,
> > >> which may be desirable in medicine or psychotherapy but not with
> R.
> > >>
> > >> Martin
> > >>
> > >> ______________________________________________
> > >> R-help using r-project.org mailing list -- To UNSUBSCRIBE and more,
> see
> > >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dhelp&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=2kAPk_-c9XEQGS0BB1rf03oPxqQtflyqhqi-0BT8bWE&s=W8I5sRKBBKZgSjXrQC_PQw6XXUApw5h2DI5EUoDdl9w&e=
> > >> PLEASE do read the posting guide
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.R-2Dproject.org_posting-2Dguide.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=2kAPk_-c9XEQGS0BB1rf03oPxqQtflyqhqi-0BT8bWE&s=ADWOmjdAMLWT3rJRMz411RnDjrc6Vyj4NNmZMoM3Sck&e=
> > >> and provide commented, minimal, self-contained, reproducible
> code.
> >
> > > --
> > > Peter Dalgaard, Professor,
> > > Center for Statistics, Copenhagen Business School
> > > Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > > Phone: (+45)38153501
> > > Office: A 4.23
> > > Email: pd.mes using cbs.dk Priv: PDalgd using gmail.com
> >
> > ______________________________________________
> > R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dhelp&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=2kAPk_-c9XEQGS0BB1rf03oPxqQtflyqhqi-0BT8bWE&s=W8I5sRKBBKZgSjXrQC_PQw6XXUApw5h2DI5EUoDdl9w&e=
> > PLEASE do read the posting guide
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.R-2Dproject.org_posting-2Dguide.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=2kAPk_-c9XEQGS0BB1rf03oPxqQtflyqhqi-0BT8bWE&s=ADWOmjdAMLWT3rJRMz411RnDjrc6Vyj4NNmZMoM3Sck&e=
> > and provide commented, minimal, self-contained, reproducible code.
> >
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpages using fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
>
> ______________________________________________
> R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
[[alternative HTML version deleted]]
More information about the R-help
mailing list