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

Improve performance of __getitem__ of CFiniteSequence #36764

Merged
merged 4 commits into from
Dec 14, 2023

Conversation

ryuhei-mori
Copy link
Contributor

Efficiency of __getitem__ for CFiniteSequence is improved.

Fixes #36763

πŸ“ Checklist

  • The title is concise, informative, and self-explanatory.
  • The description explains in detail what this PR is about.
  • I have linked a relevant issue or discussion.
  • I have created tests covering the changes.
  • I have updated the documentation accordingly.

βŒ› Dependencies

Copy link
Member

@mezzarobba mezzarobba left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution! The code looks good to me. In addition to the two comments I already left, I would suggest that you add a reference to your paper with Alin in the docstring, and maybe an example that shows that the code can handle recurrences of higher order.

It could be nice to also improve the case where one wants a whole slice of the sequence, but maybe not in this PR.

V = Matrix(QQ, d, 1, self._a[:d][::-1])
(quo, num) = num.quo_rem(den)
P = self.parent().polynomial_ring()
x = self.parent().gen()
Copy link
Member

Choose a reason for hiding this comment

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

I find it suspect that CFiniteSequences(ZZ).gen() returns a polynomial rather than a C-finite sequence, so I would write x = P.gen() here to be safe.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you. I think both are equivalent in the current implementation as in the definition of gen() in this file. But, 'P.gen()' is slightly more efficient.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I agree they are equivalent, but I view the current definition of gen() as a bug.

return wp + list(M ** (key - off) * V)[d - 1][0]
wp = quo[n]
while n:
num = P((num * den(-x)).list()[n % 2::2])
Copy link
Member

Choose a reason for hiding this comment

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

den(-x) actually takes quite a bit of time to compute in practice with the current implementation, so you may want to do it only once.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you. I improved it. In my enviorment, the improvment was very small. I also tried

nden = P([v if i % 2 == 0 else -v for i, v in enumerate(den)])

But, it was slower.

@ryuhei-mori
Copy link
Contributor Author

ryuhei-mori commented Nov 28, 2023

Thank you! I found you teached this algorithm in your course :)
I will add the docstring. Yes, I plan to implement the algorithm for slices.

By the way, I hope CFiniteSequences can be defined for general commutative rings or fields.
I think only closed_form() requires that the ring is QQ (or QQbar essentially).
Probably, guess() requires that it is field since the Berlekamp--Massey is explained by the Euclidean algorithm.
Except for them, I guess that we can allow general commutative rings for CFiniteSequences.

@ryuhei-mori
Copy link
Contributor Author

I added a reference and examples at the docstring of __getitem__(). I also added the information of the paper in src/doc/en/reference/references/index.rst.

@mezzarobba
Copy link
Member

Except for them, I guess that we can allow general commutative rings for CFiniteSequences.

I haven't looked in detail at the rest of the code, but this seems likely, and yes, this would be nice to have.

Let's wait for someone with the right permissions to approve the test workflows. (@fchapoton maybe?)

@ryuhei-mori
Copy link
Contributor Author

Thank you! The implementation of Berlekamp--Massey in SageMath is available for integral domains because we can construct a fraction field from an integral domain.

By the way, I notice that we need the middle product for implementing our MSB-first algorithm, which is used for the computation of slices. In general, algorithms obtained by the transposition usually requires the middle product. So, I hope the middle product will be implemented as a primitive for polynomial rings, etc.

Of course, I can implement the algorithm for slices without the middle product although it includes the overhead of the constant factor.

Copy link

Documentation preview for this PR (built with commit 486c776; changes) is ready! πŸŽ‰

Copy link
Member

@mezzarobba mezzarobba left a comment

Choose a reason for hiding this comment

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

Thank you!

vbraun pushed a commit to vbraun/sage that referenced this pull request Dec 10, 2023
    
Efficiency of `__getitem__` for CFiniteSequence is improved.

Fixes sagemath#36763

<!-- ^^^^^
Please provide a concise, informative and self-explanatory title.
Don't put issue numbers in there, do this in the PR body below.
For example, instead of "Fixes sagemath#1234" use "Introduce new method to
calculate 1+1"
-->
<!-- Describe your changes here in detail -->

<!-- Why is this change required? What problem does it solve? -->
<!-- If this PR resolves an open issue, please link to it here. For
example "Fixes sagemath#12345". -->
<!-- If your change requires a documentation PR, please link it
appropriately. -->

### πŸ“ Checklist

<!-- Put an `x` in all the boxes that apply. -->
<!-- If your change requires a documentation PR, please link it
appropriately -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
<!-- Feel free to remove irrelevant items. -->

- [x] The title is concise, informative, and self-explanatory.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [ ] I have created tests covering the changes.
- [ ] I have updated the documentation accordingly.

### βŒ› Dependencies

<!-- List all open PRs that this PR logically depends on
- sagemath#12345: short description why this is a dependency
- sagemath#34567: ...
-->

<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
    
URL: sagemath#36764
Reported by: Ryuhei Mori
Reviewer(s): Marc Mezzarobba, Ryuhei Mori
@vbraun vbraun merged commit 2ab6da5 into sagemath:develop Dec 14, 2023
20 checks passed
@mkoeppe mkoeppe added this to the sage-10.3 milestone Dec 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Performance of __getitem__ of CFiniteSequence
4 participants