categories: ZZ not in Posets() ?

[Daniel Krenn]

Is there a reason why

sage: ZZ in Posets()
False
sage: QQ in Posets()
False

?

Best

Daniel

[Nathann Cohen]

is there a reason why

sage: ZZ in Posets()
False
sage: QQ in Posets()
False

There are two:

- I don't think that we have any code to handle infinite posets

- You can define a thousand different posets on ZZ or QQ

Nathann 

[Vincent Delecroix]

Tough, you would expect the "natural" one to be the one induced by the
order on the real numbers.

[Nathann Cohen]

Tough, you would expect the "natural" one to be the one induced by the
order on the real numbers.

At first I thought only of the divisibility relation for ZZ, but of course the most natural is the one that is already available through the <= and < functions defined on the elements.

Then I guess it may not be a lot of work to turn them into real poset objects, even though... Well, even though it may not mean having much more than exactly those methods, at least for a start.

Plus if somebody wants to mess with the poset class, perhaps that will also give some room to rewrite the backends at the same time.

Nathann 

[Daniel Krenn]

To clearify (just in case): I don't want to make it an object inherting
from a poset class; I just think here about the category poset; the
class (ZZ, QQ) then only has to provide a method le(self, x, y) using
the existing <= and the catogory Posets() has to be assigned.

Best

Daniel

[Nathann Cohen]

> To clearify (just in case): I don't want to make it an object inherting from
> a poset class; I just think here about the category poset; the class (ZZ,
> QQ) then only has to provide a method le(self, x, y) using the existing <=
> and the catogory Posets() has to be assigned.

That's what I understood. I do not know whether we have a way to say
that "the class has to provide a method" nor to check it, but perhaps
what you want to do can be achieved by a one-liner which would declare
Posets as a supercategory of ZZ,QQ ?

Nathann

[Daniel Krenn]

From the catogory side it is easy:

sage: ZZ.category()
Join of Category of euclidean domains and Category of infinite
enumerated sets
sage: ZZ._refine_category_(Posets())
sage: ZZ.category()
Join of Category of euclidean domains and Category of posets and
Category of infinite enumerated sets

To use a property of this new category, it is assumed that we have an le
method. IMHO there is no check; but when calling something an error, of
course.

Best

Daniel

[Nathann Cohen]

> To use a property of this new category, it is assumed that we have an le
> method. IMHO there is no check; but when calling something an error, of
> course.

Okay, then it seems that there is no reason to not have the behaviour
that you request. You but have to write this one-line patch, and I am
sure that it will not take long to review.

Nathann

[Jori Mäntysalo]

On Sat, 22 Aug 2015, Nathann Cohen wrote:

> - I don't think that we have any code to handle infinite posets

Well, we kind of have...

from sage.categories.examples.posets import PositiveIntegersOrderedByDivisibilityFacade
P = PositiveIntegersOrderedByDivisibilityFacade()
P.le(4,5)

returns False. But for example P.lower_covers(10) says NotImplementedType,
not [2,5].

We have category for posets and category for finite posets --- no category
for locally finite posets.

It is not hard to implement, say, mobius function for
PositiveIntegersOrderedByDivisibilityFacade. And it is possible to make a
class of cartesian product of posets and have a le() method there. But is
there anything interesting in those?

--
Jori Mäntysalo