Re: [Rd] Use of all/any

From: Duncan Murdoch <>
Date: Fri, 26 Oct 2007 12:33:12 -0400

On 10/26/2007 12:18 PM, Martin Maechler wrote:

>>>>>> "BDR" == Prof Brian Ripley <>
>>>>>>     on Fri, 26 Oct 2007 08:16:03 +0100 (BST) writes:

> BDR> all/any coerce their arguments to logical (if
> BDR> possible). I've added a warning in R-devel if coercion
> BDR> is from something other than integer.
> BDR> This arose because it is easy to make a slip and write
> BDR> all(X) > 0 rather than all(X > 0): thanks to Bill
> BDR> Dunlap for bringing that to my attention.
> BDR> However, it has been useful in detecting quite a few other things:
> BDR> - indices which had been made double where integer was
> BDR> intended. One example from predict.lm was
> BDR> iipiv[ii == 0] <- 0
> BDR> which was intended to be
> BDR> iipiv[ii == 0L] <- 0L
> Hmm.... Do we really want to generate warnings for such small
> inefficiencies?
> I'm very happy that we've introduced <n>L integer notation, and
> as a subtle programmer, I'm making use of it gladly --- but
> still not always, just for code beauty reasons ("0" reads better).
> On the other hand, I don't think the casual R / S programmer
> should get warnings; after all, S and R are not C on purpose.
> Apropos Bill Dunlap's note: Do newer versions of S-plus warn?
> At least up to 6.2.2, I'm pretty sure no S version has warned
> about
> X <- c(0.1, pi)
> all(X) > 0.5

I don't know whether S warns about that, but isn't it clear that it should generate a warning? That's almost certainly a typo for

  all(X > 0.5)

If someone really wanted to do what all(X) > 0.5 says, then they should code it clearly as

  all(X != 0)

and not try to win an obfuscated code contest by coding it in the original way.

Duncan Murdoch

> In spite, of the buglets of you have revealed, mentioned below,
> currently, I'd still tend to only warn for coercion from
> non-numeric, but not from double.
> In this context, I have thought again of using *levels* of
> warnings, configurable via options(), and we could activate more
> stringent warnings when "R CMD check"ing than per default.
> Actually, we already have a simple form of that (with I think message()),
> and also with the way the 'codetools' ``warnings'' are treated
> by 'R CMD check'.
> For my taste and "S language feeling", such a
> 'double -> logical coercion warning'
> is somewhat similar in sprit to some of the codetools warnings.
> Martin
> BDR> - uses of lapply where sapply was intended. Examples
> BDR> are of the form
> BDR> all(lapply(z, is.numeric))
> BDR> which is applying all() to a list. One might worry
> BDR> that
> BDR> sapply(z, is.numeric)
> BDR> will return a list if length(z) == 0 (which it does)
> BDR> and so all() would warn, but that is covered by another
> BDR> change, to ignore all length-zero arguments (and so
> BDR> avoid the cost of coercion to logical(0)).
> BDR> I decided not to warn on integer as it is so common.
> BDR> But at least some of these are thinkos. For example,
> BDR> constructions like
> BDR> all(grep(pattern, x))
> BDR> occurred scores of times in the R sources. Since the
> BDR> value of grep() is an integer vector of positive
> BDR> indices, this is equivalent to
> BDR> length(grep(pattern, x)) > 0
> BDR> and when used in a if() condition the '> 0' is not
> BDR> needed.
> BDR> Some warnings are common from other packages: one is
> BDR> Warning in any(textLocations) : coercing argument of
> BDR> type 'double' to logical
> BDR> from lattice (and Deepayan Sarkar will fix that
> BDR> shortly). Quite a few others looked familiar but are
> BDR> the result of package authors copying code from base R
> BDR> or other packages: if you do that you do need to copy
> BDR> the bugfixes too.
> ______________________________________________
> mailing list
> mailing list Received on Fri 26 Oct 2007 - 16:43:44 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 30 Oct 2007 - 03:46:12 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.