In the next major release of poly I intend to remove Data.Poly.gcdExt in favor of Data.Euclidean.gcdExt from semirings. The latter works uniformly for any euclidean ring and poly depends on semirings anyways, so it is redundant to have another implementation, specific to polynomials.
The caveat is that since Data.Euclidean.gcdExt is polymorphic over EuclideanRing, it knows nothing about units of the ring and cannot normalise its output. So the gcd of two coprime elements may appear to be not only 1, but also -1 or potentially any other unit. In constrast to this, Data.Poly.gcdExt was defined only for polynomials over fields and so was always able to normalise the leading coefficient to 1.
This commit migrates galois-field to use gcdExt from Data.Euclidean and amends source code to match previous behaviour. (I'm not sure whether such changes should be reflected in the changelog, so I left it unchanged for now)
sdiehl
commented
4 years ago
In the next major release of
polyI intend to removeData.Poly.gcdExtin favor ofData.Euclidean.gcdExtfromsemirings. The latter works uniformly for any euclidean ring andpolydepends onsemiringsanyways, so it is redundant to have another implementation, specific to polynomials.The caveat is that since
Data.Euclidean.gcdExtis polymorphic overEuclideanRing, it knows nothing about units of the ring and cannot normalise its output. So the gcd of two coprime elements may appear to be not only1, but also-1or potentially any other unit. In constrast to this,Data.Poly.gcdExtwas defined only for polynomials over fields and so was always able to normalise the leading coefficient to1.See also discussion at https://github.com/Bodigrim/poly/issues/38
This commit migrates
galois-fieldto usegcdExtfromData.Euclideanand amends source code to match previous behaviour. (I'm not sure whether such changes should be reflected in the changelog, so I left it unchanged for now)