Skip to content

Conversation

5iri
Copy link

@5iri 5iri commented Aug 9, 2025

Description
This pull request resolves a bug in the Cayley computation logic. The issue caused incorrect results when handling certain edge cases in the Cayley transform. The fix updates the relevant function to correctly handle these cases, ensuring accurate mathematical results.

Addresses the root cause of the Cayley bug.
Adds tests to cover the previously failing scenarios.
Updates documentation to reflect the corrected behavior.
Fixes #40549.

@5iri
Copy link
Author

5iri commented Aug 9, 2025

please check and let me know if there are any issues <3

@cxzhong
Copy link
Contributor

cxzhong commented Aug 10, 2025

you may just use git add ., then git push, we just need the changes of finitely_presented.py

@5iri
Copy link
Author

5iri commented Aug 10, 2025

@cxzhong can you check it now?

@cxzhong
Copy link
Contributor

cxzhong commented Aug 11, 2025

Can you test whether the bug has been fixed and add a new test in doctest

@user202729
Copy link
Contributor

In which situation may the exception be raised?

Prefer to use proper capitalization and Markdown formatting.

Prefer to use imperative mood for commit messages and pull request titles.

@5iri
Copy link
Author

5iri commented Aug 12, 2025

I have added a doctest, and here's the same code working as expected, you can see that it shows 52 instead of 109

Screenshot 2025-08-12 at 12 25 28 PM

@cxzhong
Copy link
Contributor

cxzhong commented Aug 12, 2025

I have added a doctest, and here's the same code working as expected, you can see that it shows 52 instead of 109

Screenshot 2025-08-12 at 12 25 28 PM

Yes, I confirm this. @orlitzky Can you help me check it?

sage: hash(id1) == hash(id2)
True

TESTS::
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only one colon here. Make sure the docstring is valid RST.

@orlitzky
Copy link
Contributor

What was the cause of the original bug, two equal elements with different hashes?

If the _hash_ method was previously inherited from FreeGroupElement, does the problem exist there as well?

@5iri
Copy link
Author

5iri commented Aug 15, 2025

What was the cause of the original bug, two equal elements with different hashes?

If the _hash_ method was previously inherited from FreeGroupElement, does the problem exist there as well?

You are right! I completely forgot about where the hash element was inherited from.

I was debugging it in finitely_presented.py to check whether the hash was the actual issue.

I just checked that FreeGroupElement has the same issue.

The issue was, in a free group, elements are only equal if their words are identical, so the hash contract is naturally satisfied. But in a quotient (finitely presented) group, different words can represent the same element due to relations, so the inherited hash method is not sufficient.

I'll remove the extra unecessary __hash__ method from finitely_presented.py and edit free_group.py to use the canonical form first and else move to Tietze representation.

@cxzhong
Copy link
Contributor

cxzhong commented Aug 16, 2025

Can you check this? I test the bug is solved. @orlitzky

self.parent()._confluent_rewriting_system = rs
canonical_form = self.parent()._confluent_rewriting_system.reduce(self)
return hash(str(canonical_form))
except Exception:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What sort of exception are you expecting here? (Can you be more specific than Exception)? You probably don't want to ignore it if, say, the user presses Ctrl-C in the middle of the computation.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh I should be specifying expected exceptions

got it!

ill add them now

@cxzhong
Copy link
Contributor

cxzhong commented Aug 18, 2025

can you explain that why there are four error types?

@5iri
Copy link
Author

5iri commented Aug 19, 2025

can you explain that why there are four error types?

In __hash__, I’m specifically catching AttributeError, ValueError, RuntimeError, and NotImplementedError. These cover cases where the rewriting system is missing, fails to reduce, or isn’t implemented for the group. I’m not catching all exceptions, so things like KeyboardInterrupt (Ctrl-C) or SystemExit will still propagate, which is important for user control and debugging. Let me know if you think we should handle other error types!

@user202729
Copy link
Contributor

do add a doctest to demonstrate each type of exception being thrown.

Also, the current implementation, if the computation takes e.g. a second and then throw, trying to hash other elements will again try to recompute that. Not a good idea.

the surrounding context is questionable also (specifically, currently FinitelyPresentedGroupElement inherit from FreeGroupElement, presumably just to reuse code, but a FinitelyPresentedGroupElement is not always a FreeGroupElement, so documentation-wise it's incorrect—it's preferable to either invert the inheritance, or make a common AbstractGroupElementLibGAP parent class), but that's out of scope here.

I recommend moving the logic to FinitelyPresentedGroupElement it fixes the problem.

@5iri
Copy link
Author

5iri commented Aug 24, 2025

should I directly work on the AbstractGroupElementLibGAP as a feature instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cayley graphs of free groups have wrong number of vertices.
4 participants