>>>>> 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 ..)
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://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.
> --
> 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://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.
