[R] options("digits") and print.default()

[Prof Brian Ripley]

On Thu, 18 Jan 2007, Charles Dupont wrote:

> Prof Brian Ripley wrote:
>> On Mon, 15 Jan 2007, Ulrich Keller wrote:
>> 
>>> Hello everyone,
>>> 
>>> I use latex() (Hmisc) for report generation and thus have been affected by
>>> the problem with rounding decimals described, for example, in this post:
>>> 
>>> http://thread.gmane.org/gmane.comp.lang.r.general/73287/focus=73287
>>> 
>>> In short, numbers often are printed with 15 or so decimals even if there
>>> far less significant digits. The problem has been confirmed by Frank
>>> Harrell and Thomas Dupont according to this post:
>>> 
>>> http://thread.gmane.org/gmane.comp.lang.r.general/73172/focus=73186
>>> 
>>> But it has still not been fixed. Rather than changing all my reports I
>>> decided I'd look at format.df() in Hmisc myself and try to fix the problem
>>> there. I found that the problem is not in Hmisc at all, but in R itself:
>>> 
>>>> print(1.001)
>>> [1] 1.001
>>>> options(digits=16) #format.df does this
>>>> print(1.001)
>>> [1] 1.001000000000000
>>>> print(round(1.001, 3)) #rounding does not help
>>> [1] 1.001000000000000
>>> 
>>> This does not seem to be the behaviour described in the documentation,
>>> which says:
>>> 
>>> "The same number of decimal places is used throughout a vector,[sic!] This
>>> means that digits specifies the minimum number of significant digits to be
>>> used, and that at least one entry will be encoded with that minimum
>>> number. However, if all the encoded elements then have trailing zeroes,
>>> the number of decimal places is reduced until at least one element has a
>>> non-zero final digit."
>>> 
>>> If print.default() exhibited the behaviour desribed in the docs,
>>> format.df() and thus latex() would work as advertised, I think. I would
>>> have written a bug report instead of posting here, but the fact (?) that
>>> Frank and Thomas have confirmed the bug seems to indicate that the problem
>>> does indeed lie with Hmisc. Am I misunderstanding something here?
>>> 
>>> I use R version 2.4.1 Patched (2007-01-13 r40470) on Windows.
>> 
>> The bug is that Hmisc uses more digits than the representation provides:
>> 
>>> .Machine$double.eps
>> [1] 2.22044604925031e-16
>> 
>> If it used 15 digits (as R does for as.character) all would be well. Since 
>> R has to do the calculations you quote in binary arithmetic, they are also 
>> subject to representation error and there is no way they can be done to 16 
>> significant figures.  (I've traced the example, and that is what happens.) 
>> See ?as.character for more details.
>> 
>
> Is there an R object that contains the value of DBL_DIG for the current 
> machine?  I have checked '.Machine' and '.Platform' and neither have the 
> value of DBL_DIG in them.

No, but please do as I suggested and read ?as.character: it is 15 on all 
current platforms.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595