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

[Prasenjit Kapat]

Hi,

On Thursday 01 March 2007 04:49:51 pm Thomas Friedrichsmeier wrote:
> Why didn't you place the colors for 0 and 1 lines to the
> plot_stepfun_options? Formatting concerns? Any chance of working around
> those?

Actually the col.01line is an extra option for plot.ecdf(). It is not included 
in plot.stepfun().

> Indeed, it would probably be nice to have this in plot_options. I guess we
> could use the calculate() section for this and potential other extensions
> (such as rug), which require separate commands (not just options to plot).

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"); ?>));
<?	}

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"/>

> > Based on how "preview" works, as soon as this (grid) checkbox is
> > toggled, the whole graphics will be redrawn again, therby giving a "feel"
> > of grid on/off. Why is it a "feel"? Because for simulated data plots
> > (like distribution/clt plugins) every time the graphics is redrawn, it is
> > for a whole new set of random numbers. But again, this is the situation
> > with any GUI element not just the grid checkbox (if added).
>
> True, it's a bit awkward. On the other hand, outside the CLT plugins, the
> plotted data will typically be static instead of random, so I guess it's
> not too much to worry about.

Yes, I too think the same way. 

> 1) I believe the $mean and $var are only needed in the if ($scalenorm)
> case, and hence should be moved inside the if. Or maybe you can avoid these
> lines altogether, as they are really just two plain numbers (however, then
> it's not as easy to see, what those numbers signify, so not sure on this).

Ok, I have put it inside "if ($scalenorm) {}".

> 2) Maybe a few comments would be a nice extra, and help understand the
> code. Such as:
> # generate samples
> # normalize
> # adjust y range
> Not sure which ones, and how many, but it might make the code more legible.

Great, I will try to add some comments too. I realised that the php codes are 
indented rather badly, I will try to keep the indentations right henceforth, 
so that they are more readable. More on this below...

> 3) Move the $hist <- and $ylim <- outside the rk.graph.on()/off() block, as
> these are still preparation, not plotting.

Done.

> 4) I suggest to use a single try statement around all the plot functions.
> The main point of try in this case is to make sure we reach the
> rk.graph.off(), after we have made it to rk.graph.on().

Point taken and code modifed accordingly.

> 5) Indentation (my favorite nitpick):
> - I usually try to keep the indentation of the PHP code itself as it would
> be without the intervening printout. In this case, this would mean
> replacing some statement like
> <? }
> if (something) { ?>
> with
> <?	}
> 	if (something) { ?>
> There's single tab each, between "<?" and "}" and at the start of the
> second line.
> - In the generated code, the "try( lines(..." is indented by two spaces,
> but is not acutally on a different level of nesting than the lines below
> and above.

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

> > 4. As Thomas was saying, rug() is a generic plot feature, which can be
> > treated in a fashion similar to grid(). So, if everyone feel the same
> > way, I will remove "Rug options" from clt and add a new embedable plugin
> > which can be used anywhere (may be plot_options or may be (x11device)
> > VIew > Add Rug or somewhere once we reach a working solution for par()
> > options).
>
> I guess it would be similar to "grid". Note that for a rug-options plugin,
> it may make sense to support both top/bottom and left/right rugs.

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 ?

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

> > Once the rug issue for CLT is settled, I am planning to roll out the clt
> > plugin for all the distributions, and then be done with CLT. Now, that
> > means a lot of new files (19*3) under distributions dir. Is that fine, or
> > should we create a new dir (may be sub-dir under distribution)?
>
> I guess a sub-dir may make sense (distributions is a pretty crowded dir,
> already), but either way is fine with me.

Well, in that case, I will create a clt sub-dir under distributons and change 
the under_development file accordingly.

> Before rolling out the remaining CLT plugins, I suggest to get extensive
> review of the binomial CLT, first (as mentioned in the other mail).

Precisely, that was the reason I took the beta_clt plugin off svn. Lets get 
this done completely then one by one for the other distributions. 

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

Regards
PK