On Jun 3, 2008, at 2:48 PM, Duncan Murdoch wrote: > On 6/3/2008 11:43 AM, Patrick Carr wrote: >> On 6/3/08, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>> >>> because signif(0.90, digits=2) == 0.9. Those two objects are >>> identical. >> My text above that is poorly worded. They're identical internally, >> yes. But in terms of the number of significant digits, 0.9 and 0.90 >> are different. And that matters when the number is printed, say as an >> annotation on a graph. Passing it through sprintf() or format() later >> requires you to specify the number of digits after the decimal, which >> is different than the number of significant digits, and requires case >> testing for numbers of different orders of magnitude. >> The original complainant (and I) expected this behavior from >> signif(), >> not merely rounding. As I said before, I wrote my own workaround so >> this is somewhat academic, but I don't think we're alone. >>> As far as I know, rounding is fine in Windows: >>> >>> > round(1:10 + 0.5) >>> [1] 2 2 4 4 6 6 8 8 10 10 >>> >> It might not be the rounding, then. (windows xp sp3) >> > signif(12345,digits=4) >> [1] 12340 >> > signif(0.12345,digits=4) >> [1] 0.1235 > > It's easy to make mistakes in this, but a little outside-of-R > experimentation suggests those are the right answers. The number > 12345 is exactly representable, so it is exactly half-way between > 12340 and 12350, so 12340 is the right answer by the unbiased round- > to-even rule. The number 0.12345 is not exactly representable, but > (I think) it is represented by something slightly closer to 0.1235 > than to 0.1234. So it looks as though Windows gets it right. > > >> OS X (10.5.2/intel) does not have that problem. > > Which would seem to imply OS X gets it wrong.
This has nothing to do with OS X, you get that same answer on pretty much all other platforms (Intel/Linux, MIPS/IRIX, Sparc/Sun, ...). Windows is the only one delivering the incorrect result here. > Both are supposed to be using the 64 bit floating point standard, > so they should both give the same answer: Should, yes, but Windows doesn't. In fact 10000.0 is exactly representable and so is 1234.5 which is the correct result that all except Windows get. I don't have a Windows box handy, so I can't tell why - but if you go through fprec this is what you get on the platforms I tested (log10 may vary slightly but that's irrelevant here): x = 0.123450000000000004174439 l10 = -0.908508905732048899217546, e10 = 4 pow10 = 10000.000000000000000000000000 x*pow10 = 1234.500000000000000000000000 Cheers, Simon > but the actual arithmetic is being done by run-time libraries that > are outside our control to a large extent, and it looks as though > the one on the Mac is less accurate than the one on Windows. > > > But (on both windows and OS X): >> > signif(12345.12345,digits=10) >> [1] 12345.12 > > This is a different problem. The number is correctly computed as > 12345.12345 (or at least a representable number quite close to > that), and then the default display rounds it some more. Set > options(digits=19) to see it in its full glory. > > Duncan Murdoch > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
