#10998: Categories for posets
----------------------------------------------------------------------------------+
Reporter: nthiery
| Owner: sage-combinat
Type: enhancement
| Status: needs_work
Priority: major
| Milestone: sage-4.7.1
Component: combinatorics
| Keywords: days30, sd31
Work_issues:
| Upstream: N/A
Reviewer: Franco Saliola, Christian Stump, Nicolas M. Thiéry, Florent
Hivert | Author: Frédéric Chapoton, Christian Stump, Nicolas M. Thiéry
Merged:
| Dependencies: #11289, #10938, #9065
----------------------------------------------------------------------------------+
Comment(by nthiery):
Replying to [comment:34 novoselt]:
> Hi Nicolas!
>
> With the patch:
> {{{
> sage: F1 = FaceFan(lattice_polytope.octahedron(3))
> sage: F2 = FaceFan(lattice_polytope.octahedron(3))
> sage: F1 == F2
> True
> sage: F1 is F2
> False
> sage: F1(2)[0]
> 2-d cone of Rational polyhedral fan in 3-d lattice N
> sage: F1(2)[0].ambient() is F1
> True
> sage: F2(2)[0].ambient() is F2
> False
> }}}
>
> The last command is heavily assumed to return True in the toric-related
code. The problem is that when the cone lattice of `F2` is constructed, it
is considered as the same poset as the cone lattice of `F1` and so all
cones of `F2` become linked to `F1`. Possible solutions are:
> * Make cone lattices of fans which are "==" but not "is" distinct. This
should fix the issue without any complications as it will basically
restore the current state.
> * Make "==" and "is" comparisons the same for fans. I think that this
is undesirable as there are arguments for making "==" be the mathematical
equivalence, which is even weaker than the current behaviour.
> * Make fans unique based on the ordered list of rays and cone
generators. This should fix the issue but may have consequences. Also,
while in general unique fans may be good, it would be nice to still have a
possibility to make "==" the mathematical equivalence and IMHO it would be
absolutely terrible for performance and convenience of use if uniqueness
of fans was based on their mathematical equivalence.
>
> Note: I'd rather not make cones unique based on the ordered list of rays
as I want to have a possibility to create different cones with the same
order of rays but different order of facet normals. This is not currently
implemented but would be extremely convenient for handling all kinds of
dualities and correspondences.
>
> So, in short, I prefer to be able to create different posets of cones
for fans which are "==".
Thanks a lot! I'll look at this tonight.
I am still confused a bit: do you know where technically in the cone code
is there an ``==`` or ``is`` test done on some posets, which cause the
change of behaviour above?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10998#comment:35>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
