GCD in Fractions

[Ian Kelly]

On Tue, Sep 23, 2014 at 11:26 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Wolfgang Maier schrieb am 23.09.2014 um 18:38:
>> While at first I thought this to be a rather irrelevant debate over module
>> private vs public naming conventions, I now think the OP is probably right
>> and renaming fractions.gcd to fractions._gcd may be a good idea.
>
> Making a public API private is rarely a good idea. It should be enough in
> this case to document the behaviour.
>
> And, believe it or not, it actually is documented:
>
> https://docs.python.org/3.5/library/fractions.html#fractions.gcd

I don't think documentation is sufficient in this case. This is the
kind of thing though that is easy to forget about if you haven't read
the documentation recently. And with a function like gcd, one
generally wouldn't expect to *need* to read the documentation.

>> Googling for recipes to calculate the gcd using python brings up
>> fractions.gcd as a general answer (like at stackoverflow:
>> http://stackoverflow.com/questions/11175131/code-for-greatest-common-divisor-in-python)
>> and it is not obvious for non-mathematicians to realize that it is NOT a
>> generally acceptable solution.
>
> It is. Certainly for positive numbers, which clearly present the majority
> of use cases. It's definitely the "normal" use case, wouldn't you say?
>
> For negative numbers, the "expected" behaviour seems to be unclear, so the
> current behaviour is just as good as any, so backwards compatibility
> concerns clearly win this fight.

I'm not convinced it's all that clear. In addition to Mathworld and
Wikipedia that were already cited, ProofWiki provides an actual proof
that gcd(a, b) = gcd(|a|, |b|), by way of noting that a and |a| have
the same factors.