[boost] Re: [mpl] Math sublibrary: new version.

From: Andy Little (andy_at_[hidden])
Date: 2005-05-11 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