> Do you want DiGraph to have methods like rank or is_chain? Of course not. The idea was to have Poset carry a DiGraph _hasse_diagram instead of a HasseDiagram object, and to [move/merge] the methods from HasseDiagram with their Poset counterparts.
> 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. It is the same right now: you mut translate the elements in the Poset function which calls the HasseDiagram function. Except when the function does not care, like 'rank'. > 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. I do not see how: this would happen as often, but it would happen in the same location. Right now we write Poset functions whose only purpose is to relabel elements before calling HasseDiagram methods. This could be done at the same place. > 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). Why do you say that it is how the *should* be? Nathann -- 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.
