Numerical error in R (win32) (PR#8909)

classic Classic list List threaded Threaded
13 messages Options
ltp
Reply | Threaded
Open this post in threaded view
|

Numerical error in R (win32) (PR#8909)

ltp
Hi
    I had observed the following problem in R (also C, Matlab, and Python).
sprintf('%1.2g\n', 3.15)
give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
Java's System.out.printf is ok though.  
 
> round(3.75,1)
[1] 3.8
> round(3.15,1)
[1] 3.1
 
Similar outcome with sprintf in R.


However, the right answer should be 3.2
 
Regards
Teckpor
 

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

Duncan Murdoch
On 5/29/2006 12:22 PM, [hidden email] wrote:

> Hi
>     I had observed the following problem in R (also C, Matlab, and Python).
> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
>> round(3.75,1)
> [1] 3.8
>> round(3.15,1)
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2

This is not a bug.  There is no way to represent 3.15 exactly in double
precision, so it is hard to predict whether it will round up or down.
Apparently on the machine you were using it is represented as a number
slightly less than 3.15, which rounds down.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

Uwe Ligges
In reply to this post by ltp
[hidden email] wrote:

> Hi
>     I had observed the following problem in R (also C, Matlab, and Python).
> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
>
>>round(3.75,1)
>
> [1] 3.8
>
>>round(3.15,1)
>
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2

This is not a bug.

Please read the R FAQ "Why doesn't R think these numbers are equal?" and
after that note that *numerically* the following inaqualities are TRUE:
(3.2 - 3.15) > 0.05
(3.15 - 3.1) < 0.05

Uwe Ligges


> Regards
> Teckpor
>  
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

P Ehlers
In reply to this post by ltp
Did you check the Details section of the help page for round()?

Peter Ehlers

[hidden email] wrote:

> Hi
>     I had observed the following problem in R (also C, Matlab, and Python).
> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
>
>>round(3.75,1)
>
> [1] 3.8
>
>>round(3.15,1)
>
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2
>  
> Regards
> Teckpor
>  
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

Peter Dalgaard
In reply to this post by ltp
[hidden email] writes:

> Hi
>     I had observed the following problem in R (also C, Matlab, and Python).
> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
> > round(3.75,1)
> [1] 3.8
> > round(3.15,1)
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2

According to what? Remember that we're dealing with finite precision
binary arithmetic here:

>  (3.15 - 3.1)<.05
[1] TRUE
>  abs(3.15 - 3.2)>.05
[1] TRUE

See also FAQ 7.31.
 
> Regards
> Teckpor
>

--
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - ([hidden email])                  FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
ltp
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

ltp
Hi

        Thanks for the quick reply. However, I am not satisfied, as
> round(3.15000000, 1)
[1] 3.1
> round(3.75000000, 1)
[1] 3.8

        I think the problem is really more of an error in the rounding off
algorithm than finite precision.

Thanks
Teckpor

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter
Dalgaard
Sent: Monday, May 29, 2006 17:49
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)

[hidden email] writes:

> Hi
>     I had observed the following problem in R (also C, Matlab, and
Python).

> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
> > round(3.75,1)
> [1] 3.8
> > round(3.15,1)
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2

According to what? Remember that we're dealing with finite precision binary
arithmetic here:

>  (3.15 - 3.1)<.05
[1] TRUE
>  abs(3.15 - 3.2)>.05
[1] TRUE

See also FAQ 7.31.
 
> Regards
> Teckpor
>

--
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - ([hidden email])                  FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
ltp
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

ltp
In reply to this post by P Ehlers
Hi

        Thanks for the quick reply. However, I am not satisfied, as
> round(3.15000000, 1)
[1] 3.1
> round(3.75000000, 1)
[1] 3.8

        I think the problem is really more of an error in the rounding off
algorithm than finite precision.

Thanks
Teckpor

-----Original Message-----
From: Peter Ehlers [mailto:[hidden email]]
Sent: Monday, May 29, 2006 17:45
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)

Did you check the Details section of the help page for round()?

Peter Ehlers

[hidden email] wrote:

> Hi
>     I had observed the following problem in R (also C, Matlab, and
Python).

> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
>
>>round(3.75,1)
>
> [1] 3.8
>
>>round(3.15,1)
>
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2
>  
> Regards
> Teckpor
>  
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
ltp
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

ltp
In reply to this post by Duncan Murdoch
Hi

        Thanks for the quick reply. However, I am not satisfied, as
> round(3.15000000, 1)
[1] 3.1
> round(3.75000000, 1)
[1] 3.8

        I think the problem is really more of an error in the rounding off
algorithm than finite precision.

Thanks
Teckpor

-----Original Message-----
From: Duncan Murdoch [mailto:[hidden email]]
Sent: Monday, May 29, 2006 17:41
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)

On 5/29/2006 12:22 PM, [hidden email] wrote:
> Hi
>     I had observed the following problem in R (also C, Matlab, and
Python).

> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
>> round(3.75,1)
> [1] 3.8
>> round(3.15,1)
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2

This is not a bug.  There is no way to represent 3.15 exactly in double
precision, so it is hard to predict whether it will round up or down.
Apparently on the machine you were using it is represented as a number
slightly less than 3.15, which rounds down.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
ltp
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

ltp
In reply to this post by ltp
Hi

        Thanks for the quick reply. However, I am not satisfied, as
> round(3.15000000, 1)
[1] 3.1
> round(3.75000000, 1)
[1] 3.8

        I think the problem is really more of an error in the rounding off
algorithm than finite precision.

Thanks
Teckpor

-----Original Message-----
From: Uwe Ligges [mailto:[hidden email]]
Sent: Monday, May 29, 2006 17:45
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)

[hidden email] wrote:

> Hi
>     I had observed the following problem in R (also C, Matlab, and
Python).

> sprintf('%1.2g\n', 3.15)
> give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> Java's System.out.printf is ok though.  
>  
>
>>round(3.75,1)
>
> [1] 3.8
>
>>round(3.15,1)
>
> [1] 3.1
>  
> Similar outcome with sprintf in R.
>
>
> However, the right answer should be 3.2

This is not a bug.

Please read the R FAQ "Why doesn't R think these numbers are equal?" and
after that note that *numerically* the following inaqualities are TRUE:
(3.2 - 3.15) > 0.05
(3.15 - 3.1) < 0.05

Uwe Ligges


> Regards
> Teckpor
>  
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

Peter Dalgaard
In reply to this post by ltp
"ltp" <[hidden email]> writes:

> Hi
>
> Thanks for the quick reply. However, I am not satisfied, as
> > round(3.15000000, 1)
> [1] 3.1
> > round(3.75000000, 1)
> [1] 3.8
>
> I think the problem is really more of an error in the rounding off
> algorithm than finite precision.

It isn't, and adding zeros doesn't change anything. The issue is that
3.15 has a nonterminating binary expansion, just like 1/7 has a
nonterminating decimal one. Please do read the references that have
already been provided to you.
 
3.15 (dec) == 11.0010011001100110011... (bin)
3.75 (dec) == 11.11 (bin)

> Thanks
> Teckpor
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter
> Dalgaard
> Sent: Monday, May 29, 2006 17:49
> To: [hidden email]
> Cc: [hidden email]; [hidden email]
> Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)
>
> [hidden email] writes:
>
> > Hi
> >     I had observed the following problem in R (also C, Matlab, and
> Python).
> > sprintf('%1.2g\n', 3.15)
> > give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> > Java's System.out.printf is ok though.  
> >  
> > > round(3.75,1)
> > [1] 3.8
> > > round(3.15,1)
> > [1] 3.1
> >  
> > Similar outcome with sprintf in R.
> >
> >
> > However, the right answer should be 3.2
>
> According to what? Remember that we're dealing with finite precision binary
> arithmetic here:
>
> >  (3.15 - 3.1)<.05
> [1] TRUE
> >  abs(3.15 - 3.2)>.05
> [1] TRUE
>
> See also FAQ 7.31.
>  
> > Regards
> > Teckpor
> >
>
> --
>    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
>   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
>  (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
> ~~~~~~~~~~ - ([hidden email])                  FAX: (+45) 35327907
>
>

--
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - ([hidden email])                  FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

Peter Dalgaard
In reply to this post by ltp
"ltp" <[hidden email]> writes:

> Hi
>
> Thanks for the quick reply. However, I am not satisfied, as
> > round(3.15000000, 1)
> [1] 3.1
> > round(3.75000000, 1)
> [1] 3.8
>
> I think the problem is really more of an error in the rounding off
> algorithm than finite precision.

It isn't, and adding zeros doesn't change anything. The issue is that
3.15 has a nonterminating binary expansion, just like 1/7 has a
nonterminating decimal one. Please do read the references that have
already been provided to you.
 
3.15 (dec) == 11.0010011001100110011... (bin)
3.75 (dec) == 11.11 (bin)

> Thanks
> Teckpor
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter
> Dalgaard
> Sent: Monday, May 29, 2006 17:49
> To: [hidden email]
> Cc: [hidden email]; [hidden email]
> Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)
>
> [hidden email] writes:
>
> > Hi
> >     I had observed the following problem in R (also C, Matlab, and
> Python).
> > sprintf('%1.2g\n', 3.15)
> > give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
> > Java's System.out.printf is ok though.  
> >  
> > > round(3.75,1)
> > [1] 3.8
> > > round(3.15,1)
> > [1] 3.1
> >  
> > Similar outcome with sprintf in R.
> >
> >
> > However, the right answer should be 3.2
>
> According to what? Remember that we're dealing with finite precision binary
> arithmetic here:
>
> >  (3.15 - 3.1)<.05
> [1] TRUE
> >  abs(3.15 - 3.2)>.05
> [1] TRUE
>
> See also FAQ 7.31.
>  
> > Regards
> > Teckpor
> >
>
> --
>    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
>   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
>  (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
> ~~~~~~~~~~ - ([hidden email])                  FAX: (+45) 35327907
>
>

--
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - ([hidden email])                  FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

Berwin A Turlach
In reply to this post by ltp
G'day Teck,

I am taking R-bugs out of the recipient list because, as other have
pointed out to you, it definitely is not a bug and doesn't belong
there.

I was about to answer your e-mail yesterday, but then decided that my
reply was overly sarcastic, cancelled it and went home instead.  In
the morning, I noticed that you got four sound, polite answers that
were all explaining to you want was going on and, though they
contributed to filling up my mailbox I thought that this was o.k. and
would settle the matter.

But I really take offence of you continuing to fill up my mailbox with
the same nonsense answer to all four e-mails.  Since you seem to be so
desperate to get my opinion, here it is:

>>>>> "TL" == teck lim <[hidden email]> writes:

    TL> Thanks for the quick reply.
On behalf of the others, no problems.  We wished that you had taken
time to digest the answers and didn't feel the urge to immediately
reply to them again.

    TL> However, I am not satisfied, [...]
I am very sorry to hear that you are not satisfied, but what you
describe is a matter of finite precision arithmetic.  And silicon
chips don't care what you think or whether you are satisfied.

    TL> I think the problem is really more of an error in the rounding
    TL> off algorithm than finite precision.
I think the problem is rather that you are not willing to listen to
the advice and the information given to you.  My pet gripes these days
are:
a) the general level of innumeracy.
b) the level of numerical innumeracy among numerate people that start
   to do some computing.
c) the unwillingness of people to read up on material pointed out to
   them.

And there are a few more.  b) and c) seem to apply to you and, in
particular in respect to c), I find this highly worrying since you seem
to be at an academic institution.  I have actually quite some respect
for the work done at Imperial College, but if I see posts like this I
start to ask myself which direction it is exactly in which they are
leading science. :)

    TL> -----Original Message-----
    TL> From: Uwe Ligges [mailto:[hidden email]]
    TL> Sent: Monday, May 29, 2006 17:45

    UL> [hidden email] wrote:

    TL> Hi I had observed the following problem in R (also C, Matlab,
    TL> and Python).  sprintf('%1.2g\n', 3.15) give 3.1 instead of 3.2
    TL> whereas an input of 3.75 gives 3.8.  Java's System.out.printf
    TL> is ok though.
I don't see why this is a problem, and it seems that Java is out-voted
4 to 1.  Thus, while Java's output might find your approval, I think
you should, in true democratic fashion, accept the majority vote.  I
really wonder why you believe that the answer that you think is the
correct answer should be the correct answer just because one system
gives, for whatever reasons, the answer you expect.  On the other
hand, you might always try to persuade some American law makers to
legislate that 3.1 is the correct answer to settle the matter.  After
all, it seems Indiana once legislated that pi is equal to 3. :)

    >> However, the right answer should be 3.2
Says who?  So far, it seems it is you and Java against the
overwhelming majority.  And, even if this realisation might hurt you,
silicon chips give a stuff about what you or Java think the correct
answer should be.  For them the correct answer is governed by IEEE 754
and other such standards.

Furthermore, in the numerical analysis community the early versions of
Java were infamous for their implementation of finite precision
arithmetic, thus creating all kind of numerical precision problems
that were actually well known, well understood and avoidable.  My
understanding is that these days these problems are fixed, but it is
actually very hard to find a publication that says so.  It is very
easy to find publications that point out to problems with the
implementation of finite precision arithmetic in (early versions of)
Java.  So do not expect us to take Java's behaviour as being definite
proof for correct behaviour of finite precision arithmetic.

    UL> This is not a bug.

    UL> Please read the R FAQ "Why doesn't R think these numbers are
    UL> equal?"
I completely agree with Uwe and this is very good advice that you have
received.  Did you read up on that question?  To make it easier for
you to find it, it is R FAQ 7.31.  Did you read up on the references
given in the answer?  If so, you might have learned something instead
of continuing to waste bandwidth and fill other people mail-boxes.

    UL> and after that note that *numerically* the following
    UL> inaqualities are TRUE: (3.2 - 3.15) > 0.05 (3.15 - 3.1) < 0.05
Also, after reading the answer to the above FAQ, the literature cited
in the answer and trying out the code mentioned above (and that in
other replies), you might have realised what is going on.  Big hint,
think about how 3.15 and how 3.75 are represented inside a computer
and whether they can be represented exactly.  Then you may also
realise that specifying additional zeros in the literal constant that
you use doesn't make a iota difference.

If this is still too much effort for you to do, try the following
commands and reflect on their output.

> sprintf('%1.20g\n', 3.75)
[1] "3.75\n"
> sprintf('%1.20g\n', 3.15)
[1] "3.1499999999999999112\n"
> sprintf('%1.20g\n', 3.75000000)
[1] "3.75\n"
> sprintf('%1.20g\n', 3.15000000)
[1] "3.1499999999999999112\n"

I know, I should probably do the same thing as I did yesterday and hit
the delete button and go home instead of hitting the sent button.  But
this time I won't.  If anybody feels offended, my apologies.  

Cheers,

        Berwin

========================== Full address ============================
Berwin A Turlach                      Tel.: +61 (8) 6488 3338 (secr)  
School of Mathematics and Statistics        +61 (8) 6488 3383 (self)      
The University of Western Australia   FAX : +61 (8) 6488 1028
35 Stirling Highway                  
Crawley WA 6009                e-mail: [hidden email]
Australia                        http://www.maths.uwa.edu.au/~berwin

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Numerical error in R (win32) (PR#8909)

Tony Plate-3
In reply to this post by ltp
Beyond the R FAQ 7.31 the article "What Every Computer Scientist Should
Know About Floating-Point Arithmetic, by David Goldberg"
(http://docs.sun.com/source/806-3568/ncg_goldberg.html) is very
informative, but it is rather long (this topic has many subtleties).
Wikipedia has a shorter page on "Floating point arithmetic",
(http://en.wikipedia.org/wiki/Floating_point) which covers some of the
most important points for scientists who are not computer scientists,
and also has many links.

If it's really important to have exact representation for decimal
fractions, then look at the draft IEEE proposal for "General Decimal
Arithmetic" (http://www2.hursley.ibm.com/decimal/ ) which states:  "Most
computers today support binary floating-point in hardware.  While
suitable for many purposes, binary floating-point arithmetic should not
be used for financial, commercial, and user-centric applications or web
services because the decimal data used in these applications cannot be
represented exactly using binary floating-point. (See the Frequently
Asked Questions pages for more explanation and examples.)"

(I would quibble with the blanket statement that "binary floating-point
arithmetic should not be used for financial [...] applications" -- it
all depends on the needs of the particular financial application.)

I don't believe that there are any facilities in R for doing decimal
arithmetic, but I would guess that some accounting applications might
offer some.

-- Tony Plate

(I removed R-bugs from the cc list because it's not a bug, as has
already been noted.)

[hidden email] wrote:

> Hi
>
> Thanks for the quick reply. However, I am not satisfied, as
>
>>round(3.15000000, 1)
>
> [1] 3.1
>
>>round(3.75000000, 1)
>
> [1] 3.8
>
> I think the problem is really more of an error in the rounding off
> algorithm than finite precision.
>
> Thanks
> Teckpor
>
> -----Original Message-----
> From: Uwe Ligges [mailto:[hidden email]]
> Sent: Monday, May 29, 2006 17:45
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)
>
> [hidden email] wrote:
>
>
>>Hi
>>    I had observed the following problem in R (also C, Matlab, and
>
> Python).
>
>>sprintf('%1.2g\n', 3.15)
>>give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
>>Java's System.out.printf is ok though.  
>>
>>
>>
>>>round(3.75,1)
>>
>>[1] 3.8
>>
>>
>>>round(3.15,1)
>>
>>[1] 3.1
>>
>>Similar outcome with sprintf in R.
>>
>>
>>However, the right answer should be 3.2
>
>
> This is not a bug.
>
> Please read the R FAQ "Why doesn't R think these numbers are equal?" and
> after that note that *numerically* the following inaqualities are TRUE:
> (3.2 - 3.15) > 0.05
> (3.15 - 3.1) < 0.05
>
> Uwe Ligges
>
>
>
>>Regards
>>Teckpor
>>
>>
>> [[alternative HTML version deleted]]
>>
>>______________________________________________
>>[hidden email] mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel