
Boost : 
From: Cromwell Enage (sponage_at_[hidden])
Date: 20040611 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 compiletime, arbitraryprecision 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 metatypes.
> 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
> littleendian 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 allnew Yahoo! Messenger.
http://messenger.yahoo.com/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk