[RkWard-devel] Pareto chart and Quality qontrol charts

[I. Soumpasis]

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



I disagree here because of the meaning of the data. Pareto chart is used
when you have data like this
A B C D E F
1 1 1 2 2 3
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.
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.
But the pareto.chart (and the plugin) is meaningless for
a <- rep (c (1, 1, 1, 2, 2, 3), length.out=100)
If these are the names the user must make them factor  so to make a
pareto.chart() and use the plugin.

Regards,
Ilias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070223/838754ff/attachment.html>