>>>>> 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 <hpa...@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 <
>> maech...@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@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....@cbs.dk Priv: pda...@gmail.com
>> >
>> > ______________________________________________
>> > R-help@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: hpa...@fredhutch.org
>> Phone: (206) 667-5791
>> Fax: (206) 667-1319
>>
>> ______________________________________________
>> R-help@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.
>>
______________________________________________
R-help@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.
