Quantcast

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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Prof Brian Ripley
On Thu, 14 May 2009, [hidden email] wrote:

> Full_Name: Paul E. Johnson
> Version: 2.9.1

Where did you get that?  Time travel?

> 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.

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.

--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

PaulJohnson32gmail
On Tue, May 26, 2009 at 3:11 AM, Prof Brian Ripley
<[hidden email]> wrote:
> On Thu, 14 May 2009, [hidden email] wrote:
>
>> Full_Name: Paul E. Johnson
>> Version: 2.9.1
>
> Where did you get that?  Time travel?
>
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.


>>
>> 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.
>
> 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.
>
> -

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
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Barry Rowlingson
On Tue, May 26, 2009 at 5:58 PM, Paul Johnson <[hidden email]> wrote:

> There's no mention of plot.factor in the plot help page.

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...

> 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.

 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.

> 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.

 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

> On Tue, May 26, 2009 at 5:58 PM, Paul Johnson <[hidden email]> wrote:
>
>> There's no mention of plot.factor in the plot help page.
>
> 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...
>
>> 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.
>
>  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)'.

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

>
>  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.
>
>> 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.
>
>  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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Loading...