add category Posets to ZZ and QQ

[dkrenn]

ZZ and QQ should have the category Posets as well.

See also https://groups.google.com/d/msg/sage-devel/DhRfKlCcmL4/IO1ikjxSDQAJ

CC: @nathanncohen @behackl @tscrim @nthiery

Component: categories

Author: Daniel Krenn

Branch/Commit: u/dkrenn/cat/ZZ-poset @ c1d0720

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

[dkrenn]

Branch: u/dkrenn/cat/ZZ-poset

[dkrenn]

Author: Daniel Krenn

[dkrenn]

Commit: a3f031d

[dkrenn]

New commits:

cc9141f	add category Posets to QQ
da31be1	implement le for QQ
af612ad	add category Posets to ZZ
231494e	implement le for ZZ
a3f031d	fix doctests

[videlec]

comment:6

Hola,

We should try to make the cartesian products of copies of ZZ compatible with the current behavior of ZZ^n (actually, I would feel more confortable if cartesian_product([ZZ,ZZ]) would return ZZ^2). But vectors are compared with respect to the lexicographic ordering

sage: V = ZZ^2
sage: my_list = [V((i,j)) for i in range(3) for j in range(3)]
[(0, 0), (0, 1), (0, 2), (1, 0), (1, 1), (1, 2), (2, 0), (2, 1), (2, 2)]

So it is not (strictly speaking) a cartesian product of posets. Several solutions:

• change the behavior of comparisons for vectors
  • modify richcmp to be the product order and keep cmp to be the lexicographic ordering in order to keep the sort feature... we will have some Python3 troubles later on
  • break the sort operation
• find a compromise with respect to the order of the product (how?)

Having so many category for ZZ might also be a problem when it comes to morphisms. What should be

sage: Hom(ZZ,ZZ)
sage: Hom(ZZ^2, ZZ^2)

In the category of Euclidean domains + Posets there are few elements! And most of the time, when people think about ZZ^2 they do not care about the poset structure. Something likethe following should work out of the box

sage: Hom(ZZ^2, ZZ^2, Posets())
sage: Hom(ZZ^2, ZZ^2, Modules(ZZ))

My question is about the default behavior of Hom with this multiple categories.

Vincent

[videlec]

comment:7

Could you base the branch on the latest beta? Trac is not able to automatically merge.

[sagetrac-git]

Changed commit from a3f031d to c1d0720

[sagetrac-git]

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

cd8a627	Merge tag '6.9.beta7' into t/19269/cat/ZZ-poset
c1d0720	fix doctest

[dkrenn]

comment:9

Replying to @videlec:

Could you base the branch on the latest beta? Trac is not able to automatically merge.

Done.

[dkrenn]

comment:12

Replying to @videlec:

Having so many category for ZZ might also be a problem when it comes to morphisms. What should be

sage: Hom(ZZ,ZZ)
sage: Hom(ZZ^2, ZZ^2)

In the category of Euclidean domains + Posets there are few elements! And most of the time, when people think about ZZ^2 they do not care about the poset structure. Something likethe following should work out of the box

sage: Hom(ZZ^2, ZZ^2, Posets())
sage: Hom(ZZ^2, ZZ^2, Modules(ZZ))

My question is about the default behavior of Hom with this multiple categories.

What would be a solution to this or what are possible scenarios? What can we do to get this ticket (make ZZ and QQ posets) towards a positive review?

[videlec]

comment:13

Replying to @dkrenn:

Replying to @videlec:

Having so many category for ZZ might also be a problem when it comes to morphisms. What should be

sage: Hom(ZZ,ZZ)
sage: Hom(ZZ^2, ZZ^2)

In the category of Euclidean domains + Posets there are few elements! And most of the time, when people think about ZZ^2 they do not care about the poset structure. Something likethe following should work out of the box

sage: Hom(ZZ^2, ZZ^2, Posets())
sage: Hom(ZZ^2, ZZ^2, Modules(ZZ))

My question is about the default behavior of Hom with this multiple categories.

What would be a solution to this or what are possible scenarios? What can we do to get this ticket (make ZZ and QQ posets) towards a positive review?

Indeed, it was a question... One possibility: make some priorities for the Hom functor in sage.categories.homset.

Currently, to deduce the category of Hom(X,Y) the functor does X.category()._meet_(Y.category()) which is documented as being "the largest common subcategory of self and other". Instead of _meet_ one could try to implement a more dedicated method that forget some of the categories (such as the Poset one if there is some algebraic structure).

Vincent

[dkrenn]

comment:14

Replying to @videlec:

Indeed, it was a question... One possibility: make some priorities for the Hom functor in sage.categories.homset.

Currently, to deduce the category of Hom(X,Y) the functor does X.category()._meet_(Y.category()) which is documented as being "the largest common subcategory of self and other". Instead of _meet_ one could try to implement a more dedicated method that forget some of the categories (such as the Poset one if there is some algebraic structure).

This could be something like an negated version of extra_super_categories, which kicks the specified (forbidden) categories out...

[mkoeppe]

comment:17

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[mkoeppe]

comment:18

Setting a new milestone for this ticket based on a cursory review.

[mkoeppe]

comment:19

Stalled in needs_review or needs_info; likely won't make it into Sage 9.5.