[Rd] Use of all/any

[Duncan Murdoch]

On 10/26/2007 12:18 PM, Martin Maechler wrote:
>>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk>
>>>>>>     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.
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel