Boost logo

Boost :

From: Cromwell Enage (sponage_at_[hidden])
Date: 2004-06-02 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
(tested on MinGW 3.2 and MSVC 7.1).

--- Aleksey Gurtovoy <agurtovoy_at_[hidden]> wrote:
> Well, the ideal solution is outlined in
> 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 rational-to-fixed
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, one-third.

> > 3. Eventually the compile-time rational-number
> > representation will need to be converted to a
> runtime
> > floating-point 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>
    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 compile-time, arbitrary-precision integer
that looks like this:


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 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?

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 all-new Yahoo! Messenger.

Boost list run by bdawes at, gregod at, cpdaniel at, john at