"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