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