Re: [Rd] p.adjust(<NA>s), was "Re: [BioC] limma and p-values"

From: Martin Maechler <>
Date: Tue 18 Jan 2005 - 22:53:30 EST

>>>>> "MM" == Martin Maechler <>
>>>>> on Mon, 17 Jan 2005 22:02:39 +0100 writes:

 >>>>> "GS" == Gordon Smyth <>  >>>>> 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 mailing list Received on Tue Jan 18 22:09:43 2005

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:02:36 EST