-
-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement dynamic posets #10783
Comments
comment:1
By the way - I don't like how currently elements of the face lattice of cones are some poset-element-wrappers and one has to dig an actual cone from it. I'd like poset elements to be cones themselves. Perhaps that's already possible and I just didn't read the documentation enough, but if not - it would be nice to add such a feature. And if yes - it would be nice if it was a bit more visible in the documentation ;-) |
comment:2
Replying to @novoselt:
Agreed -- I'm having the same problem with posets whose elements are lists, ordered by reverse inclusion. I think this should be another ticket. |
Changed keywords from none to poset |
comment:3
I think that #17693 does this and suggest this ticket to be closed. Frédéric, please click to positive_review if you agree. |
The idea is to allow creation of a poset without specifying all of its elements but instead allow adding them later. Example: one creates a cone and this cone becomes the top element of its face lattice, but the whole lattice and its elements are not constructed until (and IF) it is necessary.
Ticket #10777 is relevant.
I am personally interested only in such lattices and cone lattice of (not necessarily complete) fans, in particular these posets are finite and they are atomistic lattices. But for the implementation, perhaps, the only convenient limitation is finiteness. Or maybe even this is not important: if we don't construct all element, who cares how many are there?
The constructor probably has to have only one mandatory parameter: some callable that can compare elements of this poset. Perhaps one can also specify a callable for checking cover relations.
For elements it would be nice to compute their neighbours up/above/next to, even if they are not constructed yet. If this it too difficult, there may be a flag in the poset
has_all_elements
or something like this so that functions that do require all elements can check if they are present or not.CC: @nilesjohnson @fchapoton
Component: combinatorics
Keywords: poset
Issue created by migration from https://trac.sagemath.org/ticket/10783
The text was updated successfully, but these errors were encountered: