On Thu, 2 Mar 2006, Martin Maechler wrote:
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Thu, 2 Mar 2006 06:45:39 + (GMT) writes:
>
>BDR> stopifnot() is not intended for use by end-users, but for tests in
>BDR> packages.
>
> and additionally for "function writers
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Thu, 2 Mar 2006 06:45:39 + (GMT) writes:
BDR> stopifnot() is not intended for use by end-users, but for tests in
BDR> packages.
and additionally for "function writers" aka 'programmeRs'.
I think we have argued that
stopifnot() is not intended for use by end-users, but for tests in
packages. If the writers of package tests are not aware of the perils of
using == or != with numbers, then it is good that they get reminded.
And we do have isTRUE for use with it.
On Wed, 1 Mar 2006, Dan Davison wrote:
> On
On Wed, 1 Mar 2006, Roger D. Peng wrote:
> Wouldn't it be better to do something like
>
> stopifnot(all(!is.na(x)), all(!is.na(y)), x, y)
>
> rather than have stopifnot() go checking for NAs? I agree the message is
> strange but if having non-NA values is really a condition, then why not just
>
Wouldn't it be better to do something like
stopifnot(all(!is.na(x)), all(!is.na(y)), x, y)
rather than have stopifnot() go checking for NAs? I agree the message is
strange but if having non-NA values is really a condition, then why not just
put
it in the call to stopifnot()?
-roger
Dan Davi
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[
