#11587: update Cremona's tables for Sage
-----------------------------------------+----------------------------------
Reporter: was | Owner: cremona
Type: enhancement | Status: positive_review
Priority: major | Milestone: sage-4.7.2
Component: elliptic curves | Keywords: elliptic curves
ellcurve database
Work_issues: | Upstream: N/A
Reviewer: John Cremona, Tom Boothby | Author: R. Andrew Ohana
Merged: | Dependencies: #11642
-----------------------------------------+----------------------------------
Comment(by cremona):
Replying to [comment:15 rohana]:
> Replying to [comment:14 cremona]:
> > It would be good if it were very easy to extend further (say just by
having more data files in the right place on installation), since I have
not stopped and in fact am very close to adding the range 180k=190k.
Adding that data (and more) should now be just a matter of adding some
data files to the spkg, right?
>
> Currently the spkg includes basically a single file -- a prebuilt
database. This is primarily because it is much faster to have the package
copy the file, rather than build the database from scratch (I was going to
use time it takes to create it on sage.math as an example, but I got too
impatient to let it finish). The script to create this database is
`sage.databases.cremona.build`, this will build and install the database
from your tgz file.
>
> If we decide to, we can move the build script to be inside the spkg,
with the knowledge that we should not use it on slow filesystems. If we do
so, we should only include allcurves, allgens, allbsd, and degphi since
those are the only files sage currently uses.
>
> > Is the information such as the maximum conductor hard-wired into the
code or just read from the database after construction from raw data
files?
>
> There is still a bit of hard-wired code: a bit in the documentation, the
build script, and an error message. It is possible to remove all of these
references, the only reason I didn't when working on this patch was
because I wanted to get sage up to speed. It is a simple fix, although if
we decide remove the build scripts from the sage library to the spkg
instead, we might as well do this at the same time.
Thanks for the explanation. I agree that it is good to have the database
file itself in the package and not the raw data, as long as it (the spkg)
also has instructions on how to (re)create this from my raw data. And a
note of the precise things to be changed when the range is extended would
also be a good idea, even if that's only a couple of places. I'm thinking
that it may not be you doing this next time!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11587#comment:16>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
