Identify abelian number fields in the jump box without polredabs (LMFDB#5471)#42
Open
roed-math wants to merge 1 commit into
Open
Identify abelian number fields in the jump box without polredabs (LMFDB#5471)#42roed-math wants to merge 1 commit into
roed-math wants to merge 1 commit into
Conversation
…LMFDB#5471) Add a fast path to WebNumberField.from_polynomial implementing jwj61's abelian identification: after polredbest, certify the field abelian with galoisinit over an order maximal at the small primes of the discriminant (never factoring the discriminant), compute the field discriminant from that order, query nf_fields by degree/signature/discriminant, and confirm candidates by exhibiting a verified root of their defining polynomial, so any label returned is provably correct; all failures fall back to the unchanged polredabs path. Inputs whose degree exceeds every field in nf_fields now return "not in database" immediately instead of running polredabs (a degree 94 kernel polynomial went from >300s to 0.15s; the issue's degree 47 field is identified from a non-reduced polynomial in ~2s). Verified: all 36 number_fields tests pass (3 new: identified jumps for the issue's degree 47 field and Q(zeta_32) from non-reduced polynomials, abelian_nf_label unit checks, fast large-degree jump); pyflakes clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Looking up a number field by polynomial always ran polredbest+polredabs, which can hang — e.g. kernel polynomials of Dirichlet characters of large degree run for many minutes without producing an answer. This implements the abelian-case identification proposed by @jwj61: after polredbest, certify the field abelian with galoisinit on an order maximal at the small primes of the discriminant (the discriminant is never factored), read off the field discriminant from that order, query nf_fields by degree/signature/discriminant, and confirm candidates by exhibiting a root of their defining polynomial in the input field, so any label returned is provably correct; on any failure we fall back to the unchanged polredabs path. In addition, polynomials whose degree exceeds every field in nf_fields now return "not in the database" immediately: a degree-94 kernel polynomial of conductor 283 that previously ran polredabs for >300s now answers in 0.15s, and the degree-47 example from the issue is identified from a non-reduced defining polynomial in ~2s with a certificate. Tested on abelian fields of degree 8, 16 and 47 entered via deliberately non-reduced polynomials, plus non-Galois/non-abelian negatives; all 36 number_fields tests pass. Addresses LMFDB#5471.
🤖 Generated with Claude Code