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

trying to get rid of coerce_c_impl #39419

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

fchapoton
Copy link
Contributor

not seriously tested so far

📝 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.

Copy link

github-actions bot commented Jan 31, 2025

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

@user202729
Copy link
Contributor

user202729 commented Feb 1, 2025

Sounds like a good idea (I keep wondering how does the coercion work for that parent, and why changing __call__ to _element_constructor_ breaks everything)

Looks like all tests pass anyway.

@fchapoton
Copy link
Contributor Author

fchapoton commented Feb 3, 2025

Ok, so tests pass. I have some concerns about possible speed regression.

Note that this is a little step in the removal of the "auld coercion system" that was mostly but not completely replaced by a better one using categories a long time ago.

- polynomial rings in a subset of the variables over any base ring that
canonically coerces to the base ring of this ring
- any ring that canonically coerces to the base ring of this polynomial
ring.

TESTS:

This fairly complicated code (from Michel Vandenbergh) ends up
implicitly calling ``_coerce_c_impl``::
Fairly complicated code (from Michel Vandenbergh)::
Copy link
Contributor

Choose a reason for hiding this comment

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

Now that this is a cpdef method we can probably test it directly?

Copy link
Contributor

Choose a reason for hiding this comment

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

I felt it's intended to be more of a "try to keep the test" than actually testing the method. But yes, R.coerce_map_from(S) should delegate to this function anyway.

return True
n = other.ngens()
check = (self.ngens() >= n and
self.variable_names()[:n] == other.variable_names())
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this assuming that the subset will be the first n?

Copy link
Contributor

Choose a reason for hiding this comment

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

Previously the coercion system wasn't entirely self-consistent either. #39126

We can probably fix this first (keep the old non-self-consistent behavior unchanged) then change it later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have kept the hypothesis that the subset of variables are the initial ones, and changed the documentation accordingly. This is a progress on what was there before (only exactly the same variables) and still a reasonable assumption to make, with no possible round trips.

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.

3 participants