Dima, Thank you for taking the time to answer the question posted by my student Samuel.
Let me just clarify the main point of his question just in case we can still obtain a helpful answer. Essentially the question is: Why is Sage calling "antisymmetric" to a property that is not the standard antisymmetric property? We would appreciate if anybody has an insight on why is this choice of name since we are writing a user friendly guide to Sage for undergraduate students trying to use Sage in Discrete Math. So far, the paragraph in our book reads as: "We just learned the antisymmetric property for relations, now ask Sage if the following relation satisfies antisymmetric property. Be aware that Sage is not checking for the absence of cycles of length 2 as we just learned, but for the absence of cycles of any length. This is because..." we would like to finish this phrase with a meaningful reason - if we found out why. The fact that this other property is "more mathematically interesting" does not seem to justify a change of name. In my field, to check for homotopically equivalent graphs is more interesting than checking for isomorphism. Yet, I don't expect Sage to check if my graphs are homotopically equivalent when I use the *is_isomorphic* function. My student Sam did read carefully the documentation that is why he discovered that Sage is using *path* instead of *edge*, as in the standard definition of antisymmetric relation in the paragraph quoted: A graph represents an antisymmetric relation if the existence of a *path* from a vertex x to a vertex y implies that there is not a *path* from y to x unless x=y. We would like to know why, so it can be incorporated in our book and enlighten next generations of undergraduate students trying to make sense of this documentation. On Monday, March 11, 2024 at 5:20:05 PM UTC-5 Dima Pasechnik wrote: > On Mon, Mar 11, 2024 at 9:24 PM Samuel Lubliner <samlu...@gmail.com> > wrote: > >> I've been exploring the concept of antisymmetry in DiGraphs within >> SageMath and noticed a discrepancy between the standard mathematical >> definition of an antisymmetric relation and SageMath's implementation for >> DiGraphs. I'm looking for some clarification or insight into this >> observation. >> >> The standard definition of antisymmetry in a relation R states: >> if aRb and bRa, then a=b. >> >> In contrast, Sage seems to interpret antisymmetry for DiGraphs in a way >> that emphasizes the absence of reciprocal paths, which is more restrictive. >> >> To illustrate, I ran a few tests within a SageCell to understand how >> antisymmetric() behaves with different graph configurations: >> >> A graph with a loop and no reciprocal edges, which should be >> antisymmetric: >> ``` >> DiGraph([(1, 2), (3, 1), (1, 1)], loops=True).antisymmetric() # Expected >> True, Returns True >> ``` >> >> >> A graph with a direct reciprocal relationship (1,2) and (2,1), clearly >> violating antisymmetry: >> ``` >> DiGraph([(1, 2), (2, 1), (3, 1), (1, 1)], loops=True).antisymmetric() # >> Expected False, Returns False >> ``` >> >> This third example is interesting because, under the standard >> mathematical definition, antisymmetry focuses on direct reciprocal >> relations between pairs of elements, not the existence of a path between >> vertices. Therefore, a cycle does not inherently violate antisymmetry >> unless there are direct reciprocal edges between any two vertices in the >> graph. >> ``` >> DiGraph([(1, 2), (2, 3), (3, 4), (4, 1)]).antisymmetric() # Expected >> True, Returns False >> ``` >> >> > you can check the docs, and see that Sage, essentially, calls directed > acyclic graphs antisymmetric. > I.e. if there is a path from x to y then there is no path from y to x > (assuming x!=y) > > A graph represents an antisymmetric relation if the existence of a > path > from a vertex `x` to a vertex `y` implies that there is not a path > from > `y` to `x` unless `x = y`. > > that's a more interesting, mathematically, definition, than mere absense > of loops of length 2. > > > > >> Is SageMath's antisymmetric() method intentionally designed to consider >> the broader structure of the graph by evaluating paths rather than just >> direct edges to determine antisymmetry? It would be great to get some >> clarification on this and understand the rationale behind SageMath's >> implementation choice. >> >> -- >> 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...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sage-support/88c4e8f1-f04d-4010-91b4-39fdd8a403f8n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/sage-support/88c4e8f1-f04d-4010-91b4-39fdd8a403f8n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/f412346e-a5a3-4d06-b495-cbb62626a0a8n%40googlegroups.com.
