Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk