Duncan Murdoch wrote: > On 3/21/2007 3:39 AM, Martin Maechler wrote: >>>>>>> "Gabor" == Gabor Grothendieck <[EMAIL PROTECTED]> >>>>>>> on Tue, 20 Mar 2007 22:10:27 -0400 writes: >> Gabor> On 3/20/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> >> On 3/20/2007 1:40 PM, Gabor Grothendieck wrote: >> >> > On 3/20/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> >> >> On 3/20/2007 12:44 PM, Gabor Grothendieck wrote: >> >> >> > On 3/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> >> >> On 3/20/2007 11:19 AM, [EMAIL PROTECTED] wrote: >> >> >> >> > Full_Name: Charles Dupont >> >> >> >> > Version: 2.4.1 >> >> >> >> > OS: linux 2.6.18 >> >> >> >> > Submission from: (NULL) (160.129.129.136) >> >> >> >> > >> >> >> >> > >> >> >> >> > 'format.pval' has a major limitation in its implementation. >> For example >> >> >> >> > suppose a person had a vector like 'a' and the error being >> ±0.001. >> >> >> >> > >> >> >> >> > > a <- c(0.1, 0.3, 0.4, 0.5, 0.3, 0.0001) >> >> >> >> > > format.pval(a, eps=0.01) >> >> >> >> > >> >> >> >> > If that person wants to have the 'format.pval' output with 2 >> digits always >> >> >> >> > showing (like passing nsmall=2 to 'format'). That output >> would look like >> >> >> >> > this. >> >> >> >> > >> >> >> >> > [1] "0.10" "0.30" "0.40" "0.50" "0.30" "<0.01" >> >> >> >> > >> >> >> >> > That output is currently impossible because format.pval can >> only >> >> >> >> > produce output like this. >> >> >> >> > >> >> >> >> > [1] "0.1" "0.3" "0.4" "0.5" "0.3" "<0.01" >> >> >> >> > >> >> >> >> > >> >> >> >> > >> --------------------------------------------------------------- >> >> >> >> > a <- c(0.1, 0.3, 0.4, 0.5, 0.3, 0.0001) >> >> >> >> > format.pval(a, eps=0.01) >> >> >> >> >> >> >> >> But there's a very easy workaround: >> >> >> >> >> >> >> >> format.pval(c(0.12, a), eps=0.01)[-1] >> >> >> >> >> >> >> >> gives you what you want (because the 0.12 forces two decimal >> place >> >> >> >> display on all values, and then the [-1] removes it). >> >> >> >> >> >> >> > >> >> >> > Clever, but the problem would be that summary.lm, etc. call >> format.pval so the >> >> >> > user does not have a chance to do that. >> >> >> >> >> >> I don't see how this is relevant. summary.lm doesn't let you pass >> a new >> >> >> eps value either. Adding an "nsmall=2" argument to format.pval >> wouldn't >> >> >> help with the display in summary.lm. >> >> >> >> >> >> I suppose we could track down every use of format.pval in every >> function >> >> >> in every package and add nsmall and eps as arguments to each of >> them, >> >> >> but that's just ridiculous. People should accept the fact that R >> >> >> doesn't produce publication quality text, it just provides you >> with ways >> >> >> to produce that yourself. >> >> >> >> >> >> Duncan Murdoch >> >> >> >> >> > >> >> > You are right in terms of my example which was not applicable but I >> >> > think in general that format.pval is used from within other >> routines rather than >> >> > directly by the user so the user may not have a chance to massage it >> >> > directly. >> >> >> >> Right, but this means that it is more or less useless to change the >> >> argument list for format.pvals in the way Charles suggested, because >> all >> >> of the existing uses of it would ignore the new parameters. >> >> >> >> It would not be so difficult to change the behaviour of format.pvals >> so >> >> that for example "digits=2" implied the equivalent of "nsmall=2", but >> I >> >> don't think that's a universally desirable change. >> >> >> >> The difficulty here is that different people have different tastes for >> >> presentation-quality text. Not everyone would agree that the version >> >> with trailing zeros is preferable to the one without. R should be >> >> flexible enough to allow people to customize their displays, but not >> >> necessarily by having every print method flexible enough to satisfy >> >> every user: sometimes users need to construct their own output >> formats. >> >> >> >> Duncan Murdoch >> >> Gabor> One possibility would be to add args to format.pval whose defaults >> Gabor> can be set through options. Not beautiful but it would give the >> user >> Gabor> who really needed it a way to do it. >> >> Yes indeed, I had had the same thought (very early in this >> thread). This doesn't mean that I wouldn't agree with Duncan's >> statement above anyway. > > I think this is harder than it looks at first. The problem is knowing > where to stop. If the value of nsmall used by format.pval() when it > calls format() can be changed, why not other parameters? Why not allow > the same flexibility for other users of format.default()? What about > other defaults of format.pval and other format.XXX methods?
What about using attributes for format options? I proposed this for difftime objects here: http://tolstoy.newcastle.edu.au/R/e2/devel/07/02/2256.html Jeff > > I'd like to see some thought put into these questions before adding an > option, because if the option is too specific, it will make it harder to > make other such changes in the future. On the other hand, if it's too > general, it will be hard to document and unusable. > > Duncan Murdoch > >> Whereas I have strong opinion on *not* allowing options() to >> influence too many things [it's entirely contrary to the >> principle of functional programming], >> options() have always been used to tweak print()ing; so they >> could be used here as well. >> As original author of format.pval(), I'm happy to accept patches >> --- if they are done well and also patch >> src/library/base/man/format.pval.Rd and ..../man/options.Rd >> >> Martin > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- http://biostat.mc.vanderbilt.edu/JeffreyHorner ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
