[boost] Re: [mpl] float representation

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

"Cromwell Enage" <sponage_at_[hidden]> wrote in message
news:20050328175235.71312.qmail_at_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