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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
TL> Sent: Monday, May 29, 2006 17:45
UL> [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
Australia http://www.maths.uwa.edu.au/~berwin
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
