... 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Burns > Sent: Tuesday, August 23, 2005 4:12 AM > To: [EMAIL PROTECTED] > Cc: r-help@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 > [EMAIL PROTECTED] > +44 (0)20 8525 0696 > http://www.burns-stat.com > (home of S Poetry and "A Guide for the Unwilling S User") > > [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. > >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 > ______________________________________________ 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
