"Cromwell Enage" <sponage@yahoo.com> wrote in message news:20050328175235.71312.qmail@web53907.mail.yahoo.com...

--- Andy Little wrote: ---

...

Why not call this one mixed_number?

...

IMO your fraction \ fraction_c functionality should be called rational \ rational_c for compatibility with the runtime boost::rational.

Okay. I suppose my choice of names was somewhat pedantic, more appropriate in elementary school than in here.

...

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.

You prefer something like the following?

rational_c<int,-11,16> mixed_number_c<int,-4,5,8> mixed_number_c<long,0,-6,7>

And of course its trivial to do rational_int<1,2> etc.

I guess the added readability would be worth the extra logic required to calculate the sign.

...

Surely better functionality and less namespace pollution could be had with a big_int parameter to the two param type.

You mean allowing Big Integral Constants as template arguments? This would eliminate the need for big_fraction/big_rational and big_mixed_number, but not the concepts they were meant to model.

IMO the rational Concept should hold independent of the exact parameters. The types used for the parameters are a trade off between using small_ints and having a relatively quick compile with the possibility of everflow, as againt big_integers with long compile (and posibly run ) times. I would guess that it would also be possible to create a type that switches from a small_int to a big_int representation when it detects overflow... and back if possible. Howver in a large number of cases a rational has known bounds, so an inbuilt int has ample range.

Shouldn't be too difficult to implement, but I need to cut down the compile times of the other big_integral test programs before testing rationals with such arguments becomes feasible.

I am wondering if the more lazy implementation possible by moving away from integral constant expansion might improve matters. OTOH perhaps it will make matters worse.( I am no expert on 'lazy' programming... but it must have some benefit ?) FWIW I have attached a proposed mpl::gcd which works on types and tries to be 'lazy'(with due attribution to Daryle Walker and Steven Cleary).

...

However currently the docs state the integral constant requirement on parameters which IMO is an unnecessary restriction.

Once I attempt to allow template arguments beyond Integral Constants and Big Integral Constants, I risk duplicating the functionality already provided by mpl::divides<>. Any good reason you'd want me to do this? For example, what would a recursive rational provide that dividing the fraction numerator by the fraction denominator would not?

It is merely one among several possible compile time types that Might be useful as parameters. Other possibilities are the aforementioned big_int and a complex, should One not try to make the thing generic as possible ? I dont think anything is lost by it. Even if the helper functions like gcd and abs are not useful for this they may come in useful somewhere else.

...

For example a more generic alternative to abs_integral could be implemented as follows, which might be a useful mpl function anyway.

Come to think of it, mpl::abs<> would be a useful metafunction indeed.

Alas ... As with you, I dont have the time to write this up properly.. regards Andy Little