From: John Maddock (john_at_[hidden])
Date: 2005-12-05 06:27:01
> But this looks more sensible, but final eps shown is still zero.
> Note lo double has become denormalised.
> So what is the right value of epsilon - or rather the 'useful' value
> of eps?
I haven't looked at NTL, but I have been playing with the darwin long double
source, and have confirmed that you can can create numbers that have a
non-contiguous series of digits.
i.e. rather than R = x*2^y
we have R = x1*2^y1 + x2*2^y2
where y2 < y1 - std::numeric_limits<double>::digits.
If the digits were contiguous then the low part would be normalised so that
y2 == y1 - std::numeric_limits<double>::digits
in all cases, and the type would behave as a normal floating point number.
But as it is, you get the behaviour that Paul's observed: there's no way to
calculate epsilon, and maybe any value you calculate is meaningless anyway.
I guess if you take epsilon as a measure of error, then the worst case, is
also the usual definition of:
epsilon = 2^(1-D)
If there are D digits in the significand.
But the best case, is the same as the formal definition (the difference
between one and the next representable number), and gives:
epsilon = numeric_limts<double>::denorm_min()
So take your pick :-)
BTW, I think I can see why they did things this way: if long double is used
to temporarily increase the precision of some arithmetic operation, then
potentially the format used preserves additional information: particularly
for additions and subtractions, it *may* avoid catestrophic cancellation
errors. The trouble is you can't easily reason about when it will do it's
magic and when it won't. You can't even treat it as a number with twice the
precision of a double and ignore the occational extra precision: I suspect
(but can't prove)that it leads to the same problems you get with 10-byte
long doubles and double-rounding and other issues. It's counter intuitive,
but it's well known that there are some operations for which a little bit of
extra precision can actually give you the wrong answer (see
Just thought I'd confuse you all some more :-)
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk