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

Implemented an Explicit Dimension Formula for the Newspace with character #38385

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

Conversation

eross156
Copy link

@eross156 eross156 commented Jul 17, 2024

This PR implements a recently computed explicit dimension formula for newspaces of modular forms with character.
This completes Issue #38384
The tests verify this formula against the current dimension computation in Sage.

I added some additional documentation underneath dimension_new_cusp_forms() for this change. But I can't view the documentation preview, because for some reason, I can't get the docs to build on my machine.

📝 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

Copy link
Collaborator

@tscrim tscrim 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. @JohnCremona, perhaps you might have some thoughts on this PR?

For me, I would prefer not to have all of those internal functions as they make the code harder to follow (i..e, take a more iterative style approach instead of functional) as most of those are called in exactly one place. You are also going to get a lot of Python ints being mixed in instead of Sage Integers too.

src/sage/modular/arithgroup/congroup_gamma1.py Outdated Show resolved Hide resolved
src/sage/modular/arithgroup/congroup_gamma1.py Outdated Show resolved Hide resolved
src/sage/modular/arithgroup/tests.py Outdated Show resolved Hide resolved
src/sage/modular/arithgroup/tests.py Outdated Show resolved Hide resolved
src/sage/modular/arithgroup/tests.py Outdated Show resolved Hide resolved
src/sage/modular/arithgroup/tests.py Outdated Show resolved Hide resolved
src/sage/modular/arithgroup/congroup_gamma1.py Outdated Show resolved Hide resolved
@JohnCremona
Copy link
Member

I will take a look -- saw the preprint but have not yet read it as I'm at ANTS this week and then on holdiday for a few days.

@eross156
Copy link
Author

eross156 commented Jul 18, 2024

@tscrim Thank you for all your feedback and updates. Especially thank you for all the style updates to match this repo; I'm still trying to figure out all the code standards here.

@eross156
Copy link
Author

eross156 commented Jul 18, 2024

For me, I would prefer not to have all of those internal functions.

We could potentially combine all the func's with the func_local's. (The original thought was to use func_local's, so that I could use early return and cut out some if / else blocks. But this turned out to not be a big deal either way.) Additionally c3, c4, c0 could be converted to just inline expressions. This would cut out about about half of the internal functions. But if you mean cutting out all of the internal functions, I guess I respectfully disagree. I don't know how I would be able to keep everything straight otherwise, comparing with the published formula. But I'm happy to conform to whatever the standards are here. Compare this with the current dimension formula for trivial character in Sage (which the character formula is a generalization of).

You are also going to get a lot of Python ints being mixed in instead of Sage Integers too.

I agree this is weird. Is it considered better practice to change every int literal in the code to e.g. ZZ(999)? Also compare this with the current dimension formula for trivial character in Sage

eross156 and others added 7 commits July 19, 2024 07:31
Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com>
Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com>
Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com>
Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com>
Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com>
Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com>
@tscrim
Copy link
Collaborator

tscrim commented Jul 29, 2024

Sorry for the delay in responding (traveling).

Yes, usually you use ZZ(123), which can run into problems if you end up dividing two ints.

I don't think it is so bad to get rid of all internal functions, but I can see some benefits to keeping some of them. However, the more trivial ones would be better to absorb as inline: psi_local, psi, beta_psi_f, beta_sigma_f, rho, beta_rho_f, rhopm, beta_rhopm_f, c3, c4, c0, omega. Many of these can be written as a prod and you could avoid refactoring chi.conductor() in a few places. (Also, it is better to use x -= y instead of x = -1 * y as a micro-optimization.) You should also always return a Sage Integer (in particular, line 896 to return ZZ.zero()).

@eross156
Copy link
Author

eross156 commented Aug 2, 2024

Ok, thanks for the feedback. I will plan to add in these changes on Monday or Tuesday (I'm currently travelling as well).

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.

4 participants