> > So, as Jori asked, what would be wrong in *not* having a HasseDiagram > class at all? A Poset object could carry a _hasse_diagram digraph, and > all methods would be poset methods. > > Right now, there are two classes where a Poset method can be > implemented: Poset, and HasseDiagram. And right now, what we often do > is implement two functions instead of one. > > Getting rid of HasseDiagram looks better unless you know how it is > actually useful? >
Do you want DiGraph to have methods like rank or is_chain? Also, by implementing them directly into the Poset's class, you must deal with the elements labels at each computation, not just when you're moving to/from the HasseDiagram backend. In particular, see interval(); this would require a lot more interaction converting between the two different representations. At least with the HasseDiagram, which is a DiGraph, it reduces the amount of overhead with this. Moreover, the methods in Poset should just be a wrapper around such functions in HasseDiagram (unless there is no apparent penalty for directly implementing them in Poset). It is often only 2-3 lines of code to write these wrappers (and copying some docstrings and changing the doctests). Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
