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, [EMAIL PROTECTED] 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 ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
