"Cromwell Enage" <sponage@yahoo.com> wrote in message news:20050324230240.97426.qmail@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