compile time version of double
I have now completed a compile time version of double which (as far as I have been able to test) the same results as the runtime equivalent. I have implemented mpl-support for all arithmetic operations plus all comparison operations. To test the accuracy, I have tested it against Cromwells sine-implementation (which by the way had a bug: In stead of 1-(angle*angle*/((2*i+2)*(2*i+3))*next_term it had (angle*angle*/((2*i+2)*(2*i+3))*next_term-1) and got the same result as a runtime-equivalent implementation of the same algorithm. There are four ways to construct a double: integral_to_double<mpl::int_<-355> > or integral_c_to_double<int,-355>::type string_c_to_double<3,'.',1,4,1,5,9,2,6,5,3,5,8,9,7,9,3,2,3,8,4,6,2,6,4,3,3,8,3,2,7,9> typedef BOOST_DOUBLE(3.141592653589793238462643383279502884197169399375105820974944592) pi; double_<mantissa<0x6487ed51,0x085a3000>,1,0> <-Equivalent of pi. The algorithm behind string_c_to_double is not very efficient, so if anyone has a better idea for an implementation, feel free to contribute :) BOOST_DOUBLE is a non-compliant macro that relies on compile time behaviour of floating operations. I have not yet added code to handle +-infinity,QNan,and SNan, but this is relatively easy. 0.0 is not represented correctly (has wrong exponent when converted to double) +0.0 does not equal -0.0 yet. On the upside, this implementation uses a 61 bit mantissa, so it is possible to utilize the full mantissa without rounding when calculating e.g. sine. This is done using boost::metamath::detail::plus_double_double<a,b>::type boost::metamath::detail::times_double_double<a,b>::type boost::metamath::detail::divides_double_double<a,b>::type The user should then deal with rounding before returning the final value: boost::metamath::detail::round<a>::type; or boost::metamath::detail::cutoff<a>::type; if no rounding is wanted. The source is available from the vault: http://boost-sandbox.sourceforge.net/vault/ <metamath.zip> Regards, Peder Holt
"Peder Holt" <peder.holt@gmail.com> wrote Hi Peder . The idea is cool, however ... mantissa.hpp requires #include <boost/mpl/bool.hpp> and requires return after final #endif However in VC7.1 using this test: #include <iostream> #include <boost/metamath/double.hpp> typedef BOOST_DOUBLE(3.33333333333333) d1; int main(){} I get these errors: Compiling... test.cpp e:\Projects\Test\test.cpp(4) : error C2513: 'int' : no variable declared before '=' e:\Projects\Test\test.cpp(4) : error C2146: syntax error : missing ';' before identifier 'd1' e:\Projects\Test\test.cpp(4) : fatal error C1004: unexpected end of file found
On 7/17/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
"Peder Holt" <peder.holt@gmail.com> wrote
Hi Peder . The idea is cool, however ...
mantissa.hpp requires #include <boost/mpl/bool.hpp> and requires return after final #endif
Oops. Fixed this + several other missing includes. Include files should now be self-contained.
However in VC7.1 using this test:
#include <iostream> #include <boost/metamath/double.hpp>
typedef BOOST_DOUBLE(3.33333333333333) d1;
int main(){}
I get these errors:
Compiling... test.cpp e:\Projects\Test\test.cpp(4) : error C2513: 'int' : no variable declared before '=' e:\Projects\Test\test.cpp(4) : error C2146: syntax error : missing ';' before identifier 'd1' e:\Projects\Test\test.cpp(4) : fatal error C1004: unexpected end of file found
There was a problem with BOOST_DOUBLE for VC7.1 which has now been corrected, but the problem you see here, is a missing include. BOOST_DOUBLE is defined in boost/metamath/double_macros.hpp Regards, Peder
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Peder Holt" <peder.holt@gmail.com> wrote
There was a problem with BOOST_DOUBLE for VC7.1 which has now been corrected, but the problem you see here, is a missing include. BOOST_DOUBLE is defined in boost/metamath/double_macros.hpp
Great . It works ok now. What does the following from your original post mean in more detail?: "BOOST_DOUBLE is a non-compliant macro that relies on compile time behaviour of floating operations." Does rthis mean that it only works on a few non-compliant compilers? Andy Little
On 7/18/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
"Peder Holt" <peder.holt@gmail.com> wrote
There was a problem with BOOST_DOUBLE for VC7.1 which has now been corrected, but the problem you see here, is a missing include. BOOST_DOUBLE is defined in boost/metamath/double_macros.hpp
Great . It works ok now.
What does the following from your original post mean in more detail?:
"BOOST_DOUBLE is a non-compliant macro that relies on compile time behaviour of floating operations."
Does rthis mean that it only works on a few non-compliant compilers?
It works on all VC versions, on all GCC versions up to 4.0, on Comeau in relaxed mode, and on the borland compiler. (Probably more as well, but those are the ones I have tested) Peder Holt
Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Peder Holt" <peder.holt@gmail.com> wrote
What does the following from your original post mean in more detail?:
"BOOST_DOUBLE is a non-compliant macro that relies on compile time behaviour of floating operations."
Does rthis mean that it only works on a few non-compliant compilers?
It works on all VC versions, on all GCC versions up to 4.0, on Comeau in relaxed mode, and on the borland compiler. (Probably more as well, but those are the ones I have tested)
The crucial question though is whether it is conforming C++ ?., or is it using non-standarad techniques, such as compile time addition of float and int as I believe happens in VC7.1. Andy Little
On 7/18/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
"Peder Holt" <peder.holt@gmail.com> wrote
What does the following from your original post mean in more detail?:
"BOOST_DOUBLE is a non-compliant macro that relies on compile time behaviour of floating operations."
Does rthis mean that it only works on a few non-compliant compilers?
It works on all VC versions, on all GCC versions up to 4.0, on Comeau in relaxed mode, and on the borland compiler. (Probably more as well, but those are the ones I have tested)
The crucial question though is whether it is conforming C++ ?., or is it using non-standarad techniques, such as compile time addition of float and int as I believe happens in VC7.1.
the BOOST_DOUBLE macro. relies on non-conforming C++. The implementation of double_ on the other hand is conforming C++. This is why I also supplied the string_c_to_double template, which is a conforming way to create a compile time double. Peder
Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- Peder Holt <peder.holt@gmail.com> wrote:
To test the accuracy, I have tested it against Cromwell's sine-implementation (which by the way had a bug: Instead of 1-(angle*angle*/((2*i+2)*(2*i+3))*next_term it had (angle*angle*/((2*i+2)*(2*i+3))*next_term-1)
Muy bien, jefe, I will fix it for my next version.
There are four ways to construct a double: integral_to_double<mpl::int_<-355> > or integral_c_to_double<int,-355>::type
string_c_to_double<3,'.',1,4,1,5,9,2,6,5,3,5,8,9,7,9,3,2,3,8,4,6,2,6,4,3,3,8,3,2,7,9>
typedef
BOOST_DOUBLE(3.141592653589793238462643383279502884197169399375105820974944592)
pi; double_<mantissa<0x6487ed51,0x085a3000>,1,0> <-Equivalent of pi.
The algorithm behind string_c_to_double is not very efficient, so if anyone has a better idea for an implementation, feel free to contribute :)
string_c_to_double looks interesting, perhaps I can use the underlying mechanisms to implement big_integral (which currently takes too many resources to compile, so "not very efficent" is better in this case).
On the upside, this implementation uses a 61 bit mantissa, so it is possible to utilize the full mantissa without rounding when calculating e.g. sine. This is done using
boost::metamath::detail::plus_double_double<a,b>::type
boost::metamath::detail::times_double_double<a,b>::type
boost::metamath::detail::divides_double_double<a,b>::type Would an MPL inner namespace be more appropriate? Say, boost::mpl::aux::double::plus<>, boost::mpl::aux::double::times, etc.
The user should then deal with rounding before returning the final value: boost::metamath::detail::round<a>::type; or boost::metamath::detail::cutoff<a>::type; if no rounding is wanted.
Would it be more practical to pass two arguments to each metafunction? Users don't always want to round to the nearest integer; e.g. for trigonometric apps one might need to round to the nearest PI/8.
The source is available from the vault: http://boost-sandbox.sourceforge.net/vault/ <metamath.zip>
Cool, I'll study it further when I get the chance. Cromwell D. Enage ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
On 7/17/05, Cromwell Enage <sponage@yahoo.com> wrote: <snip>
The algorithm behind string_c_to_double is not very efficient, so if anyone has a better idea for an implementation, feel free to contribute :)
string_c_to_double looks interesting, perhaps I can use the underlying mechanisms to implement big_integral (which currently takes too many resources to compile, so "not very efficent" is better in this case).
I think the implementation of divide_double_double is a better pattern to follow. It uses a minimum of template instantiations internally, but a pletorum of compile time constants. From my experience, this is much faster compile-time wise than the opposite. Ideally I would like to employ the same technique in string_c_to_double.
On the upside, this implementation uses a 61 bit mantissa, so it is possible to utilize the full mantissa without rounding when calculating e.g. sine. This is done using
boost::metamath::detail::plus_double_double<a,b>::type
boost::metamath::detail::times_double_double<a,b>::type
boost::metamath::detail::divides_double_double<a,b>::type
Would an MPL inner namespace be more appropriate? Say, boost::mpl::aux::double::plus<>, boost::mpl::aux::double::times, etc.
Maybe.
The user should then deal with rounding before returning the final value: boost::metamath::detail::round<a>::type; or boost::metamath::detail::cutoff<a>::type; if no rounding is wanted.
Would it be more practical to pass two arguments to each metafunction? Users don't always want to round to the nearest integer; e.g. for trigonometric apps one might need to round to the nearest PI/8.
Sorry. Bad explanation of what rounding means in this context: Rounding and cutoff here means fitting a 61 bit mantissa into a 52 bit mantissa by taking the 53'rd bit of the mantissa into account (rounding) or not (cutoff) Regards, Peder
The source is available from the vault: http://boost-sandbox.sourceforge.net/vault/ <metamath.zip>
Cool, I'll study it further when I get the chance.
Cromwell D. Enage
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/18/05, Peder Holt <peder.holt@gmail.com> wrote:
On 7/17/05, Cromwell Enage <sponage@yahoo.com> wrote:
<snip>
The algorithm behind string_c_to_double is not very efficient, so if anyone has a better idea for an implementation, feel free to contribute :)
<snip> I just updated the vault with a new and heavily improved version of string_c_to_double, which compiles much faster than the original one. It builds up the number using compile time constants, and iterates through the literals in the string using BOOST_PP macros. Compile time of the conforming string_c_to_double now matches the compile time of the non-conforming BOOST_DOUBLE macro. Regards Peder Holt
participants (3)
-
Andy Little -
Cromwell Enage -
Peder Holt