Let the `TestSuite` test that the construction of a parent returns the parent

[simon-king-jena]

Andrey told me about the following problem. When he implemented toric lattices, he inherited a .construction() method from general lattices. Consequence: If he tried to add elements of two different toric lattices, then Sage applied a pushout construction and added the two elements after pushing them to ZZ^2, which was not what he wanted.

His solution was, I think, the correct one: He overloaded the .construction() method, so that it now returns None.

Update: A similar problem also showed up in #30360.

Suggestion: Introduce a test of the TestSuite of a parent P, that will complain if P.construction() returns a pair F, O such that F(O)!=P.

I think this test should be put into sage.structure.parent.Parent (Update 9.2: sage.categories.sets_cat), because this is where .construction() is defined in the first place.

CC: @novoselt @nthiery @sagetrac-sage-combinat @tscrim @fchapoton @mwageringel @kwankyu @dkrenn

Component: coercion

Keywords: construction functor, test suite, sd53

Author: Simon King, Matthias Koeppe, Marc Mezzarobba, Travis Scrimshaw

Branch: 29e2ce0

Reviewer: Travis Scrimshaw, Matthias Koeppe

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

[simon-king-jena]

comment:1

I did not run the full test suite yet, but I already detected several bugs in .construction(). So, introducing this test really is a good idea.

Until now, I found:

1. Boolean polynomial rings:

   sage: P.<x0, x1, x2, x3> = BooleanPolynomialRing(4,order='degrevlex(2),degrevlex(2)')
   sage: P.construction()
   (MPoly[x0,x1,x2,x3], Finite Field of size 2)
   sage: F, O = P.construction()
   sage: F(O)
   Multivariate Polynomial Ring in x0, x1, x2, x3 over Finite Field of size 2
   sage: P
   Boolean PolynomialRing in x0, x1, x2, x3
   

   Suggested solution: A boolean polynomial ring is, after all, a quotient of a polynomial ring. So, it should be constructed as such, but the QuotientFunctor should be provided with an additional attribute making it notice that a boolean polynomial ring shall be returned.

2. Integer mod rings that are initialised in a non-default category:

   sage: P = IntegerModRing(19, category = Fields())
   sage: F,O = P.construction()
   sage: F(O)
   Ring of integers modulo 19
   sage: P
   Ring of integers modulo 19
   sage: F(O) == P
   False
   

   Why is this? Well, providing a different category changes the class of P (this is how the category framework works), and the __cmp__ method of integer mod rings checks for the class. And the construction functor F is not aware of the category of P.

   Suggested solutions: Change __cmp__ such that F(O) evaluates equal to P, even though F(O) is not in the category of fields, or alternatively make the construction functor aware of the category, so that F(O) actually is in the category of fields.

[simon-king-jena]

comment:2

And I am to blame for a third problem, that is actually fairly similar to the second problem mentioned above. It is in my thematic tutorial on categories and coercion.

• I create a parent class inheriting from UniqueRepresentation.
• The parent class has a construction functor that keeps track of the "important" arguments needed to reconstruct the parent.
• I create one instance P of the parent class using an additional "unimportant" argument, namely a category.

Consequence: When trying to reconstruct P using the construction functor, the "unimportant" argument is missing, and hence UniqueRepresentation believes that a new instance needs to be created. After all, for UniqueRepresentation, all arguments are important parts of the cache key.

I have to think how to solve this.

[simon-king-jena]

Branch: u/SimonKing/ticket/15223

[simon-king-jena]

comment:4

Is it really needed that BooleanPolynomialRing has a .construction()? Granted, one could describe it as the quotient of a polynomial ring over GF(2). However, you could actually not take an arbitrary ring R and create a boolean polynomial ring over R---the base ring will always be GF(2).

Anyway, using the construction functor for multivariate polynomial rings is plain wrong. We have two options:

1. Let the construction be None
2. Create a new construction functor for boolean polynomial rings, either similar to the multivariate polynomial ring functor, or similar to the quotient functor.

If we go for None, then we would have problems to do fancy constructions starting with a boolean polynomial ring: There would be no pushout constructions. I wonder if we need pushout constructions.

If we go for a new construction functor, I'd suggest to modify quotient functors. After all, it is a quotient in a particular implementation.

And looking at the second problem, it seems to be a general problem with quotient functors: Sometimes we want to add more information on a quotient, such as "the quotient shall belong to the category of fields" or, "the quotient shall be implemented as a boolean polynomial ring". So, we should invent a general scheme to load the quotient functor with this additional information.

[simon-king-jena]

comment:5

By the way, the branch that I uploaded fixes all doctests, except for the three issues described in the previous posts (boolean polynomial rings, quotients that are pushed into a sub-category of the default, and the stuff that I wrote in the thematic tutorial).

[simon-king-jena]

comment:6

The quotient functors (sage.categories.pushout.QuotientFunctor) eventually call the .quo() method when they are called. They actually do make a special case for fields that are constructed as a quotient.

I think it would be possible to store further arguments in an attribute, say, _further_arguments, which should be a dictionary, and then do

   Q = R.quo(I, names=self.names, **self._further_arguments)

Then, one should also make the .quo() method accept these additional arguments.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

[changeset:a81fcc1]

Make _test_construction pass in the thematic tutorial

[sagetrac-git]

Commit: a81fcc1

[simon-king-jena]

comment:8

In the current commit, I fix the example in the thematic tutorial by making the construction functor aware of the additional arguments that were originally used to construct the parent.

It works, and I think a similar idea would work for quotient functors.

[simon-king-jena]

comment:10

I just added Nicolas to this ticket, since it relates not only with coercion (this is the component of this ticket) but also with categories.

In a nutshell: If P is a parent, then P.construction() should return None, or a pair F,O, where F is a construction functor and O is some object.

The contract is that F(O)==P. But nobody has checked this contract so far. The original aim of this ticket is to introduce a test.

While we are at it, I thought one could improve QuotientFunctor. First of all, it must allow to pass additional arguments to the quotient being constructed. For example, the construction functor for IntegerModRing(19, category=Fields()) must know that the category is specialised. Similarly, the construction functor for BooleanPolynomialRing(...) must know that the result is not just a quotient of a polynomial ring, but has a special implementation.

And something else that I want to improve with the QuotientFunctor: Currently, it is a functor from Rings() to Rings(). But why?? Perhaps, at some point, we want to apply the QuotientFunctor in the context of groups!

Hence, I think it would make sense to be more precise when choosing the domain and codomain of the functor.

Today, I experimented with this idea: If Q is a quotient, and F,O=Q.construction(), then the quotient functor F should go from O.category() to Q.category().

But when running the tests, it turns out that this is too narrow: Sometimes, we want to apply the quotient functor F to a ring over a different base ring.

This makes me think of the following: Would it make sense to introduce a method of categories C.without_parameters(), returning the join of all super-categories of C that are not instances of CategoryWithParameters?

For example, for C = Category.join([EnumeratedSets(),Algebras(QQ)]), C.without_parameters() would return Join of Category of rings and Category of enumerated sets.

Nicolas, do you think it would hurt to introduce such method here?

[nbruin]

comment:11

Replying to @simon-king-jena:

While we are at it, I thought one could improve QuotientFunctor. First of all, it must allow to pass additional arguments to the quotient being constructed. For example, the construction functor for IntegerModRing(19, category=Fields()) must know that the category is specialised.

Isn't that going to be a problem?

sage: A=IntegerModRing(19, category=Fields())
sage: B=IntegerModRing(19)
sage: B in Fields()
True

After this isn't the category of B refined to fields? And doesn't that then mean that A and B are the same, and hence should be identical? But if UniqueRepresentation takes the category argument into account, they won't be identical.