An update of my work is available in the <http://groups.yahoo.com/group/boost/files/> directory, filename mpl_math.zip (MSVC 6 SP 5 burped an error when compiling mpl_fraction.cpp; I didn't bother trying the other two examples on it.) --- Cromwell Enage <sponage@yahoo.com> wrote:
My current focus with regard to this endeavour is to provide a compile-time, arbitrary-precision integer that looks like this:
typedef big_integer<positive_sign,2,9,9,7,9,2,4,5,8> metric_speed_of_light; typedef big_integer<negative_sign,9,0,0,0,0,0,0,0,0,0> coulomb_constant;
Actually it's called "big_integral" now.
Once I get it to work, I should be able to roll out big_fraction and big_rational the same way I did fraction_c and rational_c, after which I'll consider building fixed_c on top of big_rational.
The negate, add, and multiply metafunctions are now operational for big_integral, but I still need to tackle divide, modulus, greatest_common_divisor, and least_common_multiple before I can build the other number meta-types.
Right now I could wrap the digits in a vector_c, with the unspecified digits set to -1, then perhaps use iter_fold_backward to convert it into a little-endian digit sequence so I could process the value more easily. I believe the issue there is that the user has to #define BOOST_MPL_LIMITS_VECTOR_SIZE before #including big_integer in order to increase the precision beyond 10 digits, right? What should I do in this case?
I haven't made the precision completely independent of BOOST_MPL_LIMITS_VECTOR_SIZE, but I've given the user the ability to increase the precision by setting the BOOST_MPL_LIMITS_BIG_INTEGRAL_DIGIT_COUNT_FACTOR macro to whatever value she deems fit. The default value is 4, which when multiplied with BOOST_MPL_LIMITS_VECTOR_SIZE amounts to a default precision of 40 digits. A minor issue with this setup is that when setting BOOST_MPL_LIMITS_BIG_INTEGRAL_DIGIT_COUNT_FACTOR the user should also set BOOST_MPL_BIG_INTEGRAL_DIGIT_TYPE to the appropriate integer type (unsigned int by default). Should I use MPL's sizeof construct to remove this potential dependency? BTW, I'm looking forward to the new MPL docs. Maybe then I'll learn to use MPL lambda + iterators properly instead of using Boost.PP as a crutch. Cromwell Enage __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/