# Boost :

From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-06-08 12:38:56

On 6/8/05, David Abrahams <dave_at_[hidden]> wrote:
> 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.

In that case VC7.1,VC8.0 beta and GCC3.2 got it wrong somewhere :)
(1.0<2.0) yields a compile-time bool,
long(2.0) yield a compile-time long.
On the above compilers, that is.

Regards,
Peder

>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>