[RkWard-devel] plot.function and curve

[Prasenjit Kapat]

> > may be allow_xlim and allow_ylim for the moment?
>
> Added.

Thanks.

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

Yeah, thats true. I see the difference now.

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

Yeah which is rather confusing I guess.

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

Ok, now I understand and thus agree.

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

All right, that makes a lot of sense.

> 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

Now that is something I would like to keep in mind. May be it will come of help.

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

True and agreed. Thanks for explaining things in detail, I earnestly
appreciate it.

> Oh, yes, that's a real simple and clean solution, indeed. Wonder why this
> never occurred to me...

Ok then, I will change the functions to curve().

> > One other thing, like getRK_val() is there any setRK_val to set the value
> > of a certain GUI object from the php code, bay be during the preprocess
> > stage?
>
> No, there isn't. This would be possible to add. However the drawback will be
> that this will not become effective immediately, as the PHP-template is
> evaluated in a separate process. Probably not noticeable in most real world
> cases, but that's one reason why I never looked into that approach, much (*).
> Also, I'd probably have to check some recursion issues, so not something to
> add before 0.4.6.

Thats fine, I was just fancying the idea. If it is worth then may be
you can give it a thought later.

> What did you have in mind, specifically?

Well, it was this issue: when plot_options is embeded into other
plugin, whether or not the various plot_options variables can be set
from inside the embeding code. What happens is this: After I click on
"Plot options" button, the window opens with all parameters empty.
Suppose, the "preview" is enabled. I enter a value in the xlim "From"
field. The "preview" display goes blank. Because the parameter is set
to xlim=c(2,max()). Only when I input a valid (greater than From)
value in the "To" field of xlim, the display gets back to what is
intended. There are two possiblities:
a) somehow prevent the xlim from being evaluated unless both the
entries are valid.
OR
b) preset the the xlim values based on the current plot parameters
(par("usr")). But this options is not good. Querying par("usr") opens
up a empty X11 device, if none exist.

Basically, the broader idea is to show the user the current par()
values when plot_options is used. Then let the user change them if
he/she feels so. We can put an "advanced" tab in plot_options for
doing this!

Anyway, I guess all this is just food for thought in the long run.

> Currently I have an eye on KJSEmbed (yes, I know, javascript is not much of a
> loved language, but it comes pre-installed/loaded with kdelibs, and seems to
> offer many of these features), but I haven't evaluated this in depth, and
> KJSEmbed could do with some better documentation.

I agree, javascript has always been an issue in KDE. I have never been
able to make R's html search work with konqueror. I have to use
firefox for this. Anyway, we can keep these things in mind for future
versions.

Thanks
PK.