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

PARI's qfbclassno() may give incorrect results #34801

Open
yyyyx4 opened this issue Nov 28, 2022 · 2 comments
Open

PARI's qfbclassno() may give incorrect results #34801

yyyyx4 opened this issue Nov 28, 2022 · 2 comments

Comments

@yyyyx4
Copy link
Member

yyyyx4 commented Nov 28, 2022

Since #23986, Sage calls PARI's qfbclassno() to compute the class number of a quadratic order. However, the documentation for that PARI function says:

[...] this function only implements part of Shanks's method (which allows to speed it up considerably). It gives unconditionnally correct results for |D| < 2.10¹⁰, but may give incorrect results for larger values if the class group has many cyclic factors. We thus recommend to double-check results using the function quadclassunit [...]

Thus, Sage should probably default to quadclassunit() and only use qfbclassno() if proof=False is set.

CC: @tscholl2 @roed314

Component: number fields

Issue created by migration from https://trac.sagemath.org/ticket/34801

@yyyyx4 yyyyx4 added this to the sage-9.8 milestone Nov 28, 2022
@mkoeppe mkoeppe removed this from the sage-9.8 milestone Jan 29, 2023
@b1acktothefuture
Copy link

b1acktothefuture commented Sep 21, 2024

Is this already taken care of here: #36184? @yyyyx4

@yyyyx4
Copy link
Member Author

yyyyx4 commented Sep 27, 2024

No: The check there follows the recommendation in the PARI documentation for when to use quadclassunit() instead of qfbclassno(), but for the latter there still is a warning that the results could be incorrect even in a nonempty part of the range where the documentation recommends it should be used. In contrast, for quadclassunit() the PARI documentation promises that the results are correct assuming GRH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants