CC @griesemer

Note, you can avoid allocation by using:

new(big.Int).GCD(nil, nil, a.Abs(a), b.Abs(b))

Which switches the sign without allocation.

What would be the proposed convention for the signs of the Bezout coefficients?

z = a*x + b*y
or
z = |a|*x + |b|*y

I don't think there is an established convention here.

For zero values, I presume you would set x=0 if a=0 and y=0 if b=0

What is the use case for GCD of negative numbers?

That would mutate the arguments, however. I don't think it is desirable to change a or b when asking for new(big.Int).

If it worked as GCD(|a|, |b|) then I think the latter would make more sense. And as you say for the case of zeros.

Normalizing fractions, computing content of polynomials, simplify integer matrices, all these work beyond natural numbers.

Yes, it's not ideal that you would have to track the signs of a and b and restore them after calculating the GCD, I was just noting that you could currently calculate the GCD without allocating by doing some additional bookkeeping.

For reference, GMP uses the first convention for the Bezout coefficients z = a*x + b*y
https://gmplib.org/manual/Number-Theoretic-Functions.html

This as well but also accessing a or b from other threads would be unsafe.

Disclaimer: No, don't do this ;)

func evilAbs(x *big.Int) *big.Int {
	y := *x
	y.Abs(&y)
	return &y
}

Change https://golang.org/cl/164972 mentions this issue: math/big: allow all values for GCD

The documentation for (*big.Int).GCD currently says:

If either a or b is <= 0, GCD sets z = x = y = 0.

That's unfortunate: it gives well-defined non-error behavior for an input that arguably should have been defined to be a user error. It also makes any change to GCD for zero or negative inputs violate Go 1 compatibility, and per #28221, we want to avoid such redefinitions.

That seems to suggest that the extended GCD function must have a new name.

That is unfortunate. I don't think there should be a different GCD function that accepts zero or negative inputs. So that probably makes this a Go 2 proposal then.

Even a Go 2 proposal will generally need to follow the guidelines from #28221 in order to be accepted.
I don't think there is a viable alternative to putting the behavior in a separate method.

Doesn't math/big fall under standard-library-changes and not changes to the core language.

One of the benefits of a Go 2 transition is the chance to release some of the standard library packages from the Go 1 compatibility guarantee.

In particular, it would appear to be part of the penumbra-standard-library

The penumbra standard library consists of those packages that are included with a release but are maintained independently. This will be most of the current standard library. These packages will follow the same discipline as today, with the option to move to a v2 where appropriate.

Which seems to indicate this change would be possible in a future release.

Given semantic import versioning, adding a v2 of an entire package is strictly more duplication than adding a method to an existing type. An entire v2 package would be a very large hammer for a problem that could be addressed by adding a somewhat-redundant method with a somewhat-suboptimal name.

IMHO, I don't think this warrants a new method. GCD(x, 0) = |x| (or at least x), everything else is wrong result. If there was a bug in stdlib and users started to rely on, would Go prefer to fix it or keep the broken behaviour? The only situation where this would break current code is when the user relied on inexact result. Go 1.12 introduced more precise Sin, Cos, ... which produce non-identical results from earlier releases. If I relied on the old transcendental function, this would break my code. As a side note, Python is in similar situation now. They have both fractions.gcd and math.gcd, and marked the former as deprecated.

@TuomLarsen A bug is, generally speaking, a deviation of the behavior of a program from its intention. The fact that this behavior is explicitly documented, though, shows that this behavior is the intention - someone made the deliberate decision that the function should behave that way. As such, if you rely on it, you're also not relying on "inexact results" - it is clearly specified how the function behaves in this case and you're relying on that specification.

In any case, this is actually documented (even though we're talking stdlib and not language, the same principles apply). This would at best fall under "specification error" and be incompatible. And the compatibility guarantee clearly states that they only happen for security issues. Bugs, to answer your question, can be fixed, even if it breaks code that relies on it. And as to Sin, Cos, those changes would fall under "unspecified behavior" (it was never guaranteed that the results would stay bitwise identical). Grain of salt though, that again this is stdlib and not language :)

@bcmills AIUI the intention was to keep this around as a "if we ever release math.Big/v2 for whatever reason, we could add this change to the bunch", not to release a new version specifically to address this. AIUI the opinion is that this is not important enough to warrant the cost of a new function - but if we ever have to pay the transition cost of a major version anyway, we might as well throw this in for basically free.

(I have no opinion on my own whether this should have a new function. I think doing what's suggested would be the correct way for GCD to behave, but it is inconsequential to me if and how that would be achieved :) )

Per the discussion above, I have to agree that the new definition would indeed be problematic in the light of backward-compatibility. I am also not convinced that we should add a new function (GCD2) at this point. At any rate, it is easy for a client needing the extra functionality to just write that code.

Leaving this on hold for now.

It is true that the docs for GCD say:

If either a or b is <= 0, GCD sets z = x = y = 0.

but even before that, they say:

a and b, which both must be > 0

Kind of self-contradictory, but we currently forbid < 0 args, even if we also specify a behavior for them.

Fair point; I did miss that.

@bcmills Do you still have strong objections in light of this? Personally, I'd go forward with it.

I still think it's a breaking change, but if you want to call it a specification error instead I'm ok with trying it out and seeing what breaks.
(The “specification error” in this case would be the fact that we documented the behavior for prohibited inputs.)

@griesemer @bcmills Is there a final decision on this? As far as any practical effects, I don't foresee that any code was calling GCD with negative arguments and doing something specific with an all zero result. Likely, any code calling GCD with negative arguments would have been checking the sign of arguments before the call since the all zero result would not be what they wanted.

Let's try this (and consider the current documentation at "specification error"). For Go 1.14.

Thank you!

Change https://golang.org/cl/217104 mentions this issue: math/big: update comment on Int.GCD