Opened 10 years ago
Closed 10 years ago
#3793 closed defect (fixed)
[with patch, with positive review] Some elliptic curve doctests fail when the optional database is installed
Reported by: | cremona | Owned by: | was |
---|---|---|---|
Priority: | minor | Milestone: | sage-3.1 |
Component: | algebraic geometry | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | Work issues: | ||
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
A few of the doctests in ell_rational_field.py
fail when the optional package database_cremona_ellcurve-20071019 is installed, mainly because for curves in the database the gens() as supplied by the database may differ from those computed on the fly. (In almost all cases the generators are not uniquely determined, being the generators of a finitely-generated abelian group. We have put some thought into how to make the generators canonical but have not yet succeeded.)
Attachments (1)
Change History (7)
Changed 10 years ago by
comment:1 Changed 10 years ago by
- Summary changed from Some elliptic curve doctests fail when the optional database is installed to [with patch, needs review] Some elliptic curve doctests fail when the optional database is installed
comment:2 Changed 10 years ago by
- Milestone set to sage-3.1
comment:3 Changed 10 years ago by
- Summary changed from [with patch, needs review] Some elliptic curve doctests fail when the optional database is installed to [with patch, with positive review] Some elliptic curve doctests fail when the optional database is installed
I ran the tests on 3.0.6 before and after installing the database, *without* applying the patch, and both tests passed everything. So... is this really necessary?
But I still think this looks good and should be applied, since it addresses some ambiguity that could be annoying.
comment:4 Changed 10 years ago by
The point is that there was randomness in the old doctests: whenever they use E.gens() where E is an elliptic curve we cannot guarantee that the same gens are computed (on different systems, etc). As a special case of this ambiguity, the gens obtained from the database (which don't change! -- or at least ont very rarely, e.g. if they are found to be wrong) may not agree with computed gens.
I dealt with this by either inserting "# random", or by using explicit points instead of gens().
I hope that with this explanation you can give this (admittedly rather trivial) patch a positive review.
comment:5 Changed 10 years ago by
ok, so it already has a positive review! Thanks!
comment:6 Changed 10 years ago by
- Resolution set to fixed
- Status changed from new to closed
Merged in Sage 3.1.alpha1
To test this you should really test the doctests in ell_rational_field.py both before and after installing the database.