[Rd] p.adjust(<NA>s), was "Re: [BioC] limma and p-values"
Martin Maechler
maechler at stat.math.ethz.ch
Tue Jan 18 12:53:30 CET 2005
>>>>> "MM" == Martin Maechler <maechler at stat.math.ethz.ch>
>>>>> on Mon, 17 Jan 2005 22:02:39 +0100 writes:
>>>>> "GS" == Gordon Smyth <smyth at wehi.edu.au>
>>>>> on Sun, 16 Jan 2005 19:55:35 +1100 writes:
<..............>
GS> 7. The 'n' argument is removed. Setting this argument
GS> for any methods other than "none" or "bonferroni" make
GS> the p-values indeterminate, and the argument seems to be
GS> seldom used.
GS> (It isn't used in the R default distribution.)
that's only any indication it *might* be seldom used...
we really have to *know*, because not allowing it anymore will
break all code calling p.adjust(p, meth, n = *)
GS> I think trying to combine this argument with NAs would get you
GS> into lots of hot water. For example, what does
GS> p.adjust(c(NA,NA,0.05),n=2) mean? Which 2 values
GS> should be adjusted?
The case where n < length(p) should simply give an error which
should bring you into cool water...
MM> I agree that I don't see a good reason to allow specifying 'n'
MM> as argument unless e.g. for "bonferroni".
MM> What do other think ?
no reaction yet.
I've thought a bit more in the mean time:
Assume someone has 100000 P values and knows that he
only want to adjust the smallest ones.
Then, only passing the ones to adjust and setting 'n = 100000'
can be useful and will certainly work for "bonferroni" but
I think it can't work in general for any other method.
In sum, I still tend to agree that the argument 'n' should be
dropped -- but maybe with "deprecation" -- i.e. still allow it
for 2.1.x giving a deprecation warning.
Martin
More information about the R-devel
mailing list