Skip to content

plot ignores type= "n" when x is factor (PR#13703)

5 messages · Paul Johnson, Brian Ripley, Barry Rowlingson +1 more

Original
Paul Johnson
# 
Full_Name: Paul E. Johnson
Version: 2.9.1
OS: Linux (Ubuntu 9.04)
Submission from: (NULL) (129.237.61.25)


x <- gl(2,50)
y <- rnorm(100)
plot(x,y)
plot(x,y, type="n")


I *wish* the last one would draw a blank plot box w/axes, but it does not. It
fills in the middle with a box plot. I've not seen this problem when x is
numeric.
11 days later
Brian Ripley
#
On Thu, 14 May 2009, pauljohn at ku.edu wrote:

            

      
      
      
    

        
Where did you get that?  Time travel?

            

      
      
      
    

        
Because this is a call to the 'factor' (see ?plot.factor).  Although 
?plot says

      ...: Arguments to be passed to methods, such as graphical
           parameters (see 'par'). Many methods will accept the
           following arguments:

           'type' what type of plot should be drawn.  Possible types are

'many' does not mean 'all' and all the other values of 'type' would be 
inappropriate for plot.factor.  Note that plot.factor is a wrapper for 
a call to barplot(), spineplot() or (in your case) boxplot(), which do 
not take a 'type' argument.

If plot.factor() or barplot() or boxplot() allowed a 'type' argument, 
what value would be appropriate to give the usual plot?  Not as far as 
I can see any of those listed in ?plot, and that says all other values 
are errors.


So, this is not a bug, it was not marked for the wishlist (see the R 
FAQ), and there seems no simple way to accommodate the implicit wish.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Paul Johnson
    

    

      
      #
    

  


  

      
On Tue, May 26, 2009 at 3:11 AM, Prof Brian Ripley

        
<ripley at stats.ox.ac.uk> wrote:

            

      
      
      
    

        
No, actually.  I used time travel to return to the present and
pre-maturely file the bug report :)

I knew the problem would still be there in 2.9.1 and I came back to
try to warn you about it.

            

      
      
      
    

        
Please look at this from the user's point of view.

There's no mention of plot.factor in the plot help page.  Aside from
reading the source code of the plot function (or your email), I don't
think a user would know that plot.factor is even involved in plot.

How about inserting this at the top of the help page for plot:

If either x or y is a factor variable, the plot.factor method is
called to determine the sort of graph to be drawn. If x and y are both
numeric, the type argument determines the sort of graph to be drawn.

If you did that, then you could answer my bug report with the
criticism that I did not read ?plot.factor or that plot.factor can't
do what I want. Otherwise, your response seems unkind and somewhat
unreasonable.  I have no way of knowing that plot.factor is even
involved when I try to use the plot function.

pj

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Barry Rowlingson
    

    

      
      #
    

  


  

      
On Tue, May 26, 2009 at 5:58 PM, Paul Johnson <pauljohn32 at gmail.com> wrote:

        

            

      
      
      
    

        
Yes there is, but hidden slightly more than the planning application
for the destruction of the Earth ("It was on display in the bottom of
a locked filing cabinet stuck in a disused lavatory with a sign on the
door saying 'Beware of the Leopard'"[1]). Here it is:

See Also:

     'plot.default', 'plot.formula' and other methods; 'points',
     'lines', 'par'.

 see that 'other methods'? That's it. That's a clue. That's our
'beware of the leopard'. So you need to know about methods...

            

      
      
      
    

        
Ah, but something like that would need inserting at the top of just
about every function. R has 'generic' functions that call specific
functions for specific types of object. In two (or more) different
ways. I'm not sure if there's an easy way to say 'get me the help for
the specific method for this thing X when I do foo(X)'.

 You can try: methods(class=class(factor(c(1,2,3,1)))) which will show
'plot.factor' as one of the possible things you can do with factor
objects. Then you can do help(plot.factor). You can also do
methods(plot) to show all the different classes that the generic plot
function can work on. But note these are 'S3' methods - once you hit
"S4" methods you'll need something else.

 And you can hit S4 methods in cruel and unusual ways. For example:

 > library(sp)
 > plot
 standardGeneric for "plot" defined from package "graphics"

function (x, y, ...)
standardGeneric("plot")
<environment: 0x842c6d8>
Methods may be defined for arguments: x, y
Use  showMethods("plot")  for currently available ones.

 Ooh, let's try that:

 > showMethods("plot")
 Function: plot (package graphics)
 x="ANY", y="ANY"
 x="SpatialLines", y="missing"
 x="Spatial", y="missing"
 x="SpatialPoints", y="missing"
 x="SpatialPolygons", y="missing"

 - no mention of factor there. That's because the sp package has
fiddled with the generic plot function to make it S4-compatible. The
S3 methods still work, but now you get added S4 method goodness.

 Yes, the plot function has changed in the middle of your R session.
And this isn't "mostly harmless[1]". Some code I wrote broke because
the new definition of 'plot' was evaluating the 'y' when I didn't want
it to. The previous definition didn't evaluate y until it got to my
generic function.

            

      
      
      
    

        
Perhaps an unkind and unreasonable response serves to shock people
into remembering these things -  people on the end of such treatment
don't seem to return to ask very many more questions...

Barry

[1] Hitchhikers' Guide To The Galaxy, Douglas Adams

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 5/26/2009 1:38 PM, Barry Rowlingson wrote:

            

      
      
      
    

        
There is, though it only works if X has an S4 class, so it doesn't work 
in this particular case.  You just use

?foo(X)

The mechanism could be extended to S3 classes by guessing that functions 
always dispatch on the class of the first argument, and that might be 
better than what we have now, but there's a lot of guesswork involved.

Duncan Murdoch