[Rd] plot(<lm>): new behavior in R-2.2.0 alpha

Martin Maechler maechler at stat.math.ethz.ch
Sat Sep 17 17:29:20 CEST 2005


>>>>> "Wst" == Werner Stahel <stahel at stat.math.ethz.ch>
>>>>>     on Fri, 16 Sep 2005 09:37:02 +0200 writes:

    Wst> Dear Martin, dear Johns Thanks for including me into
    Wst> your discussion.

    Wst> I am a strong supporter of "Residuals vs. Hii"

    >>> One remaining problem I'd like to address is the
    >>> "balanced AOV" situation, ...

    Wst> In order to keep the plots consistent, I suggest to
    Wst> draw a histogram. Other alternatives will or can be
    Wst> interesting in the general case and therefore are not a
    Wst> suitable substitute for this plot.

hmm, but all other 3 default plots have
 (standardized / sqrt) residuals  on the y-axis.
I'd very much like to keep that for any forth plot.
So would we want a horizontal histogram?  And do we really want
a histogram when we've already got the QQ plot?

We need a decent proposal for a 4th plot 
{instead of  R_i vs h_ii  , when  h_ii are constant}
REAL SOON NOW  since it's feature
freeze on Monday. 
Of course the current state can be declared a bug and still be
fixed but that was not the intention...

Also, there are now at least 2 book authors among R-core (and
more book authors more generally!) in whose books there are
pictures with the "old-default" 4th plot. 
So I'd like to have convincing reasons for ``deprecating'' all 
the plot.lm() pictures in the published books.

At the moment, I'd still  go for
 
         R_i  vs i
or  sqrt|R_i| vs i  -- possibly with type = 'h' 

which could be used to "check" an important kind of "temporal" 
auto-correlation.

the latter, because in a 2 x 2 plot arrangement, this gives the
same y-axis as default plot 3.

    Wst> ........................

    Wst> Back to currently available methods:

    Wst> John Maindonald discusses different contours. I like
    Wst> the implementation I get currently in R-devel: contours
    Wst> of Cook's distances, since they are popular and we can
    Wst> then argue that the plot of D_i vs. i is no more
    Wst> needed.

what about John's proposal of different contour levels than
c(0.5, 1)  -- note that these *have* been added as arguments to
plot.lm() a user could modify.

    Wst> For most plots, I like to see a smoother along with the
    Wst> points.  I suggest to add the option to include
    Wst> smoothers, not only as an argument to plot.lm, but even
    Wst> as an option().  I have heared of the intense
    Wst> discussions about options().  With Martin, we arrived
    Wst> at the conclusion that options() should never influence
    Wst> calculations and results, but is suitable to adjust
    Wst> outputs (numerical: digits=, graphical: smooth=) to the
    Wst> user's taste.

{and John Fox agreed, `in general'}

That could be a possibility, for 2.2.0  only applied to
plot.lm() in any case, where plot.lm() would get a new argument

    add.smooth = getOption("plot.add.smooth")

What do people think about the name? 
it would ``stick with us'' -- so we better choose it well..

    >>> (4) Are there other diagnostics that ought to be
    >>> included in stats? (perhaps in a function other than
    >>> plot.lm(), which risks being overloaded).  One strong
    >>> claiment is vif() (variance inflation factor),

   ...................
   ...................
   ...................


    Wst> As we focus on plots, my plot method includes the
    Wst> option (default) to add smooths for 20 simulated
    Wst> datasets (according to the fitted model).

this and others are really nice.

However not for R 2.2.x in any case.

I agree that one should rather provide `single-plot'
functions and have plot.lm() just call a few of them; instead of
having things all part of plot.lm().
There's the slight advantage that you can guarantee some
consistence (e.g. in the definition of "standardized residuals")
and save some computations when have everything in one function,
but consistency should be possible otherwise as well...
Anyway this is for 2.3.0 or later.

Martin



More information about the R-devel mailing list