R help - Dec 2004 - Odd underflow(?) error

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.

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

My first thought was that GMP and/or MPFR weren't working properly, so I 
recompiled GMP, which passed all of its tests, and GCC, making sure to 
imclude support for them.  This made no difference.

Anyone have any ideas, including which one is broken?  Both?

-Bitt

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.
Yes.  .Machine$double.xmin tells you the smallest number representable to 
full precision, which is 2.225074e-308 (I think on all machines where R 
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
Machines can differ in what they do with numbers smaller than 
.Machine$double.xmin. They can report zero, or they can add leading zeros 
and so lose precision.  Suppose you had a 4-digit base 10 machine with 2 
digits of exponent.  The smallest number representable to full accuracy 
would be
     1.000e-99
but by allowing the leading digits to be zero you could represent
     0.001e-99
ie, 1e-102, to one digit accuracy (these are called "denormalized" 
numbers).

My Mac laptop denormalizes, and agrees with your other computer, giving 
the smallest representable number as 4.940656e-324. It is 
.Machine$double.xmin/2^52.   This number has very few bits left to 
represent values, so for example
> (a/2^52)*1.3==(a/2^52)
[1] TRUE
where a is .Machine$double.xmin


Both your machines should be correct. I don't think we deliberately 
require denormalized numbers to work anywhere.


 	-thomas