From: P Ehlers <ehlers_at_math.ucalgary.ca>

Date: Tue 23 Aug 2005 - 20:51:33 EST

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 Received on Tue Aug 23 21:10:29 2005

Date: Tue 23 Aug 2005 - 20:51:33 EST

Since there is nothing wrong with

for(i in 1:nr - 1)

R can't really do much more than point to where your code fails due your incorrect assumption about operator precedence. You're certainly not the first to fall into this trap. But it's not that hard to diagnose. Anytime I have problems with a loop, I do three simple things:

- for(i in whatever) print(i)
- look at what traceback() says
- step through the loop "by hand".

The first test would have told you (in much less than an "entire evening") what the problem was.

Peter Ehlers

Ravi.Vishnu@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.
**> 2. Faced with a similiar problem in the future, what is a smart way of
**> debugging in R to locate a problem. With this problem, I checked and
**> double checked every single statement in the program, except the for
**> statement because I just did not expect any problem there. I have seen
**> that there is a debug package but I have not used it. Can such tools be
**> used to locate a problem with greater ease? Can somebody give a concrete
**> example (for the following program, for example) of a debugging routine.
**>
**> *************************************************************************'
**> # Bayesian Data Analysis
**> ## source("M:/programming/Rfolder/Assignments/fortest.txt")
**>
**> # #Remove all objects from the workspace
**> rm(list=ls())
**> # #We will also try to note the time that the program takes
**> # #We will start the clock at starttime
**> starttime <- proc.time()[3];
**>
**> my.function<-function(x) {
**> s2<-sqrt(2);
**> if ((x>=0) & (x<s2)) return(x/2)
**> else
**> if ((x>=s2) & (x<1+s2)) return(0.2)
**> else
**> if ((x>=1+s2) & (x<1.5+s2)) return(0.6)
**> else
**> if ((x>1.5+s2) | (x<0)) return(0)
**> }
**>
**> alphayx<-function(y,x) {
**> fy<-my.function(y)
**> fx<-my.function(x)
**> fyx<-fy/fx
**> # to account for 0/0 division
**> if (is.na(fyx)) fyx<-0
**> #fyx<-ifelse(is.na(fyx),0,fyx);
**> alpha<-min(1,fyx)
**> return(alpha)
**> }
**>
**> sigma<-0.5;
**> #nr is the number of iterations
**> nr<-20
**> x<-numeric(nr);
**> x[1]<-1;
**> t<-1:nr;
**>
**> for (i in 1:nr-1) {
**> xi<-x[i];
**> yi<-rnorm(1,mean=xi,sd=sigma);
**> ui<-runif(1,0,1);
**> ualphai<-alphayx(yi,xi);
**> xn<-ifelse(ui<=ualphai,yi,xi);
**> x[i+1]<-xn;
**> }
**>
**> plot(t,x,type="p")
**>
**> endtime<-proc.time()[3];
**> elapsedTime<-endtime-starttime;
**> cat("Elapsed time is", elapsedTime, "seconds", "\n")
**> *****************************************************************************'
**>
**>
**>
**>
**> This message is meant for the addressee only and may contain
**> confidential and legally privileged information. Any unauthorised
**> review, use, copying, storage, disclosure or distribution of this e-
**> mail and any attachments is strictly prohibited. If you are not the
**> named recipient or have otherwise received this communication in
**> error, please destroy this message from your system and kindly notify
**> the sender by e-mail. Thank you for your co-operation.
**>
**> [[alternative HTML version deleted]]
**>
**> ______________________________________________
**> 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 Received on Tue Aug 23 21:10:29 2005

*
This archive was generated by hypermail 2.1.8
: Sun 23 Oct 2005 - 15:43:42 EST
*