I would like to reply to the following email from May in the thread
[Rd] R 2.5.0 refuses to print enough digits to recover exact floating point
values
On Wed, May 23, 2007 at 06:32:36PM +0100, Prof Brian Ripley wrote:
I think this is a bug in the MacOS X runtime. I've checked the C99
On 5/23/07, Prof Brian Ripley [EMAIL PROTECTED] wrote:
[...]
It really is the case that writing out a number to 15 significant digits
and reading it back in again is not required to give exactly the same
IEC60559 (sic) number, and furthermore there are R platforms for which
this does not
Zack Weinberg wrote:
On 5/22/07, Uwe Ligges [EMAIL PROTECTED] wrote:
Zack Weinberg wrote:
I'd really appreciate some way of forcing R to print enough digits to
represent every possible IEEE double value. I would also argue that
this should be the default behavior of dump(),
On 5/22/07, Uwe Ligges [EMAIL PROTECTED] wrote:
Zack Weinberg wrote:
I have noticed that in R 2.5.0, no method of textual output will print
a double mode quantity with more than 15 digits after the decimal
point. From the help page (?print.default) it appears that this is
intentional,
On 5/23/07, hadley wickham [EMAIL PROTECTED] wrote:
On 5/22/07, Uwe Ligges [EMAIL PROTECTED] wrote:
Zack Weinberg wrote:
I have noticed that in R 2.5.0, no method of textual output will print
a double mode quantity with more than 15 digits after the decimal
point. From the help
Well, okay, now what about dump, write.table, save, etc?
save() uses the required precision. For exp(1) it stores
2.718281828459045 and you will see that
exp(1) == 2.718281828459045 is TRUE
save(...,ascii=TRUE) uses 16 digit precision, but this seems
not to be sufficient. In R-2.5.0,
This is an addition to my previous message.
16 digits are indeed not sufficient to represent a double
value exactly. The next table is calculated in bc calculator.
It shows that if we restrict (or round) double values
to 16 decadic digits then from 4 to 5 consecutive distinct
double values get
I think this is a bug in the MacOS X runtime. I've checked the C99
standard, and can see no limits on the precision that you should be able
to specify to printf.
Not that some protection against such OSes would come amiss.
However, the C99 standard does make clear that [sf]printf is not
I think this is a bug in the MacOS X runtime. I've checked the C99
standard, and can see no limits on the precision that you should be able
to specify to printf.
That seems quite possible - it's interesting that increasing the
number of digits (ie 1e7 vs 1e6) doesn't crash, but takes up about
I have noticed that in R 2.5.0, no method of textual output will print
a double mode quantity with more than 15 digits after the decimal
point. From the help page (?print.default) it appears that this is
intentional, since digits after the fifteenth may be uncertain.
However, fifteen digits after
Zack Weinberg wrote:
I have noticed that in R 2.5.0, no method of textual output will print
a double mode quantity with more than 15 digits after the decimal
point. From the help page (?print.default) it appears that this is
intentional, since digits after the fifteenth may be uncertain.
On 5/22/07, Uwe Ligges [EMAIL PROTECTED] wrote:
Zack Weinberg wrote:
I'd really appreciate some way of forcing R to print enough digits to
represent every possible IEEE double value. I would also argue that
this should be the default behavior of dump(), write.table() and
friends, and
12 matches
Mail list logo
