[RkWard-devel] comments on plot_options and distribution plots

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Fri Feb 2 12:09:42 UTC 2007


On Friday 02 February 2007 02:00, Prasenjit Kapat wrote:
> may be allow_xlim and allow_ylim for the moment?

Added.

> > Well, there is a subtle difference: The current log option takes the log
> > of the value. The plot_options log option draws the scale logarithmic.
>
> I am not much aware of R internals, but I would like to know more
> about it. Any reference?

No good reference indeed. For this case it's obvious:

plot (function (x) df (x, [...], log=TRUE), [...])

here, first, the following will be computed for each value of x:

df (x, [...], log=TRUE)

and then that will be plotted. Hence the plot sees the log'ed values only, and 
simply plots them as usual (and so you'll get negative values in the y axis).

For the log parameter to par(), there seems to be no exact statement. The best 
documentation seems to be at ?plot.default, but it does not really say, 
whether it will log the value or just the scale. However the latter is what 
actually happens:

plot (function (x) df (x, [...], log=FALSE), [...], log="y")

> > This works, but probably we should not use it:
> > graphics:::plot.function (function (x) dbinom (x, size = 12, prob=0.5000,
> > log=TRUE), from=0, to=12, n=13, type="p", xlim=c (2,8))
>
> Again, why should we not use it?

Ok, maybe it's a corner case. On the one hand, note the triple colon operator. 
This is needed because plot.function is not an exported function of the 
graphics namespace. That's like saying "Warning! This is internal! It may 
change". I suspect, that strange "y" parameter that is passed from plot may 
be a left-over after some change to the plot.function arguments.
On the other hand, it does have a help-page of its own (but that says to use 
plot() with a function), and I don't know whether it's likely to actually 
change anytime soon.
Still, it just doesn't feel too comfortable.

> I have reported this problem to r-help with your code, let us see what
> they reply!

Thanks! I hope somebody did notice (usually replies come in faster). If there 
is no reply in a few days, maybe post to r-devel.

> > > x = seq(from=0,to=12,length=13)
> > > y = dbinom(x,size=12,prob=0.5)
> > > plot(x=x,y=y<? getRK ("plotoptions.code.printout"); ?>)
>
> Well if you add the allow_xlim and allow_ylim then I can include
> plot_option by setting allow_{xlim,ylim,log} to false. But again, I
> fail to understand the technical details of why using
> plot(x=x,y=y<?..?>) is to be avoided?

Well, it's mostly aestethics, and maybe you are right in that we should do 
this (even if the plot.function() thing gets fixed, somehow, that will not be 
before R 2.5, and we'll want to support older versions, too...). Some things 
to note, though:

Using x and y as temporary variables is dangerous. What if the user has 
objects x and y in the workspace? They'd be overwritten without prompting. No 
good thing.
So one approach we often use in the alternative is to use names 
like "rk.temp.x" and "rk.temp.y" instead. However, that would make the axis 
labels look silly, so we'd have to specify axis labels manually, getting in 
trouble with plot_options (which also supplies xlab and ylab parameters) 
again, on the way.
Maybe the following is a way out:

try (local ({
	x <- seq(from=0,to=12,length=13)
	plot (x, y=dbinom(x,size=12,prob=0.5))
}))

(local is used to make sure the x is not written to .GlobalEnv). The only 
downside is, that we add another seldom-used construct to the generated code, 
making it somewhat harder to understand. But probably still one of the better 
options left?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070202/014a4d9b/attachment.sig>


More information about the Rkward-devel mailing list