From: William Faulk <wfaulk_at_icoria.com>

Date: Tue 07 Dec 2004 - 02:28:30 EST

*>
*

*>
*

*> TL> On Fri, 3 Dec 2004, William Faulk wrote:
*

*> >> I'm still trying to install R on my Irix machine. Now I have a new problem
*

*> >> that crops up during the checks. I've found the root cause, and it's that R
*

*> >> is returning zero for certain things for reasons I don't understand.
*

*> >>
*

*> >> 2.225073859e-308, entered directly into R, responds "2.225074e-308".
*

*> >> 2.225073858e-308 responds "0".
*

*> >>
*

*> >> Their negative values respond similarly, so it would appear that somewhere in
*

*> >> there is the smallest absolute value that that installation of R will hold.
*

*>
*

*> TL> Yes. .Machine$double.xmin tells you the smallest number representable to
*

*> TL> full precision, which is 2.225074e-308 (I think on all machines where R
*

*> TL> works)
*

*>
*

*> >> On another machine where the checks passed, both responses are correct, not
*

*> >> just the first one. The underflow there is significantly lower, with much
*

*> >> less accuracy, as opposed to what seems to be good accuracy on what looks
*

*> >> like the broken one. The values there are:
*

*> >>
*

*> >> 2.4703282293e-324 gives 4.940656e-324
*

*> >> 2.4703282292e-324 gives 0
*

*>
*

*> TL> Machines can differ in what they do with numbers smaller than
*

*> TL> .Machine$double.xmin. They can report zero, or they can add leading zeros
*

*> TL> and so lose precision. Suppose you had a 4-digit base 10 machine with 2
*

*> TL> digits of exponent. The smallest number representable to full accuracy
*

*> TL> would be
*

*> TL> 1.000e-99
*

*> TL> but by allowing the leading digits to be zero you could represent
*

*> TL> 0.001e-99
*

*> TL> ie, 1e-102, to one digit accuracy (these are called "denormalized"
*

*> TL> numbers).
*

*>
*

*> TL> My Mac laptop denormalizes, and agrees with your other computer, giving
*

*> TL> the smallest representable number as 4.940656e-324. It is
*

*> TL> .Machine$double.xmin/2^52. This number has very few bits left to
*

*> TL> represent values, so for example
*

*> >> (a/2^52)*1.3==(a/2^52)
*

*> TL> [1] TRUE
*

*> TL> where a is .Machine$double.xmin
*

*>
*

*> (very nice explanation, thanks Thomas!)
*

*>
*

*>
*

*> TL> Both your machines should be correct. I don't think we deliberately
*

*> TL> require denormalized numbers to work anywhere.
*

*>
*

*> yes, indeed.
*

*> I can imagine that some of regression tests (aka "validation" !)
*

*> implicitly use some property -- but as Thomas said, that's not
*

*> deliberate (and a buglet in our tests).
*

*>
*

> William, could you move this topic from R-help to R-devel and

> give more specifics about what is failing for your installation?

*> 260c260
*

> < [1] 0.000000e+00 2.225074e-308 2.225074e-308 2.227299e-308 2.447581e-308

*> ---
*

*> 266c266
*

> < [1] 0.000000e+00 0.000000e+00 0.000000e+00 2.447581e-308 1.566452e-306 1.253162e-305

*> ---
*

*> 269,273c269,273
*

*> < [1,] 0e+00 0e+00 0.0e+00 0.00e+00 0.000e+00 0.0000e+00 0.00000e+00
*

*> < [2,] 0e+00 0e+00 0.0e+00 0.00e+00 0.000e+00 0.0000e+00 0.00000e+00
*

*> < [3,] 0e+00 0e+00 0.0e+00 0.00e+00 0.000e+00 0.0000e+00 0.00000e+00
*

*> < [4,] 0e+00 0e+00 2.4e-308 2.45e-308 2.448e-308 2.4476e-308 2.44758e-308
*

> < [5,] 2e-306 2e-306 1.6e-306 1.57e-306 1.570e-306 1.5660e-306 1.56650e-306

*> ---
*

*> 358c358
*

> < [1,] 4.141593+ 1i NaN+NaNi -Inf+NaNi

*> ---
*

*> OK
*

R-devel@stat.math.ethz.ch mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue Dec 07 02:34:37 2004

Date: Tue 07 Dec 2004 - 02:28:30 EST

Martin Maechler wrote:

>>>>>>"TL" == Thomas Lumley <tlumley@u.washington.edu> >>>>>> on Fri, 3 Dec 2004 15:22:07 -0800 (PST) writes:

> William, could you move this topic from R-help to R-devel and

> give more specifics about what is failing for your installation?

Sure. Sorry for talking on the wrong list.

The first problem I encountered with the checks has to do with R not understanding dates prior to 1/1/1970, but I'll start another thread for that.

The problem I'm talking about here occurs in print-tests.R. Here's the output from the make:

*> running code in 'print-tests.R' ... OK
**> comparing 'print-tests.Rout' to './print-tests.Rout.save' ...256c256
*

> < [1] 9

*> ---
*

>> [1] 11

> < [1] 0.000000e+00 2.225074e-308 2.225074e-308 2.227299e-308 2.447581e-308

>> [1] 2.002566e-308 2.222849e-308 2.225074e-308 2.225074e-308 2.225074e-308 2.227299e-308 2.447581e-308

> < [1] 0.000000e+00 0.000000e+00 0.000000e+00 2.447581e-308 1.566452e-306 1.253162e-305

>> [1] 2.002566e-308 2.447581e-308 1.281643e-306 1.566452e-306 1.025314e-305 1.253162e-305

> < [5,] 2e-306 2e-306 1.6e-306 1.57e-306 1.570e-306 1.5660e-306 1.56650e-306

>> [1,] 2e-308 2e-308 2.0e-308 2.00e-308 2.003e-308 2.0026e-308 2.00257e-308 >> [2,] 2e-308 2e-308 2.4e-308 2.45e-308 2.448e-308 2.4476e-308 2.44758e-308 >> [3,] 1e-306 1e-306 1.3e-306 1.28e-306 1.280e-306 1.2820e-306 1.28160e-306 >> [4,] 2e-306 2e-306 1.6e-306 1.57e-306 1.570e-306 1.5660e-306 1.56650e-306 >> [5,] 1e-305 1e-305 1.0e-305 1.03e-305 1.025e-305 1.0250e-305 1.02530e-305

> 355c355

> < 4.141593+ 1i 4.341593+ 10i NaN+NaNi Inf+ 0i -Inf+NaNi NaN+Infi

> ---

>> 4.141593+ 1i 4.341593+ 10i NA Inf+ 0i -Inf+NaNi NaN+Infi

> < [1,] 4.141593+ 1i NaN+NaNi -Inf+NaNi

>> [1,] 4.141593+ 1i NA -Inf+NaNi

> 364c364

> < [3,] NaN+ NaNi NaN+ Infi

> ---

>> [3,] NA NaN+ Infi

Hmm. You know, I just noticed that "OK" at the end. And then a very small error message afterwards about the next test, which also seems to have to do with dates.

So, uh, nevermind. I may bring up my other problems that I'm sure are actually problems. Or at least I am right now....

Sorry.

-Bitt

R-devel@stat.math.ethz.ch mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue Dec 07 02:34:37 2004

*
This archive was generated by hypermail 2.1.8
: Tue 07 Dec 2004 - 03:22:55 EST
*