[boost] Re: [mpl] float representation

From: Andy Little (andy_at_[hidden])
Date: 2005-03-28 06:24:49

"Cromwell Enage" <sponage_at_[hidden]> wrote in message 
news:20050324230240.97426.qmail_at_web53902.mail.yahoo.com...
> --- Andy Little wrote: ---
>> What is the rationale for the 4 different types
>> representing rational fractions?
>
> Presumably you mean fraction, fraction_c, rational,
> and rational_c?
>
> The fraction_c struct template is simply a
> metafunction that returns a fraction type, and the
> rational_c struct template returns a rational type.
> (Or was it the other way around?)  The fraction struct
> template covers a smaller range of numbers than the
> rational struct template, but the rational struct
> template models the concept of a mixed number, which
> consists of a whole number part and a fraction part,

Why not call this one mixed_number?

> so I figured both the fraction and rational
> representations were essential.

 IMO  your fraction \ fraction_c functionality should be called rational \ 
rational_c for compatibility with the runtime boost::rational.
 FWIW IMO with your current 'rational, the extra parameters extend the range but 
not indefinitely and the extra number and  especially sign parameters are 
cumbersome. Surely better functionality and less namespace pollution could be 
had with a big_int parameter to the two param type.

>It certainly made
> implementation simpler.

This rationale sounds very dodgy to me  :-)

>> What is the rationale for making the numerator and
>> denominator types in fraction_c?
>
> In an earlier version, the numerator and denominator
> were defined by BOOST_STATIC_CONSTANT.  Looking
> through the Integral Constant Guidelines and the MPL
> source code, I read that certain compilers were likely
> to complain about the very code I used to have:
> BOOST_STATIC_CONSTANT before typedef statements,
> fraction_c<long,7,8>::value inside macros, etc.  Not
> that I have these compilers on hand, but I figured I
> wasn't making this sub-library just for myself,
> either, so I searched for a better representation.  Lo
> and behold, Aleksey Gurtovoy created a set of
> arithmetic metafunction classes that do the dirty work
> for me.  I simply built on top of his work.

I have been pondering your use of types v values and I grudgingly accept it. I 
dont like it because think it extends compile time and to some extent is 
pandering to non-conforming compilers. (I guess there are the lazy issues too) 
However using types does extend the possibility of the parameters to non 
integral constant types. One could use a recursive rational for example. However 
currently the docs state the integral constant requirement on parameters which 
IMO is an unnecessary restriction. For example a more generic alternative to 
abs_integral could be implemented as follows, which might be a useful mpl 
function anyway.

 template <typename T>
    struct abs : eval_if<
        less<
            T,
            minus<T,T> // find T's version of zero
        >,
        negate<T>,
        T
    >{};

I hope I will get time to try this out in more depth on the tentatively Renamed 
rational alias fraction

regards
Andy Little