sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.47k stars 488 forks source link

__invert__ for Laurent polynomial is wrong #20963

Open videlec opened 8 years ago

videlec commented 8 years ago

The parent of the inverse of a Laurent polynomial can be three different things

sage: R.<x> = LaurentPolynomialRing(ZZ)
sage: parent(~x)
Univariate Laurent Polynomial Ring in x over Integer Ring
sage: parent(~(2*x))
Univariate Laurent Polynomial Ring in x over Rational Field
sage: parent(~(x+1))
Fraction Field of Univariate Polynomial Ring in x over Integer Ring

This is against the principle: "the result of an arithmetic operation should only depend on the parent".

At the same time we provide a (partial) conversion from the fraction field back to the original ring.

CC: @miguelmarco

Component: algebra

Issue created by migration from https://trac.sagemath.org/ticket/20963

miguelmarco commented 8 years ago
comment:1

So you suggest to return always a fraction? In that case we would need a good conversion from such fractions back to Laurent polynomials (for the ones that actually can be converted).

videlec commented 8 years ago

Description changed:

--- 
+++ 
@@ -11,3 +11,5 @@

This is against the principle: "the result of an arithmetic operation should only depend on the parent". + +At the same time we provide a (partial) conversion from the fraction field back to the original ring.

videlec commented 8 years ago
comment:2

Yes! We could also implement a specific function to inverse units as

sage: (-1).inverse_of_unit()
-1
sage: m._invert_unit()
[ 1 -1]
[-1  2]

Though, we would have to chose the name (see https://groups.google.com/forum/#!topic/sage-devel/SLfWHJp4Apk).

tscrim commented 8 years ago
comment:3

It is really annoying to not be able to do 1 / x and stay within Laurent polynomials as there is a lot more functionality available than in the fraction field. So -1 on always returning an element in the fraction field (in this case).

videlec commented 8 years ago
comment:4

Replying to @tscrim:

It is really annoying to not be able to do 1 / x and stay within Laurent polynomials as there is a lot more functionality available than in the fraction field. So -1 on always returning an element in the fraction field (in this case).

Modifying the coercion model is out of the scope of this ticket ;-) What about 1 / 1? The result should stay in whatever ring 1 belongs to? The advantage of the coercion model approach is that there is no ambiguity.

I agree that we should be able to invert x inside the Laurent polynomials (hence my post on sage-devel mentioned in comment:2). But I don't agree that the syntax should be 1 / x.

tscrim commented 8 years ago
comment:5

Replying to @videlec:

Replying to @tscrim:

It is really annoying to not be able to do 1 / x and stay within Laurent polynomials as there is a lot more functionality available than in the fraction field. So -1 on always returning an element in the fraction field (in this case).

Modifying the coercion model is out of the scope of this ticket ;-) What about 1 / 1? The result should stay in whatever ring 1 belongs to? The advantage of the coercion model approach is that there is no ambiguity.

The reason why I am okay with 1/1 in QQ is because rationals behave the same as integers for nearly all purposes. However, for fraction fields of (Laurent polynomial) rings, they behave very differently than the Laruent polynomial rings.

I agree that we should be able to invert x inside the Laurent polynomials (hence my post on sage-devel mentioned in comment:2). But I don't agree that the syntax should be 1 / x.

However, this makes perfect sense mathematically and is the only real notation that we have for it other than x^-1. However, this would confuse so many people (and has) if x^-1 is different than 1 / x. Moreover this is such a common operation that forcing people to do inverse_of_unit (or anything like that), in addition to it being different than the print output, would lead to anger.

I also think this abuse is okay from the POV of the code as the coercion framework allows you to not care when doing generic arithmetic operations. Besides, sometimes it is better to break principles/rules. ;)