Full_Name: Greg Kochanski Version: 2.2.1 OS: Debian Linux (testing) Submission from: (NULL) (212.159.16.190) mosaicplot(x, shade=TRUE) is intended to color the blocks blue if they are more common than one might expect and red if they are rarer than one might expect. Unfortunately, if a block is much rarer than expected, it is so narrow that one cannot see the red. Thus, a casual inspection of the mosaicplot will miss some of the most statistically significant results. This is partially an intrinsic problem and cannot be entirely fixed, but it is made worse by the black outlines around each block. Blocks with very small probabilities show as black, not red. The broken outlines on the red blocks help, but not quite enough. I would suggest that there be an option to either turn off the black outlines when for the colored blocks, or an option to use colored outlines. If those options are somehow hidden in the ... part of the argument list for mosaicplot(), I apologize, but then this bug report should be converted to a documentation bug. Nowhere in help(mosaicplot) does it say what one can put into the unspecified arguments (...).
Mosaicplot coloring (PR#8537)
7 messages · greg.kochanski@phon.ox.ac.uk, Achim Zeileis, Greg Kochanski
On Sun, 29 Jan 2006 greg.kochanski at phon.ox.ac.uk wrote:
Full_Name: Greg Kochanski Version: 2.2.1 OS: Debian Linux (testing) Submission from: (NULL) (212.159.16.190) mosaicplot(x, shade=TRUE) is intended to color the blocks blue if they are more common than one might expect and red if they are rarer than one might expect. Unfortunately, if a block is much rarer than expected, it is so narrow that one cannot see the red.
Where is the bug?? Please read Section 9 in http://CRAN.R-project.org/doc/manuals/R-FAQ.html and also the posting guide at http://www.R-project.org/posting-guide.html
Thus, a casual inspection of the mosaicplot will miss some of the most statistically significant results.
Note that with this shading you are using colored cells and statistically significant results might not coincide.
This is partially an intrinsic problem and cannot be entirely fixed, but it is made worse by the black outlines around each block. Blocks with very small probabilities show as black, not red. The broken outlines on the red blocks help, but not quite enough. I would suggest that there be an option to either turn off the black outlines when for the colored blocks, or an option to use colored outlines.
For an enhanced implementation of mosaic plots written in the grid graphics system, see the package "vcd" and the functions mosaic() and strucplot(). See the package vignettes for details on control of the graphical appearance and also for combining shading and significance testing. To overcome the problem of small cells, another approach is to plot expected instead of observed frequencies. Z
If those options are somehow hidden in the ... part of the argument list for mosaicplot(), I apologize, but then this bug report should be converted to a documentation bug. Nowhere in help(mosaicplot) does it say what one can put into the unspecified arguments (...).
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Achim Zeileis wrote:
On Sun, 29 Jan 2006 greg.kochanski at phon.ox.ac.uk wrote:
Full_Name: Greg Kochanski Version: 2.2.1 OS: Debian Linux (testing) Submission from: (NULL) (212.159.16.190) mosaicplot(x, shade=TRUE) is intended to color the blocks blue if they are more common than one might expect and red if they are rarer than one might expect. Unfortunately, if a block is much rarer than expected, it is so narrow that one cannot see the red.
Where is the bug?? Please read Section 9 in http://CRAN.R-project.org/doc/manuals/R-FAQ.html and also the posting guide at
The bug is that the software produces results that could lead to the wrong conclusion in a research paper, or could lead the readers of the research paper to an erroneous belief. That sounds like a relevant definition of a bug to me. From section 9:
Finally, a command's intended definition may not be best for
> statistical analysis. This is a very important sort of problem, > but it is also a matter of judgment. > > ... The manual's job is to make everything clear. > It is just as important to report documentation bugs > as program bugs.... From my reading of section 9, this is a documentation bug. ...
For an enhanced implementation of mosaic plots written in the grid graphics system, see the package "vcd" and the functions mosaic() and strucplot(). See the package vignettes for details on control of the graphical appearance and also for combining shading and significance testing. To overcome the problem of small cells, another approach is to plot expected instead of observed frequencies. Z
You shouldn't be telling this to me, you should be putting it in the documentation where it might help more than one person. Putting a "see also" note in help(mosaicplot) that points to the "vcd" package, and "mosaic" and "strucplot" functions might be a solution to the problem.
On Mon, 30 Jan 2006, Greg Kochanski wrote:
The bug is that the software produces results that could lead to the wrong conclusion in a research paper, or could lead the readers of the research paper to an erroneous belief. That sounds like a relevant definition of a bug to me.
Maybe. However, it seems to be a bug in the way you interpret mosaic displays, not in the way they are implemented/documented in R. As I said before: This is a known issue with mosaic displays which is not so hard to find out if you consult the references given in ?mosaiplot. Another solution to your problem might be to use association plots (assoplot() is referred to in ?mosaicplot, assoc() is again a more flexible implementation in "vcd").
For an enhanced implementation of mosaic plots written in the grid graphics system, see the package "vcd" and the functions mosaic() and strucplot(). See the package vignettes for details on control of the graphical appearance and also for combining shading and significance testing. To overcome the problem of small cells, another approach is to plot expected instead of observed frequencies.
You shouldn't be telling this to me,
? If you don't want feedback, don't write to the lists.
you should be putting it in the documentation where
Note that I'm neither the author of the mosaicplot() function nor its manual page.
it might help more than one person. Putting a "see also" note in help(mosaicplot) that points to the "vcd" package, and "mosaic" and "strucplot" functions might be a solution to the problem.
vcd is `only' a contributed package on CRAN, hence not referred to from base packages. Z
Achim Zeileis wrote:
On Mon, 30 Jan 2006, Greg Kochanski wrote:
The bug is that the software produces results that could lead to the wrong conclusion in a research paper, or could lead the readers of the research paper to an erroneous belief. That sounds like a relevant definition of a bug to me.
Maybe. However, it seems to be a bug in the way you interpret mosaic displays, not in the way they are implemented/documented in R.
OK. Call it that if you want, though I expect that I share the bug with many other people.
As I said before: This is a known issue with mosaic displays which is not so hard to find out if you consult the references given in ?mosaiplot.
The problem I see is that you (as a representative for the r-project) are the wrong person to judge the success or failure of the documentation. You presumably know the software in detail. Documentation is (to at least some degree) intended for use by people who _do_not_ know the software well. Expecting a package's developer to judge documentation is like asking a bald man to judge which comb is best. He knows what a comb is for, he may remember using one, but it's not quite the same as actually needing and using one.
Another solution to your problem might be to use association plots (assoplot() is referred to in ?mosaicplot, assoc() is again a more flexible implementation in "vcd").
Thanks; that may help me; I appreciate the suggestion. (I must point out, though, it doesn't help improve mosaicplot().)
For an enhanced implementation of mosaic plots...
You shouldn't be telling this to me, you should be putting it in the documentation where
Note that I'm neither the author of the mosaicplot() function nor its manual page.
Just out of curiosity, why are you responding to bug reports that you don't have the power to fix?
Putting a "see also" note in help(mosaicplot) that points to the "vcd" package, ... might be a solution to the problem.
vcd is `only' a contributed package on CRAN, hence not referred to from base packages.
But, if the contributed packages are better (as you seem to say) than the base packages, perhaps they *should* be mentioned?
Greg:
OK. Call it that if you want, though I expect that I share the bug with many other people.
What I tried to say here was: Reports of user errors do not belong on R-bugs. A request on R-help would have been more likely to generate a useful, friendly and widely shared reply/discussion.
The problem I see is that you (as a representative for the r-project) are the wrong person to judge the success or failure of the documentation. You presumably know the software in detail. Documentation is (to at least some degree) intended for use by people who _do_not_ know the software well.
What I tried to say here was: The main problem is neither the software nor the documentation, but the way you use it and interpret its results.
Expecting a package's developer to judge documentation is like asking a bald man to judge which comb is best.
I would never make recommendations about combs.
Note that I'm neither the author of the mosaicplot() function nor its manual page.
Just out of curiosity, why are you responding to bug reports that you don't have the power to fix?
Because you did not report a bug. Furthermore, I thought I could give you a helpful pointer to other solutions to your problem. FYI: Meanwhile, R-core has signalled that they would add a cross reference to vcd in this case. Hence, I'll suggest a documentation patch to R-core. Best regards, Z
Achim Zeileis wrote:
Greg:
OK. Call it that if you want, though I expect that I share the bug with many other people.
What I tried to say here was: Reports of user errors do not belong on R-bugs. A request on R-help would have been more likely to generate a useful, friendly and widely shared reply/discussion.
And what I was trying to say is that any behaviour of a program that makes user errors likely can reasonably be considered a bug. I'll grant you that an individual user error is mere anecdotal evidence, but an individual's report combined with a plausible argument that other people will make the same mistake deserves some attention. I would make an analogy to accident reports from aircraft accidents. Most accidents are caused (at least in part) by user error, and yet the reports recommend design changes to the aircraft to minimize the probability of future errors.
FYI: Meanwhile, R-core has signalled that they would add a cross reference to vcd in this case. Hence, I'll suggest a documentation patch to R-core.
Thanks!