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 (...).
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 >
From: Greg Kochanski> > 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.Sorry for butting in... I'm no expert in mosaic displays, and don't even use them very often, but I think the problem you're referring as a bug in R is more like a problem with the _method_ itself, (which will impact most, if not all, implementation of mosaic displays, not just R's). That's the reason Achim points to the reference cited by the help page. If that's the case, I doubt it's fair to expect software documentation to point out all possible (or known) problems with the methods it implements. Instead, I'd rather think that it's the user's responsibility to know what s/he is getting into.> > 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.R (and S) has the uncommon (if not unique) `feature' of turning users into developers, so there's not a sharp distinction between users and developers. Some of the package authors (including yours truly) really see themselves more as users than developers, or at least that's how we started in this wonderful environment. Perhaps you do not understand why the documentations in base R do/can not refer to contributed packages (as Achim stated). There are several, but the more obvious one is that contributed packages are not guanranteed to be there: Each package is required to have a maintainer, who is responsible for making necessary updates to keep the package up-to-date with R versions. A package not actively maintained is subject to removal from CRAN. Can you reasonably expect base R to cite contributed packages in such a setup? Cheers, Andy> > 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? > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > >
Prof Brian Ripley
2006-Jan-30 14:02 UTC
[Rd] References to contributed packages (was Re: Mosaicplot coloring)
On Mon, 30 Jan 2006, Liaw, Andy wrote:> Perhaps you do not understand why the documentations in base R do/can not > refer to contributed packages (as Achim stated). There are several, but the > more obvious one is that contributed packages are not guanranteed to be > there: Each package is required to have a maintainer, who is responsible > for making necessary updates to keep the package up-to-date with R versions. > A package not actively maintained is subject to removal from CRAN. Can you > reasonably expect base R to cite contributed packages in such a setup?As a general principle this is indeed so, but we do have some exceptions (look in the R Data Import/Export Manual for several), especially to the recommended packages. Where there is enhanced methodology in a package and as a result there are no plans to enhance the main R version and the package is stable and has maintainers with a track record of being responsive, we do consider adding a cross-reference (and indeed a cross-ref from mosaicplot to vcd has been floated before). And possibly under other circumstances too .... -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595