Hello, > Let's for sanity's sake suppose that == among all vertex labels of > FinitePosets is an equivalence relation. Let's moreover suppose that > hashing respects this equivalence relation.
Thanks, > Then the problem seems to be that in the unique representation > (an_integer_labelled_hasse_diagram, list_of_vertex_labels) > of FinitePoset the internal mapping from vertex labels to integers is > exposed. > > It seems to me that this can be fixed by > A) getting rid of the exposure of the internal mapping, > or > B) by making the internal mapping unique given the Hasse diagram > labelled using the actual vertex labels. > > Option A probably involves using a vertex label labelled Hasse diagram > in the unique representation. The issue then becomes implementing that. I will rewrite it by making Poset.__init__ only depend on a hasse diagram represented by a labelled digraph (which will then be translated internally into an integer-labelled HasseDiagram). This way the key is the labelled hasse diagram, which is the only thing that makes sense. Nicolas told me that this "_elements" thing was only used by Anne Schilling in her markov-related code. So I will create some AnneSchillingPoset class with list of elements, keys and everything she needs and get us a real Poset class. And I hope everything will hold together afterwards. Thank you for your message, though. Asking a design question only earned me answers about "what is equality", and "can you provide a bug report which is not the bug report you provided". Now, all I have to do is write somebody else's code. 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
