<br><br><div><span class="gmail_quote">2007/2/23, Thomas Friedrichsmeier <<a href="mailto:thomas.friedrichsmeier@ruhr-uni-bochum.de">thomas.friedrichsmeier@ruhr-uni-bochum.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Ilias,<br><br>On Friday 23 February 2007 20:07, I. Soumpasis wrote:<br>> I tried the above and I send it as tar.gz file. It does not supress plot<br>> but prints only the table. If there is a preview window open then user does
<br>> not sees anything, but if it is not, then it pops up a window with the<br>> plot.<br>><br>> I do not know if this is an acceptable solution, that's why I send it here.<br>> If you have something other simple go on. Otherwise making a new plugin as
<br>> said above it is an overkill and I do not know how useful it might be.<br><br>I see two problems with this approach (only with the "Print plot" option<br>unchecked):<br>1) A plot will always be produced, and there is no way around this using
<br>pareto.chart(). Of course we can keep it from going to the output, but it<br>will still be generated. So this option is a bit confusing, and might<br>actually do (slight) harm, if the user has a previous plot in an active
<br>active device, and then tries to get the descriptives only: He'll get the<br>descriptives alright, but also his previous plot will be overwritten.<br>2) For the case where only descriptives are wanted, using pareto.chart
() (as<br>and R function) is overkill. Overkill not in the sense of too much work for<br>us (as you pointed out, it's a lot less), but in the sense of requiring the<br>user to load a package (qcc) that is not actually needed for the job, and
<br>always does a plot as a side-effect.<br><br>> I personally find the plugin as is full of capabilities because most of the<br>> users will need both plot and results.<br><br>Well, and I think this is the bright side of it: There is no urgent need to
<br>create a second plugin, even though in the long run, I think there should be<br>one. For now, your plugin can cover both tasks, even if the second one could<br>be handled more efficiently in a separate plugin.<br><br>
My suggestion: Leave the plugin essentially as is, but remove the "Print plot"<br>option again. It's rather confusing, in that a plot is still generated (just<br>not added to the output), and that may even be harmful in some situations the
<br>user should never need to worry about. Rather leave it as a plot with<br>the "added value" of also giving the descriptives, if that is wanted.<br><br>Note that the comment about using table() from my previous mail still applies
<br>to this plugin: I think something like this would be needed in this section:<br><br>rk.temp.x <- (<? echo ($vars); ?>)<br>if(is.factor(rk.temp.x)) {<br>        rk.temp.x <- summary(rk.temp.x)<br>}<br><br>I simply think that in most situations the following:
<br><br>rk.temp.x <- (<? echo ($vars); ?>)<br>if(!is.table(rk.temp.x)) {<br>        rk.temp.x <- table(rk.temp.x)<br>}<br><br>would be closer to the expected result. Currently the plugin works nicely for<br>factors, but for vectors it typically does not produce a useful plot. 
E.g.<br>try with these two objects:<br><br>a <- rep (c (1, 1, 1, 2, 2, 3), length.out=100)<br>b <- as.factor (a)</blockquote><div><br> </div></div>I disagree here because of the meaning of the data. Pareto chart is used when you have data like this
<br>A B C D E F <br>1 1 1 2 2 3<br>Suppose that the above is type of defects, you can take the pareto chart with the most serious of them. It has a different approach of the barplot. <br>The summary(factor) gives the the factor variable in this way to help the user not to have to make a new variable in order to use the plugin.
<br>But the pareto.chart (and the plugin) is meaningless for <br>a <- rep (c (1, 1, 1, 2, 2, 3), length.out=100)<br>If these are the names the user must make them factor  so to make a pareto.chart() and use the plugin. 
<br><br>Regards,<br>Ilias<br>