#10998: Categories for posets
----------------------------------------------------------------------------------+
Reporter: nthiery
| Owner: sage-combinat
Type: enhancement
| Status: needs_review
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:38 novoselt]:
> As I understand the uniqueness framework, it is based on checking that
the input to the constructor is the same as was already used before. So if
posets are unique, the constructor input is somehow normalized (using
Hasse diagram, perhaps?) and then compared with those that were already
constructed.
Correct.
> However for implementation purposes there is a big difference between
treating two cones as cones of the same fan and as two arbitrary cones. In
the first case the intersection is internally computed as the intersection
of two ordered sets of integers. In the second one it involves
constructing a new polyhedral object and determining its minimal generator
set. With old PALP/cdd interfaces this takes forever (compared to
intersection two short lists of integers). With Volker's new PPL interface
it is much better, yet still it requires many more operations.
To me this sounds like two cones/fans shall be equal (as in A==B) only if
they really have the same ambient space / ... and otherwise be only
isomorphic (as in A.is_isomorphic(B)).
In general, equality is often used by Python at a very low level, e.g. for
hash table lookups. So it should be fast and simple.
Anyway, this does not need to be settled now, and we can discuss this more
efficiently face to face at the next occasion.
> I agree that we have here more structure than poset itself but it is
basically the question of "the same" and "isomorphic". We have a similar
issue with toric lattices: if M = ZZ^n^, then the dual space is also
ZZ^n^, yet they are isomorphic but not equal. It would be great actually
to have some standard way in Sage to tag objects. Maybe ZZ is unique as a
ring, but it is possible that one wants to consider several modules which
are isomorphic to ZZ and treat them as different ones.
We definitely have had such use cases as well. However we were lucky
enough that we usually wanted to add some more structure, or change a bit
the structure, and in those cases we would either derive a new class, or
use a facade parent together with Cat.IsomorphicObjects() to transfer the
part of the structure that was to be kept.
But we could think of generalizing the use of a key=`...` in
UniqueRepresentation as I used here for posets.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10998#comment:40>
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.
