Although it is not as fancy as all other responses, I usually just print
the value of i first and see where it stopped. Of course this assumes you
it is stored in the main env. If it is inside a function and it is failing
I usually use the <<- operator to get it to the main env. and print it.
Here you would've seen that i stopped at 0.
Jean
On Tue, 23 Aug 2005, Gabor Grothendieck wrote:
> On 8/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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.
>
> ______________________________________________
> R-help@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
>
______________________________________________
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
