Opened 12 years ago
Closed 10 years ago
#10172 closed defect (fixed)
Rational Point algorithm bug
Reported by: | nkaplan | Owned by: | AlexGhitza |
---|---|---|---|
Priority: | major | Milestone: | sage-4.8 |
Component: | algebraic geometry | Keywords: | |
Cc: | minz | Merged in: | sage-4.8.alpha5 |
Authors: | Moritz Minzlaff | Reviewers: | John Cremona |
Report Upstream: | None of the above - read trac for reasoning. | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
When you have a curve defined over a projective space over a finite field, it looks like sometimes the rational point list coming from the Brill-Noether package in Singular is not the full list of rational points.
sage: S.<x,y,z> = GF(5)[] sage: g = x*z+z^2 sage: G = Curve(g) sage: G.rational_points('enum') [(0 : 1 : 0), (1 : 0 : 0), (1 : 1 : 0), (2 : 1 : 0), (3 : 1 : 0), (4 : 0 : 1), (4 : 1 : 0), (4 : 1 : 1), (4 : 2 : 1), (4 : 3 : 1), (4 : 4 : 1)] sage: G.rational_points('bn') [(0 : 1 : 0), (4 : 0 : 1), (4 : 1 : 1), (4 : 2 : 1), (4 : 3 : 1), (4 : 4 : 1)]
The problem was how Sage calls Singular's functions.
Attachments (1)
Change History (6)
comment:1 Changed 11 years ago by
- Cc minz added
comment:2 Changed 11 years ago by
- Status changed from new to needs_work
comment:3 Changed 11 years ago by
- Description modified (diff)
- Status changed from needs_work to needs_review
We were missing so far that and how Singular dehomogenizes the defining polynomial of the curve: Always with respect to the last variable. If the corresponding line is a component of the curve, the output was missing those points.
comment:4 Changed 10 years ago by
- Reviewers set to John Cremona
- Status changed from needs_review to positive_review
The patch looks good to me and applies cleanly to 4.8.alpha4. All long tests in sage/scheme pass. I am happy with this.
comment:5 Changed 10 years ago by
- Merged in set to sage-4.8.alpha5
- Resolution set to fixed
- Status changed from positive_review to closed
Part of the problem was the same as in the computation of Riemann-Roch spaces #8997.
There still remains a problem: The above example works fine now if we replace z by y (which shouldn't make a difference in terms of correctness of the algorithms involved). Maybe the current singular interface makes certain assumptions about the variable names and their ordering that we still need to pay attention to here?