
Boost : 
From: Cromwell Enage (sponage_at_[hidden])
Date: 20040602 22:01:59
I now have a working implementation of fraction_c and
rational_c, as well as arithmetic metafunctions that
operate on them, at
<http://groups.yahoo.com/group/boost/files/mpl_math.zip>
(tested on MinGW 3.2 and MSVC 7.1).
 Aleksey Gurtovoy <agurtovoy_at_[hidden]> wrote:
> Well, the ideal solution is outlined in
>
http://article.gmane.org/gmane.comp.lib.boost.user/5668/,
> but for
> the purpose of implementing the functionality itself
> I suggest you
> abstract from all these complications and simply
> name these as
> you wish, e.g. 'fp_plus', 'fp_minus', etc., or
> anything along these
> lines.
Yeah, I'll hold off on implicit rationaltofixed
conversions et. al. for a while.
> > 2. Should I define fixed_c in terms of
> rational_c, to
> > reduce the amount of functionality I may need to
> > duplicate? Something like this:
> >
> > template <typename IntType, IntType N,
> > IntType PowerOf10>
> > struct fixed_c
> > {
> > typedef rational_c<IntType,...,...>
> > type;
> > };
>
> If it gives us a satisfactionary range of
> representable values, sure.
Hmmm, maybe it won't. A decimal of sufficient size
may be out of the value range that a rational (which
I've actually implemented as a fraction) may
represent; likewise, no decimal in mathematical
existence can exactly represent, say, onethird.
> > 3. Eventually the compiletime rationalnumber
> > representation will need to be converted to a
> runtime
> > floatingpoint value. Should I define this
> conversion
> > function within rational_c (which means an
> additional
> > template parameter, with either function or class
> > scope, defining the return value type), within a
> > wrapper struct, or somewhere else? And how?
>
> Within the wrapper struct, in form of a conversion
> operator, so we
> can write something like
>
> typedef float_<2,718281828> e;
> std::cout << e;
Ah, haven't done that yet. What I've done for the
moment was something like this:
typedef rational_c<int,4,5,8> shoe_size;
typedef rational_wrapper<float,shoe_size>
shoe_wrap;
std::cout << shoe_wrap::value();
That's what I actually meant by wrapper struct, but if
you want me to use a default return type, I should be
able to reduce the code down to your type of syntax.
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;
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 challenge I face now, of course, is getting
big_integer to work.
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?
BTW, how and where should I provide MPL lambda
support, if at all? Admittedly I have no idea how
that works.
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