[Rd] p.adjust(<NA>s), was "Re: [BioC] limma and p-values"
Martin Maechler
maechler at stat.math.ethz.ch
Sat Jan 8 17:19:23 CET 2005
>>>>> "GS" == Gordon K Smyth <smyth at wehi.edu.au>
>>>>> on Sat, 8 Jan 2005 01:11:30 +1100 (EST) writes:
<.............>
GS> p.adjust() unfortunately gives incorrect results when
GS> 'p' includes NAs. The results from topTable are
GS> correct. topTable() takes care to remove NAs before
GS> passing the values to p.adjust().
There's at least one bug in p.adjust(): The "hommel" method
currently does not work at all with NAs (and I have an
uncommitted fix ready for this bug).
OTOH, the current version of p.adjust() ``works'' with NA's,
apart from Hommel's method, but by using "n = length(p)" in the
correction formulae, i.e. *including* the NAs for determining
sample size `n' {my fix to "hommel" would do this as well}.
My question is what p.adjust() should do when there are NA's
more generally, or more specifically which `n' to use in the
correction formula. Your proposal amounts to
``drop NA's and forget about them till the very end''
(where they are wanted in the result),
i.e., your sample size `n' would be sum(!is.na(p)) instead of
length(p).
To me it doesn't seem obvious that this setting
"n = #{non-NA observations}" is desirable for all
P-value adjustment methods. One argument for keeping
``n = #{all observations}'' at least for some correction
methods is the following "continuity" one:
If only a few ``irrelevant'' (let's say > 0.5) P-values are
replaced by NA, the adjusted relevant small P-values shouldn't
change much, ideally not at all. I'm really no scholar on this
topic, but e.g. for "holm" I think I would want to keep ``full
n'' because of the above continuity argument.
BTW, for "fdr", I don't see a straightforward way to achieve the
desired continuity.
5D
Of course, p.adjust() could adopt the possibility of chosing how
NA's should be treated e.g. by another argument ``use.na = TRUE/FALSE''
and hence allow both versions.
Feedback very welcome, particularly from ``P-value experts'' ;-)
Martin Maechler, ETH Zurich
More information about the R-devel
mailing list