
Boost : 
From: Andy Little (andy_at_[hidden])
Date: 20050511 05:25:28
"Cromwell Enage" wrote
>  Andy Little wrote:
>> disallowing negative denominator seems a little
>> harsh. 1 / 2 is a valid
>> mathematical expression.
>
> Very well. I'll move this restriction to
> mixed_number<>.
>
>> FWIW some comments on rational...
>>
>> 1) rational should have a value_type for similarity
>> with integral_c.
>> ( eg plus <Numerator,Denominator>::type::value_type;
>> )
>
> So, what should value_type be when either Numerator or
> Denominator are big_integral<>?
err... whatever the underlying type is. presumably long or long long?
But I see the problem. In hindsight .. I guess I can live without it.
>> 2) Because gcd is not a primitive operation( because
>> it can be expressed solely
>> in terms of others); Is there a need fo the 'impl
>> and '::apply rigmarole. I
>> think not(Same for abs, is_negative etc.)Why is
>> this amount of implementation
>> complexity necessary in gcd?.
>
> There may be an implementation of gcd<> that is more
> efficient even if it works solely on big_integral<>
> numbers.
Surely it would make sense to specialise this for big_int.
Or there may not, but for now, I shouldn't
> rule out anything that promises to make big_integral<>
> operations less expensive.
But these operations will now be unneccessarily expensive for small_int types.
Your version of gcd looks is obviously optimised for big_integral. However my
requirements on rational would be for a large number of smallint types. I hope
you will take this into account in the design and favour the implementation more
towards small_int types as well.
>> parameters pretty easily. FWIW Ive enclosed my
>> rendition of denominator
>> (hopefully boostified) in this method .
>
> I hadn't thought of this, yet. I'll do it, but I'll
> only specialize for integral_c_tag and
> big_integral_tag; the default implementation will look
> for the corresponding member type. Same for
> whole_part<>, rational_part<>, real_part<>, and
> imaginary_part<>.
OK maybe that would be quicker, and give better error messages. But you will
need a tag dispatch mechanism anyway wont you?, to avoid a large number of
specialisations.
>> Thanks for working on it though ... ;)
>
> Not a problem, whenever I have time. :)
Cheers
Andy Little
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk