
Boost : 
From: Andy Little (andy_at_[hidden])
Date: 20050328 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk