[R] Debugging R's code: boxplot.stats

Duncan Murdoch murdoch at stats.uwo.ca
Mon Oct 30 02:18:19 CET 2006


On 10/29/2006 8:01 PM, Matthew Walker wrote:
> On Sun, 2006-10-29 at 18:47 -0500, Duncan Murdoch wrote:
> [snip]
>>> Hi Duncan,
>>>
>>> Thanks for your reply.
>>>
>>> How do you know that (i) boxplot.stats lives in the grDevices namespace?
>> getAnywhere(boxplot.stats) starts out as
>>
>>  > getAnywhere(boxplot.stats)
>> A single object matching 'boxplot.stats' was found
>> It was found in the following places
>>    package:grDevices
>>    registered S3 method for boxplot from namespace grDevices
>>    namespace:grDevices
>>
>>> and (ii) how do you know/change that boxplot will look in grDevices
>>> before it uses the local copy?
>> That was actually a guess.  But checking now:
>>
>>  > getAnywhere(boxplot)
>> A single object matching 'boxplot' was found
>> It was found in the following places
>>    package:graphics
>>    namespace:graphics
>> with value
>>
>> function (x, ...)
>> UseMethod("boxplot")
>> <environment: namespace:graphics>
>>
>> so boxplot() is in the graphics package, and works in that namespace. 
>> The graphics namespace file starts out
>>
>> import(grDevices)
>>
>> so functions in that package will look in grDevices before they look 
>> elsewhere.  I thought that meant that S3 methods would be found there 
>> before they're found anywhere else, but I didn't actually check this. 
>> So let's check:
>>
>>  > boxplot.stats <- function(x, ...) stop("mine")
>>  > x <- 1
>>  > class(x) <- "stats"
>>  > boxplot(x)
>> Error in boxplot.stats(x) : mine
> 
>> Whoops!  Looks as though my local copy does get found first.  Not sure 
>> if this is a bug...
> 
> That's an interesting way to check.  If I enter
> boxplot.stats <- function(x, ...) stop("mine")
> boxplot(1)
> 
> I get a graph (i.e. no error) and so I concluded that the original
> boxplot is calling the original boxplot.stats.  In other words, the
> original is ignoring my local copy.
> 
>>> I tried to do as you suggested and create a local copy of boxplot.  I
>>> used the following commands:
>>> boxplot.stats <- edit(boxplot.stats)  # Made changes to line 14
>>> boxplot <- edit(boxplot)              
>>> boxplot.default <- edit(boxplot.default)  # Added a call to "cat()"
>>>
>>> When I called boxplot() the local copy was executed (as I could see the
>>> output of my "cat" commands), however it appears that the local copy of
>>> boxplot.stats isn't the one being called from my version of "boxplot".
>>> How do I fix this?
>> That's very strange.  Which R version are you using?  Are you sure the 
>> wrong version was being called?  I was doing my tests in 2.4.0.
> 
> I'm using 2.4.0 too (on Linux; sessionInfo() copied below)
> 
> If I execute the following:
> boxplot.stats <- function(x, ...) stop("mine")
> 
> boxplot <- edit(boxplot) 
>   # Added cat("local boxplot\n")
> 
> boxplot.default <- edit(boxplot.default) 
>   # Added cat("local boxplot.default\n")
> 
> boxplot(1) 
> 
> I get a graph with the text
> "local boxplot
> local boxplot.default"
> 
> Had boxplot.default called the local version of boxplot.stats, I would
> have expected the error "mine".

Sorry, I didn't realize that boxplot.default was calling boxplot.stats. 
  To get boxplot.default to call your local copy of boxplot.stats, you 
need to make a local copy of it, and (the part I left out before) set 
its environment to globalenv().  For example:

boxplot.default <- boxplot.default
environment(boxplot.default) <- globalenv()

The environment is where it goes to look for names that aren't defined 
locally within it.

> Is there a way I can avoid all this?  Perhaps I can somehow edit the
> file that R loads when it reads the original "boxplot.stats"?

Well, you can edit the source to R, but it's not usually advisable: 
when the next release comes out, you'll have to worry about merging your 
changes in.  It's better to write your own function with a different 
name to do what you want.

If you're sure your change is a good idea then post a patch here along 
with an explanation of why it's so good:  and it might make it into the 
next release.

Duncan Murdoch



More information about the R-help mailing list