#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 novoselt):

 Replying to [comment:35 nthiery]:
 > 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?

 When a fan computes its cone lattice, it constructs all of the required
 cones (which are bound to the correct fan) and then converts them into a
 poset. All further methods work with this poset. Since now posets are
 unique and involve "==" checks for fans and cones, the poset of the second
 fan is treated as the same one as the first one, so the second fan gets a
 poset of cones bound to the first fan. The precise method of fans is
 `_compute_cone_lattice`.

 Now, I have actually realized, that it will have the same issue for cones,
 it just does not break the existent doctests yet:
 {{{
 sage: C1 = Cone([(0,1)])
 sage: C2 = Cone([(0,1)])
 sage: C1 == C2
 True
 sage: C1 is C2
 False
 sage: C1.facets()[0]
 0-d face of 1-d cone in 2-d lattice N
 sage: C1.facets()[0].ambient() is C1
 True
 sage: C2.facets()[0].ambient() is C1
 True
 sage: C2.facets()[0].ambient() is C2
 False
 }}}
 The code for cones is in `face_lattice` method. Again, I don't want to get
 the same posets even for cones that have the same order of rays, and there
 are arguments that "==" should treat rays as sets. So it would be nice to
 force different posets for "==" objects.

 Why exactly are posets unique? Isn't it expensive to check that two posets
 are equivalent? I am interested in dealing with face lattices of about
 10^5^ elements, how long would it take to check their equality? Maybe
 elements of posets should be unique, but not posets themselves?

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10998#comment:36>
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.

Reply via email to