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

[Berton Gunter]

... and there is also Mark Bravington's debug package for more IDE-like
debugging.

-- Bert Gunter
Genentech Non-Clinical Statistics
South San Francisco, CA
 
"The business of the statistician is to catalyze the scientific learning
process."  - George E. P. Box
 
 

> -----Original Message-----
> From: r-help-bounces at stat.math.ethz.ch 
> [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Patrick Burns
> Sent: Tuesday, August 23, 2005 4:12 AM
> To: Ravi.Vishnu at outokumpu.com
> Cc: r-help at stat.math.ethz.ch
> Subject: Re: [R] priority of operators in the FOR ( ) statement
> 
> The command that I think is most useful in this situation
> is 'browser()'.
> 
> Even a couple decades of programming in the S language
> hasn't yet solved the problem of my fingers typing code that
> doesn't match what I want to happen.  I quite consistently have
> a
> 
> browser()
> 
> call in functions that I write to make sure that what I am assuming
> is the same as what R assumes.
> 
> 
> Patrick Burns
> patrick at burns-stat.com
> +44 (0)20 8525 0696
> http://www.burns-stat.com
> (home of S Poetry and "A Guide for the Unwilling S User")
> 
> 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.
> >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 at 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 at 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
>