Author mark.dickinson
Recipients brg@gladman.plus.com, mark.dickinson, vstinner
Date 2014-09-24.07:58:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1411545492.67.0.747248935813.issue22477@psf.upfronthosting.co.za>
In-reply-to
Content
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.

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.)
History
Date User Action Args
2014-09-24 07:58:12mark.dickinsonsetrecipients: + mark.dickinson, vstinner, brg@gladman.plus.com
2014-09-24 07:58:12mark.dickinsonsetmessageid: <1411545492.67.0.747248935813.issue22477@psf.upfronthosting.co.za>
2014-09-24 07:58:12mark.dickinsonlinkissue22477 messages
2014-09-24 07:58:12mark.dickinsoncreate