Opened 5 years ago

Last modified 5 years ago

#20963 new defect

__invert__ for Laurent polynomial is wrong

Reported by: vdelecroix Owned by:
Priority: major Milestone: sage-7.3
Component: algebra Keywords:
Cc: mmarco Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by vdelecroix)

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.

Change History (5)

comment:1 Changed 5 years ago by mmarco

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).

comment:2 Changed 5 years ago by vdelecroix

  • Description modified (diff)

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).

comment:3 follow-up: Changed 5 years ago by 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).

comment:4 in reply to: ↑ 3 ; follow-up: Changed 5 years ago by vdelecroix

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.

comment:5 in reply to: ↑ 4 Changed 5 years ago by tscrim

Replying to vdelecroix:

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. ;)

Note: See TracTickets for help on using tickets.