Opened 4 years ago

Last modified 4 years ago

#19269 needs_info enhancement

add category Posets to ZZ and QQ

Reported by: dkrenn Owned by:
Priority: major Milestone: sage-6.9
Component: categories Keywords:
Cc: ncohen, behackl Merged in:
Authors: Daniel Krenn Reviewers:
Report Upstream: N/A Work issues:
Branch: u/dkrenn/cat/ZZ-poset (Commits) Commit: c1d0720cc0b80041c8fdda8c85ec89bc031749ae
Dependencies: Stopgaps:

Description (last modified by dkrenn)

ZZ and QQ should have the category Posets as well.

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

Change History (14)

comment:1 Changed 4 years ago by dkrenn

  • Description modified (diff)

comment:2 Changed 4 years ago by ncohen

  • Cc ncohen added

comment:3 Changed 4 years ago by dkrenn

  • Branch set to u/dkrenn/cat/ZZ-poset

comment:4 Changed 4 years ago by dkrenn

  • Authors set to Daniel Krenn
  • Commit set to a3f031d08ce245e6969fcfd5b703839fb676e4b2
  • Status changed from new to needs_review

New commits:

cc9141fadd category Posets to QQ
da31be1implement le for QQ
af612adadd category Posets to ZZ
231494eimplement le for ZZ
a3f031dfix doctests

comment:5 Changed 4 years ago by dkrenn

  • Status changed from needs_review to needs_work

comment:6 follow-up: Changed 4 years ago by vdelecroix

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

comment:7 follow-up: Changed 4 years ago by vdelecroix

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

comment:8 Changed 4 years ago by git

  • Commit changed from a3f031d08ce245e6969fcfd5b703839fb676e4b2 to c1d0720cc0b80041c8fdda8c85ec89bc031749ae

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

cd8a627Merge tag '6.9.beta7' into t/19269/cat/ZZ-poset
c1d0720fix doctest

comment:9 in reply to: ↑ 7 Changed 4 years ago by dkrenn

Replying to vdelecroix:

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

Done.

comment:10 Changed 4 years ago by dkrenn

  • Cc behackl added

comment:11 Changed 4 years ago by dkrenn

  • Status changed from needs_work to needs_info

comment:12 in reply to: ↑ 6 ; follow-up: Changed 4 years ago by dkrenn

Replying to vdelecroix:

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?

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

Replying to dkrenn:

Replying to vdelecroix:

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

comment:14 in reply to: ↑ 13 Changed 4 years ago by dkrenn

Replying to vdelecroix:

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

Note: See TracTickets for help on using tickets.