On 24/09/2014 08:58, Mark Dickinson wrote:
> 
> Mark Dickinson added the comment:
> 
> The current `gcd` definition is almost accidental, in that it just happens to be what's convenient for use in normalisation in the Fraction type.  If people are using it as a standalone implementation of gcd, independent of the fractions module, then defining the result to be always nonnegative is probably a little less surprising than the current behaviour.
> 
> BTW, I don't think there's a universally agreed definition for the extension of the gcd to negative numbers (and I certainly wouldn't take Rosen's book as authoritative: did you notice the bit where he talks about 35-bit machines being common?), so I don't regard the fraction module definition as wrong, per se.  But I do agree that the behaviour you propose would be less surprising.

I only quoted Rosen because I had it immediately to hand.  I will
willingly supply more references if you need them.  Sadly even some
maths books don't cover this at all but then go on to rely on the
co-prime test gcd(a, b) == 1 even when a and/or b can be negative.
So I would agree that it is easy to conclude that the gcd is not defined
for negative numbers.  But, of those maths texts that explicitly cover
the behaviour of the gcd for negative numbers, I do not know of any that
do not define gcd(a, b) to be gcd(|a|, |b|).

> One other thought: if we're really intending for gcd to be used independently of the fractions module, perhaps it should be exposed as math.gcd.  (That would also give the opportunity for an optimised C version.)

To me it makes more sense to put this in math as this is where I would
expect to find it.  But a comment on comp.lang.python was not in favour
of this.