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
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 no
> 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 abo
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 requir
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 the
> > 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
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
> > > poi
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
> >
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 du
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
> > fr
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 uncertai
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 afte
12 matches
Mail list logo
