Skip to content

Conversation

@Hapsa21
Copy link
Contributor

@Hapsa21 Hapsa21 commented Dec 11, 2025

📝 Description

This PR implements the __floordiv__ method for IntegerFactorization objects, enabling the use of the floor division operator (//).

Previously, using // on IntegerFactorization objects (e.g., factor(100) // factor(2)) raised a TypeError. This implementation:

  1. Extracts the integer values from the factorization objects.
  2. Performs standard integer floor division.
  3. Returns the factorization of the result (e.g., factor(50)).

It correctly handles mixed types (e.g., factor(100) // 3) and lets Python raise ZeroDivisionError naturally when dividing by zero.

Fixes #40812.

📝 Checklist

  • The title is concise and informative.
  • 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 and checked the documentation preview.

⌛ Dependencies

None

@github-actions
Copy link

github-actions bot commented Dec 11, 2025

Documentation preview for this PR (built with commit 32637c3; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

@Hapsa21
Copy link
Contributor Author

Hapsa21 commented Dec 12, 2025

@cxzhong Is this fix ok ?

@yyyyx4
Copy link
Member

yyyyx4 commented Dec 12, 2025

What is the motivation for this? I don't think I know any algorithms that would require this kind of thing, and in any case, blindly re-factoring the result of the division essentially defeats the purpose of the Factorization object...

@Hapsa21
Copy link
Contributor Author

Hapsa21 commented Dec 12, 2025

What is the motivation for this? I don't think I know any algorithms that would require this kind of thing, and in any case, blindly re-factoring the result of the division essentially defeats the purpose of the Factorization object...

The motivation is to ensure consistency with standard Python operators and improve interactive convenience, as requested in Issue #40812.

Blindly re-factoring is inefficient. I can update the implementation to check for divisibility first and subtract exponents directly where possible, only falling back to full re-factorization when necessary. Would that be fine?

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.

Implement // (floordiv) for IntegerFactorization objects

3 participants