Skip to content
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

fix: enforce simple form uniqueness in ContinuedFraction.extend op #127

Closed
sr-murthy opened this issue Oct 26, 2024 · 0 comments
Closed
Labels
code quality Code quality measures

Comments

@sr-murthy
Copy link
Owner

sr-murthy commented Oct 26, 2024

Enforce simple form uniqueness (of sequences of elements) in ContinuedFraction``extend operation - the current implementation allows the construction of instances with sequences of elements with the terminal element being 1, violating uniqueness. Not a bug as op constructs the correct fractions in extensions, but anomaly in the uniquness of sequence of elements needs fixing.

>>> cf = ContinuedFraction.from_elements(3, 4)
>>> cf
ContinuedFraction(13, 4)
>>> cf.extend(1)
>>> cf
ContinuedFraction(16, 5)
>>> cf.elements
(3, 4, 1)
>>> ContinuedFraction.from_elements(3, 5) == ContinuedFraction.from_elements(3, 4, 1)
True
>>> cf = ContinuedFraction.from_elements(13, 4)
>>> cf
ContinuedFraction(13, 4)
>>> cf.extend(2, 1)
>>> cf
ContinuedFraction(42, 13)
>>> cf.elements
(3, 4, 2, 1)
>>> ContinuedFraction.from_elements(3, 4, 3) == ContinuedFraction.from_elements(3, 4, 2, 1)
True

For the tail extension (3 4) ~> (3, 4, 1) the resulting instance ContinuedFraction(16, 5) is correct as a fraction but as a unique simple continued fraction should have the sequence of elements 3, 5 rather than the sequence 3, 4, 1, as [3; 5] = [3; 4 + 1] = [3; 4, 1]. Same for the tail extension (3, 4) ~> (3, 4, 2, 1): the resulting instance ContinuedFraction(42, 13) is correct as a fraction but as a unique simple continued fraction should have the sequence of elements 3, 4, 3 rather than the sequence 3, 4, 2, 1, as [3; 4, 3] = [3; 4, 2 + 1] = [3; 4, 2, 1].

@sr-murthy sr-murthy added the code quality Code quality measures label Oct 26, 2024
@sr-murthy sr-murthy linked a pull request Oct 26, 2024 that will close this issue
This was referenced Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code quality Code quality measures
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant