On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> 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