[R] priority of operators in the FOR ( ) statement

[Gabor Grothendieck]

On 8/23/05, Ravi.Vishnu at outokumpu.com <Ravi.Vishnu at outokumpu.com> wrote:
> Dear All,
> I spent an entire evening in debugging a small, fairly simple program in R
> - without success. It was my Guru in Bayesian Analysis, Thomas Fridtjof,
> who was able to diagonose the problem. He said that it took a long time
> for him also to locate the problem.
> This program illustrates in some ways the shortcomings of the error
> messages that R responds with. In this case, it was quite misleading and
> directs attention to a location far removed the actual problem statement.
> Without any more introductory comments, let me directly discuss the
> essential problem. I am enclosing the entire program after a brief
> discussion.
> 
> The problem arises from the following statement (nr is an integer
> constant) :
> for ( i in 1:nr-1) {.......}
> The unexpected problem (at least for me) is that R reads the above
> statement as (i in (1:nr)-1) {.....}. This makes i be initially as zero
> which leads to an error because the for loop in R starts from 1. The
> problem is easily fixed by writing the for loop as  ( i in 1:(nr-1))
> {.......}. This would be an easy problem to fix if R directly indicates
> what the problem is. Instead, it gives mystifying error messages which are
> totally misleading. For example, to the program given below, I got the
> following error message (these point to commands elsewhere in the program)
> :
> Error in if ((x >= 0) & (x < s2)) return(x/2) else if ((x >= s2) & (x <  :
> 
>        missing value where TRUE/FALSE needed
> 
> I would like clarifications on the following points :
> 1. I am just curious to know if the priority of operators in the for
> statement ( the colon before the minus operator, for example) is a
> deliberate design decision. I have tested Matlab and found that it
> interprets my original statement correctly without an extra paranthesis.

?Syntax gives the operator precedence.

Also, note that : is probably best not used in functions since it does
not handle boundary conditions properly.   If n were 0 then 1:n 
results in two iterations corresonding to 1 and 0 but what you
really wanted was likely no iterations at all.  To do that you need
seq(length = n) rather than ":".   

Also I have found expressions like 0:1/10 handy to generate 
0, .1, .2, ..., 1 and that works with the current precedence.