Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-07 19:34:06
>> Each of our back-ends is designed to maintain precision for add, sub, mul,
>> div, sqrt.
> Excellent, that's exactly what I wanted to know.
> So I would expect the relative error for those operations to be equal to 1
> machine epsilon.
> From a brief view on your implementation it seems that there is no way to
> get access to the internal data, exp, neg, fpclass members.
> Am I right? Could you expose those as readonly through a const accessor
> I need this functionality to be able to compare two floating point values
> within specified ulp range (units in the last place).
I believe the relative error in our basic operations is *less than* or equal
to one ULP. However, in portable C++, we can not hack the floating-point
type---never. One of our back ends has base-10. The other two have
an intriguing combinations of base-2. The hacks of the internal details
of these representations would not be portable.
Consider ldexp() and frexp().
With our strategy, the user is not granted access to the internal details of
the floating-point type. The facility std::numeric_limits<T> has
a member called epsilon(), which returns the smallest number in
a given floating-point system that differs from 1.
To test for relative (in)-equality within one ULP, you need to take the
ratio of two quantities, subtract this ratio from 1 and subsequently
take the absolute value of the result to obtain a basis for comparison
with 1 ULP.
This is the normal way for any floating-point type. It is a lot to take at first.
But no portable code can rely on the internal representation of the floating-point
type. You can only use library functions, limits and/or comparison.
I hope this helps.
Best regards, Chris.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk