[R] A stopifnot() nastiness, even if not a bug

[Martin Maechler]

>>>>> William Dunlap 
>>>>>     on Mon, 13 Apr 2020 09:57:11 -0700 writes:

    > 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.

well, maybe.
As I brougth up the 0-length example:  One could think of making
an exception for  logical(0)  and treat that as non-TRUE.

(for R-devel only, but still probably not this close before
 releasing R 4.0.0)

Martin

    > 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.
    >>