Nils, Yes, that terminology is not perfectly aligned between different areas in mathematics is a good takeaway we will definitely mention in the book. Thank you!
In this case I understand that we are checking antisymmetric in a graph, but the most confusing part is that the documentation is explicitly stating: "A graph represents an *antisymmetric relation* if ... " It is not saying a graph is antisymmetric, but is introducing a new definition of antisymmetric relation. I don't think that the issue is about *relation* or *graph* (both definitions are for graphs), so I like your suggested names "edge_antisymmetric" and "path_antisymmetric" momentarily because they emphasize the actual distinction, so I would suggest the following change in Dima's course of action: 1) copy antisymmetric() to antisymmetric_relation(); deprecate antisymmetric(); introduce antisymmetric_graph(), to mean the standard definition as Hellen points at. "path_antisymmetric()" instead of "antisymmetric_relation()" "edge_antisymmetric()" instead of "antisymmetric_graph()" 2) after the deprecation period, make antisymmetric() a copy of antisymmetric_graph(), and deprecate the latter 3) after the (2nd) deprecation period, remove antisymmetric_graph() So in the end, in about 2 years, there will be antisymmetric() - conforming to the standard - and antisymmetric_relation() - the original code for old antisymmetric() In the end there will be path_antisymmetric() and just antisymmetric(), both for graphs, where the latter corresponds to graphs representing antisymmetric relations. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-support/7ad86cea-5c6c-4685-a77f-040691b15ea1n%40googlegroups.com.