Bonjour Vik,
> Here is an updated patch fixing that.
As I said, welcome to arithmetic:-)
Patch v5 applies cleanly.
Doc: I'd consider using an example the result of which is 42 instead of
21, for obvious geek motivations. Possibly gcd(2142, 462) should be ok.
I got it wrong with my previous comment on gcd(int_min, 0). I'm okay with
erroring on int_min.
Code comments: gcd(n, 0) = abs(n), not n?
About the code.
Add unlikely() where appropriate.
I'd deal with int_min and 0 at the beginning and then proceed with
absoluting the values, rather than the dance around a1/arg1, a2/arg2, and
other arg2 = -arg2, and arg1 = -arg1 anyway in various places, which does
not make the code that easy to understand.
Pseudo code could be:
if ((a1 == min && (a2 == min || a2 == 0)) ||
(a2 == min && a1 == 0))
error;
a1 = abs(a1), a2 = abs(a2);
euclids;
return;
Note: in the numeric code you abs the value, ISTM consistent to do it as
well in the other implementations.
Would it make sense that NAN is returned on NUMERIC when the computation
cannot be performed, eg on non integer values?
Why the positive constraint on LCM(NUMERIC, NUMERIC)? Why not absoluting?
Tests: you can make LCM fail on much smaller values for int2/4/8, you do
not need to start around max_int.
--
Fabien.