[R] options("digits") and print.default()
Charles Dupont
charles.dupont at vanderbilt.edu
Thu Jan 18 18:06:29 CET 2007
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.
Thank you
Charles Dupont
--
Charles Dupont Computer System Analyst School of Medicine
Department of Biostatistics Vanderbilt University
More information about the R-help
mailing list