New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
graphs: fickle equality testing #730
Comments
comment:2
This patch fixes the problem noted above by redefining vertices() to return just a list of vertices and then patching various places to explicitly sort the output of vertices(). An option to vertices, boundary_first=True, outputs the boundary vertices first (but sorts the boundary vertices, so it still is deterministic). The patch takes this approach so that vertices() can be more efficient (it doesn't have to loop through and separate out the boundary vertices any time someone wants a list of vertices). However, this does break backward compatibility (previous versions returned the boundary first by default).
|
comment:3
The above patch breaks a doctest. A determinant has the opposite sign, which would happen if two rows of the adjacency matrix were reversed because boundary vertices aren't returned first anymore. It would be good to check if the failed doctest can be changed or if there is a problem in the patch. |
Because the order returned by iterkeys is not guaranteed, enum, and therefore,
__cmp__
do not seem to behave well. This could possibly be fixed by sorting the boundary vertices in the vertices() function.It seems that since the graphs are the same, with the same labels and everything, the equality test should return True. However, the boundary vertices are not sorted, so g.vertices() and h.vertices() return in a non-specified order.
Why do we return the boundary vertices first anyway?
Component: combinatorics
Issue created by migration from https://trac.sagemath.org/ticket/730
The text was updated successfully, but these errors were encountered: