# Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-08 11:49:24

Peder Holt <peder.holt_at_[hidden]> writes:

> On 6/8/05, David Abrahams <dave_at_[hidden]> wrote:
>> Peder Holt <peder.holt_at_[hidden]> writes:
>>
> Currently, I use a naive approach, that does not handle rounding
> errors correctly for exponents.
>
> It goes something like this:
>
> #define REMOVE_EXP256(number) number*(number>1e256?1e-256:1.)
> #define REMOVE_EXP128(number) \
> REMOVE_EXP256(number)*(REMOVE_EXP256(number)>1e128?1e-128:1.)
> etc etc
> to
> #define REMOVE_EXP1(number)\
> REMOVE_EXP2(number)*(REMOVE_EXP2(number)>1e1?1e-1:1.)
>
> And similar for negative exponents.
>
> After removing the exponent (normalising the number)
> I convert the number to int:
>
> #define BOOST_META_NORMALISED_DOUBLE_TO_INTA(value)
> (value<0?-1:1)*int((value)*1e8)
>
> #define BOOST_META_NORMALISED_DOUBLE_TO_INTB(value)
> (value<0?-1:1)*int(((value)*1e8-int((value)*1e8))*1e8)
>
> As mentioned, since double is 2-based, the above approach gives
> round-off errors since it is 10-based.
>
> Replacing the above with a 2-based exponent seems to solve this problem

Maybe I'm missing something obvious, but I don't see how any of this
leads to compile-time constants. On a conforming compiler, a
calculation involving floating-point is not a compile-time constant.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com