[Rd] wishlist -- Fix for major format.pval limitation (PR#9574)

[Jeffrey Horner]

Duncan Murdoch wrote:
> On 3/21/2007 3:39 AM, Martin Maechler wrote:
>>>>>>> "Gabor" == Gabor Grothendieck <ggrothendieck at gmail.com>
>>>>>>>     on Tue, 20 Mar 2007 22:10:27 -0400 writes:
>>     Gabor> On 3/20/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>>     >> On 3/20/2007 1:40 PM, Gabor Grothendieck wrote:
>>     >> > On 3/20/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>>     >> >> On 3/20/2007 12:44 PM, Gabor Grothendieck wrote:
>>     >> >> > On 3/20/07, murdoch at stats.uwo.ca <murdoch at stats.uwo.ca> wrote:
>>     >> >> >> On 3/20/2007 11:19 AM, charles.dupont at vanderbilt.edu 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
http://biostat.mc.vanderbilt.edu/JeffreyHorner