[R] Debugging R's code: boxplot.stats
Gabor Grothendieck
ggrothendieck at gmail.com
Mon Oct 30 01:47:44 CET 2006
On 10/29/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> On 10/29/2006 6:08 PM, Matthew Walker wrote:
> > On Sat, 2006-10-28 at 08:03 -0400, Duncan Murdoch wrote:
> >> On 10/27/2006 11:06 PM, Matthew Walker wrote:
> >>> Hi everyone,
> >>>
> >>> I think I have found a minor issue with the R function "boxplot.stats".
> >>> But before I make such a rash comment, I'd like to check my facts by
> >>> fixing what I think is the problem. However, why I try to do this, R
> >>> does not behave as I expect. Can you tell me what I'm doing wrong?
> >>>
> >>> If I use the command:
> >>> debug(boxplot.stats)
> >>> I am allowed to step through the code as normal.
> >>>
> >>> I then want to edit the function, so I type:
> >>> boxplot.stats <- edit(boxplot.stats)
> >>> and I make my changes.
> >>>
> >>> I can check my changes have been made by typing:
> >>> boxplot.stats
> >>> and the updated version appears on screen.
> >>>
> >>> But now when I come to test my changes, the "debug" functionality has
> >>> just up and disappeared; I can no longer step though the function as
> >>> normal. Further to that, it appears that the change has somehow not
> >>> been registered, as exactly the same error occurs---although I cannot be
> >>> sure that it is occurring inside boxplot.stats.
> >>>
> >>> Does anyone have any tips, suggestions or comments? I'd love to be able
> >>> to fix this.
> >>>
> >>> (For what it's worth I wish to change line 14 of boxplot.stats so that
> >>> it reads "if (any(out[nna],na.rm=TRUE))".)
> >> Besides what Gabor said, an issue here is that boxplot.stats lives in
> >> the grDevices namespace. If you call boxplot(), it will look there
> >> before it sees your locally modified copy.
> >>
> >> For testing, you can call boxplot.stats directly from the console, or
> >> also make a local copy of boxplot.
> >>
> >> Not sure why boxplot.stats is in grDevices rather than graphics, but
> >> that's not really relevant to your problems.
> >>
> >> Duncan Murdoch
> >>
> >
> > 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...
I think UseMethod uses dynamic scoping whereas ordinary funtions
use lexical scoping. From ?UseMethod
Name spaces can register methods for generic functions. To support
this, UseMethod and NextMethod search for methods in two places: first
in the environment in which the generic function is called, and then
in the registration data base for the environment in which the generic
is defined (typically a name space). So methods for a generic function
need to be available in the environment of the call to the generic, or
they must be registered. (It does not matter whether they are visible
in the environment in which the generic is defined.)
More information about the R-help
mailing list