From wfaulk at icoria.com  Mon Dec  6 16:28:30 2004
From: wfaulk at icoria.com (William Faulk)
Date: Mon Dec  6 16:28:41 2004
Subject: [Rd] Re: [R] Odd underflow(?) error
In-Reply-To: <16817.41812.164656.71501@gargle.gargle.HOWL>
References: <41B0D42E.7000604@icoria.com>	<Pine.A41.4.61b.0412031512140.201322@homer06.u.washington.edu>
	<16817.41812.164656.71501@gargle.gargle.HOWL>
Message-ID: <41B47A9E.6000508@icoria.com>

Martin Maechler wrote:
>>>>>>"TL" == Thomas Lumley <tlumley@u.washington.edu>
>>>>>>    on Fri, 3 Dec 2004 15:22:07 -0800 (PST) writes:
> 
> 
>     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?

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
> 260c260
> < [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
> 266c266
> < [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
> 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
> ---
>> [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
> 358c358
> < [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
>  OK

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


[Rd] Re: [R] Odd underflow(?) error
William Faulk