Re: [boost] [MPL] rational_c and fixed_c

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

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.
http://messenger.yahoo.com/