This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gladman
Recipients akira,, gladman, mark.dickinson, mrabarnett, scoder, steven.daprano, terry.reedy, vstinner, wolma
Date 2014-09-25.16:52:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 25/09/2014 17:02, Matthew Barnett wrote:
> Matthew Barnett added the comment:
> As it appears that there isn't general agreement on how to calculate the GCD when negative numbers are involved, I needed to look for another way of thinking about it.
> Splitting off the sign as another factor was what I came up with.
> Pragmatism beats purity, and all that! :-)

I understand :-)

But I think we now know that we are not going to get agreement here on
grounds of principles for what the gcd should return for negative

First, in order to preserve my sanity, I am going to concede Mark's
point that returning a negative value from GCD is not wrong :-)

For negative integers we have now amassed quite a few alternatives:

1) return the GCD that is non-negative (my preference)

2) return the GCD that is negative (your suggestion)

3) return the GCD that has the same sign as its first input

4) return the GCD that has the same sign as its second input (as now)

and, I suspect, a few more I haven't thought of.

I may be wrong here, but I suspect that if we were starting from scratch
the first of these would quickly be adopted for several reasons:

1) it yields the least surprising results and the one that most users
probably both want and expect.

2) For me, Wolfgang Maier's point about the commutative properties of
the gcd is rather important since finding that gcd(a, b) != gcd(b, a) is
a real loss, not just an inconvenience.

3) Its supports a common idiom for checking for co-prime numbers by
testing if the gcd is equal to 1.

But we are not starting from scratch and it is hard to see that it makes
much sense to change the GCD in fractions given the backwards
compatibilty issues that this might create.

So, it would seem that we should eiher do nothing or we should introduce
a gcd in, say math, that adopts approach (1) above and document its
difference when compared with that in fractions, allowing both to

We can, hopefully speed it up (see the related threads) and it might
over time come to be the gcd that people come to use as the norm (also
nothing would stop its internal use in fractions).

We might also allow one or more inputs.

Last but not least I hope I have not done anyone a disservice in this
Date User Action Args
2014-09-25 16:52:57gladmansetrecipients: + gladman, terry.reedy, mark.dickinson, scoder, vstinner, mrabarnett, steven.daprano, akira, wolma,
2014-09-25 16:52:57gladmanlinkissue22477 messages
2014-09-25 16:52:57gladmancreate