Mosaicplot coloring (PR#8537)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Mosaicplot coloring (PR#8537)

Greg Kochanski-4
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 (...).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mosaicplot coloring (PR#8537)

Achim Zeileis
On Sun, 29 Jan 2006 [hidden email] 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 (...).
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mosaicplot coloring (PR#8537)

Greg Kochanski-3


Achim Zeileis wrote:

> On Sun, 29 Jan 2006 [hidden email] 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
>

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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mosaicplot coloring (PR#8537)

Achim Zeileis
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mosaicplot coloring (PR#8537)

Greg Kochanski-3


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?

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mosaicplot coloring (PR#8537)

Achim Zeileis
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mosaicplot coloring (PR#8537)

Liaw, Andy
In reply to this post by Greg Kochanski-4
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?
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

References to contributed packages (was Re: Mosaicplot coloring)

Brian Ripley
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,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mosaicplot coloring (PR#8537)

Greg Kochanski-3
In reply to this post by Achim Zeileis


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!

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel