Re: [boost] [MPL] rational_c and fixed_c

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-05-23 18:01:26

Cromwell Enage writes:
> A while back it was mentioned that
> boost::mpl::rational_c and boost::mpl::fixed_c needed
> redesigning.
> 
> Before I attempt to tackle this task anymore than I
> already have, I should have some questions answered.
> 
> 1.  For those compilers for which BOOST_NO_LIMITS is
> defined, I've learned that there is no way to include
> a floating-point number in an integral constant
> expression.  

As Dave already replied, BOOST_NO_LIMITS has no bearing on it;
it's simply not allowed.

> Does this mean that no matter how I define fixed_c::value, I 
> cannot pass fixed_c as a template argument to a metafunction 
> that ordinarily takes integral_c as input?  

Yep, that's what it means.

> Do I have to duplicate the functionality as a result?  

Well, it's not really _duplicating_ of functionality; you have
to implement the same set of primitives for a different 
representation, yes.

> If so, what should be the
> naming convention for these new metafunctions?

I assume we are talking about arithmetic metafunctions in particular.
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.

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

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

> 
> 4.  I only have to deal with rational numbers, right? 
> I don't have to worry about accurately representing a
> transcendental number or a complex-number expression?

As long as rational number representation gives us enough domain 
space, sure.

--
Aleksey Gurtovoy
MetaCommunications Engineering