[RkWard-devel] Grid, Stepfun and final (nearly) form of the clt plugin.

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Fri Mar 2 15:21:02 UTC 2007


On Friday 02 March 2007 08:39, Prasenjit Kapat wrote:
> Actually the col.01line is an extra option for plot.ecdf(). It is not
> included in plot.stepfun().

I see. Makes sense, then.

> But, even if grid() is embeded in plot_options (say under the Points/Lines
> tab below color?), it will not be automatically useable. A plugin planning
> to use grid() will have to modify the php file to include a few new lines
> of code, something like:
>
> if ($dogrid) { ?>
> try(grid(<? getRK_val ("plotoptions.grid.printout"); ?>));
> <?	}

True. I think we should place the grid.code.printout in the calculate() 
section of plot_options, though. Yes, it is a sort of misuse of that section. 
However, there are two advantages:

1) Embedding plugins need not know too much about the internal names used in 
plot_options (in this case, that there is a component called "grid", and that 
this component is an embedded plugin (instead of just a group of options)). 
Where possible we should avoid this, so the plot_options plugin can be 
reworked internally, without breaking embedding plugins.

2) This will easily be extensible to further features such as rug(), as those 
are just additional commands, that can be placed in the calculate() section.

> After doing all the neccessary plots commands.
>
> Should I go ahead and try to include it in plot_options (with the following
> logic) or postpone embeding grid altogether?
>
> <external id="allow_grid" default="false"/>
> <connect client="grid.visible" governor="allow_grid"/>

I think this would be relatively safe, as it does not change the default 
behavior, and does not add too much new plugin code to review. So go ahead.

> Yes, I was always confused with the indentation pattern in the php files. I
> am trying to fix on a standard protocol: Put the "<?" and "?>" markers on
> newlines so that the indentation of the php specific code is not disturbed.
> As for the R code, do not indent them w.r.t the php code, but rather to
> themselves, as if there were no php codes. I have done this in the
> plot_binomial_clt.php file, let me know if this looks fine, or is it an
> overkill of indentation? Let me know if there is a better protocol, which
> any of you use...

No, I think that's exactly the way to go:
1) The PHP portions should be indented, as though there was no R code between 
them.
2) The R code should be indented, as though there was no PHP code in between.
Of course, this protocol only works for statements that are complete lines. In 
other cases, the best solution is probably still to "inline" the PHP code, as 
in
my.fun (<? echo ($myfunopts); ?>)
where the PHP code is not indented at all, of course.

> Yes, I guess so. There is a little difficulty in getting rug under the
> (x11device) Edit menu. How will the plugin get the the variable x in
> rug(x,...)? It is doable as an embeded plugin using <external>, but how as
> a standalone one under (x11) Edit menu ?

Oh, yes. I simply had not thought about this. I guess it really is not 
possible.

> As for supporting left/right rugs, the "x" argument to rug(x,...) will need
> to the values on the y-axis, which is a little more work, coz, the plotted
> values will need to be extracted and stored away before plotting. I am not
> concerned for this ATM. Even R, talks of (Normally 1/3). Unless a concrete
> decision is made for the fate of rugs I'll leave them as it is (may be
> remove them alltogether from clt plugins).

I guess rug does not add too much value to the CLT plugins (even if you could 
get it to work on the y axis, that's probably not too informative, IMO), so 
it may indeed be the best choice to simply remove it, here.

> > That's strange, indeed. Interestingly, if you set ECDF to be the default
> > mode, it works correctly. Almost certainly a bug on the C++ side. I'll
> > look into it later (remind me, if I don't).
>
> Yes, you are right.... Take your time, not an urgent need. I can take
> the "rug" off the clt plugin altogether...

In fact, that's another nice thing about removing rug, here...

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/20070302/ac864008/attachment.sig>


More information about the Rkward-devel mailing list