[R] Intersection for two curves

[William Dunlap]

> -----Original Message-----
> From: r-help-bounces at r-project.org 
> [mailto:r-help-bounces at r-project.org] On Behalf Of Peter Ehlers
> Sent: Saturday, April 24, 2010 3:51 PM
> To: hadley wickham
> Cc: r-help at r-project.org
> Subject: Re: [R] Intersection for two curves
> 
> On 2010-04-24 13:50, hadley wickham wrote:
> > On Sat, Apr 24, 2010 at 12:54 PM, Peter 
> Ehlers<ehlers at ucalgary.ca>  wrote:
> >> Well, this has seriously gotten off the original topic.
> >>
> >> While Hadley makes some sense, it is nevertheless
> >> sometimes the case (surely so for David, I would surmise)
> >> that one is putting together a response to an R-help
> >> query when a new query prompts one to temporarily abandon
> >> the first and formulate a response to the second. One
> >> may well prefer not to have one's workspace cleared even
> >> though this would not lose more than the temporarily
> >> suspended work. So, is ther *ever* a good reason to
> >> *not* put rm(list=ls()) behind a comment char? I doubt it.
> >
> > Is there ever a good idea to use rm(list = ls()) ?  Why not close R
> > and restart it so you can guarantee you have a clean 
> environment which
> > with to test your code.
> 
> I agree completely. It's precisely what I do. The only
> drawback might be restarting a number of packages but even
> that hasn't been a problem. I don't think I've used rm(list=ls())
> in any session other than one I don't mind losing.

My guess about why lots of people start their
scripts with a call like rm(list=ls(all=TRUE))
is that they don't want to define functions to
use.  Hence their workspace gets filled with
temporary variables and they want to get rid of
them before the next test run of the script file.

E.g., one appeared today that looked like
   # [do not execute] # RM(list=ls(all=TRUE))
   myData <- read.table(...)
   for(i in 1:ncol(myData)) {
       tmp1 <- ...
       ...
       tmp20 <- ...
       print(tmp20)
       result <- cbind(result, c(tmp1, ..., tmp20))
   }
I suspect the rm() is there to get rid of the 20 temporary
variables left over from the last try.  If this were written
as a function definition followed by a call, so all temporary
variables disappeared when the call was done, there might
be less temptation to put the rm() call in the script:
    f <- function(data) {
       for(i in 1:nrow(data)) {
          tmp1 <- ...
          ...
          tmp20 <- ...
          print(tmp20)
          returnValue <- ...
       }
       returnValue
   }
   result <- f(myData)
Defining functions makes it easier for others to work
on a problem, since they make it clear what the inputs
and outputs are and it is easy to compare the outputs of
two functions calls with all.equal(f1(data), f2(data)).

Many people seem to be reluctant to define functions,
even thought I think it is a pretty small step from
writing scripts to writing functions.  If you don't
write functions you are doomed to an R-life of copying
and pasting or having to remember stupid details of
the language instead of being able to solve a problem
once and reusing the solution (like doing math by
using only Peano's axioms instead of using theorems
proved from them).

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com  

> 
>   -Peter
> 
> >
> > This is probably one of the biggest disadvantages of using the
> > existing R guis - you normally only have one running, and it's a
> > hassle to close it down and restart it.
> >
> > Hadley
> >
> 
> -- 
> Peter Ehlers
> University of Calgary
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>