[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