Re: [boost] [MPL] rational_c and fixed_c

From: Cromwell Enage (sponage_at_[hidden])
Date: 2004-06-11 23:00:25

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_at_[hidden]> 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/