Anything in the review queue?

[Don]

dsimcha wrote:
> On 3/20/2011 10:26 PM, bearophile wrote:
>> dsimcha:
>>
>>> On second thought, given the difficulty finding anything else, rational
>>> may be the thing that's most ready.  I'll offer it up for review now
>>
>> It's good to have rationals in Phobos, thank you.
>>
>> Is this GCD? There is already a gcd in Phobos. Is this efficient when 
>> numbers gets very large?
>> CommonInteger!(I1,I2) gcf(I1, I2)(I1 num1, I2 num2);
>>
> 
> I knew someone was going to ask this, so I probably should have answered 
> it pre-emptively.  std.numeric.gcd doesn't work with BigInts.  I'm 
> considering making my implementation private and eventually fixing 
> std.numeric rather than having duplicate public functionality.
> 
>>
>> An alternative is to give the number of binary digits of precision for 
>> the mantissa (see std.math.feqrel):
>> Rational!(Int) toRational(Int)(real floatNum, real epsilon = 1e-08);
> 
> That's worth considering.  The only reason I did it the way I did is 
> because the Maxima computer algebra system did it this way and, when in 
> doubt, I generally do what Maxima does in this library.  I also think 
> absolute error is the better metric for this case.  If you do:
> 
> auto foo = toRational!BigInt(1e-200);
> 
> Do we really want to return some ridiculously huge number (that possibly 
> overflows in the case of fixed width integers) for the denominator in 
> this case?

The original plan for BigInt was to have a BigRational type. Suppose 
that such a thing existed -- would it affect plans for this library?

I'm not sure that it is realistic to have a single templated type that 
does both BigInt rationals, together with rationals based on built-in 
integral types. The algorithms are different in a few respects:
(1) copying built-ins is practically zero cost;
(2) operations on BigInts depend on the size of the number (whereas for 
builtins, all operations are O(1));
(3) BigInts cannot overflow.
In particular, gcd algorithms for arbitrary precision types are quite 
different to gcd for built-ins.

I guess the primary question is:
If there were a BigRational type, would you still want rational?
Ie, are there use cases for rational over built-in types (rather than it 
just being a workaround for a lack of a BigRational type)?

If the answer to this question is yes, then I suspect that the semantics 
for rational over built-ins are so different to the semantics for 
BigRational, that the two could be relatively independent.