Re: [Rd] interaction.plot

From: Martin Maechler <>
Date: Thu 12 Aug 2004 - 03:14:17 EST

>>>>> "ChrBu" == Christoph Buser <>
>>>>> on Fri, 6 Aug 2004 10:24:40 +0200 writes:

    ChrBu> Dear R core team I've a proprosal to improve the
    ChrBu> function interaction.plot. It should be allowed to
    ChrBu> use type = "b". 

thank you for the suggestion.
I've implemented the above for R-devel several days ago.

    ChrBu> This can be done by changing the function's header from

    ChrBu> function( , type = c("l", "p"), )

    ChrBu> to

    ChrBu> function( , type = c("l", "p", "b"), )

    ChrBu> Then it works.

well, as I mentioned to you privately, it also needs a change in the legend() call subsequently.

    ChrBu> This type = "b" is useful, if the second level of the
    ChrBu> x.factor is missing for some level of the
    ChrBu> trace.factor. With type= "l" you loose first level of
    ChrBu> the x.factor, too (because you can't draw the line to
    ChrBu> the missing second level). With type = "p" so see
    ChrBu> this first level, but you have no lines at all (just
    ChrBu> chaos with points). With type = "b", you get all
    ChrBu> existing levels plus the lines between two contiguous
    ChrBu> levels (if they both exist).

    ChrBu> There is a second point. Using interaction.plot with     ChrBu> the additional argument main creates a warning:

    ChrBu> parameter "main" couldn't be set in high-level plot() function

    ChrBu> The reason is that "..." is used twice inside of     ChrBu> interaction.plot, in fact in

    ChrBu> matplot( ,...)

    ChrBu> and in

    ChrBu> axis( ,...)

    ChrBu> axis can do nothing with this argument main and
    ChrBu> creates this warning. You could replace ,... in the
    ChrBu> axis function by inserting all reasonable arguments
    ChrBu> of axis in the functions header (interaction.plot)
    ChrBu> and give over those arguments to axis. Then you
    ChrBu> shouldn't get this warning anymore.

yes, indeed.

Note however that this warning also happens with other such plotting functions and I find it is not a real blemish. Your proposed solution is not so obvious or easy, since axis() really has its own ``intrinsic'' ... argument and conceptually does accept many more possible "graphical parameters" in addition to its specific ones.

Hence I believe it would need quite a large extent of extra code in order to
1) keep the current potential functionality 2) always properly separate arguments to be passed to matplot()

   from those to be passed to axis().

Martin mailing list Received on Thu Aug 12 03:17:01 2004

This archive was generated by hypermail 2.1.8 : Wed 03 Nov 2004 - 22:45:05 EST