|
This section contains a sketch of how databases of examples
can be built. This is an aside from the rest of the chapter,
and is only of interest if one either wants to understand the
construction of the K3 database for its own sake, or wishes
to create other similar lists that take too long to be
regenerated on demand.
Note, however, that the database facility described here is
not suitable for very large databases: roughly speaking,
it is intended for those containing a few tens of thousands
of elements, not millions, and certainly not in the
Kreuzer--Skarke [KS00] range.
This section describes briefly the method of construction used for
the K3 database. The K3 database is fully installed in
Magma---see Section The K3 Database for instructions---and there is
no need to use the functions described here to rebuild it unless
you intend to modify the code to incorporate new information in
the database.
The construction is in two steps. First we create all the
K3 surfaces we require and write them as abbreviated records
to a series of files. Then we load these files one at a time,
writing their contents in further abbreviated form to a binary
data file, K3S.dat. The writing functions keep track of
key indexing information and write this to an index file,
K3S.ind. Functions to read from these files are already
installed, so the process is completed by copying these two
files to the standard data directory in the Magma libraries.
We now go through the process in detail.
CreateK3Data(g,r) : RngIntElt,RngIntElt -> SeqEnum
CreateK3Data(g,B) : RngIntElt,SeqEnum -> SeqEnum
Create a sequence containing all K3 surfaces of genus g≥ - 1;
restrict to those with singular rank at most r, if given as an
argument, or having baskets in the sequence B of baskets, if given
as an argument.
The return sequence is ordered according to the natural
numerical order on the coefficients of Hilbert series.
Analysis of projections of Types I and II is made to
modify weights of K3 surfaces, and any inconsistencies between
different predictions of weights coming from different projections
are reported.
A record in K3 record format that contains a subset of the data
associated to the K3 surface X from which all attributes of X
can be computed.
The K3 surface with the same data as that of the record x
in K3 record format.
Write the K3 surfaces in the sequence Q to the file with name
given by the string F. The resulting file F is a text file
containing Magma code which, when loaded into a Magma session,
generates a sequence called data of records in K3 record
format that corresponds to Q.
With the data for the K3 database saved as a series of files
"k3data-1", "k3data0" and so on, the command
load "writek3db.m"; (or load "PATH/writek3db.m";)
loads them in turn, writes the two binary files and then deletes
the data from the Magma session. Magma must be running in
the directory containing all the data files "k3data ... ".
In normal Magma use, even though the data in the K3 database
is in coded form (as a tuple, in fact), when returned to the user
it is expressed as a K3 surface. Of course, this final translation
step takes a little time, insignificant in most use, but very
significant when searching through the whole database.
So there are functions to access the raw data, and then to
translate it into a K3 surface. The search intrinsics installed
in the Magma packages use these functions, as should any new
searches that need only modest increase in speed.
K3SurfaceRaw(D,Q,i) : DB,SeqEnum,RngIntElt -> Tup
The i-th element of the K3 database D expressed as a tuple
of data (or the i-th element whose Hilbert series has
coefficients of ti given by the integers in the sequence Q,
which may have length at most 5).
The K3 surface with the same data as that of the tuple x
that is in the raw K3 database format.
Here we explain in general terms how to write new databases
of polarised varieties. We give complete instructions for writing
the data and index files, but are more sketchy on the other
steps: you will have to assemble the data, write translation
functions and write any cosmetic wrapping functions for yourself.
Step 1: Prepare the directory.
Make a new directory, `NewDB' say, and copy the files
data_spec.m, write.m, init_info.m, write_tools.m,
write_func.m, create_ind_func.m into NewDB from
the Magma package directories.
Of these files, the first two will have to be edited to conform
to the required database, while the remaining four are common
to all databases.
Step 2: Decide record format.
Edit the file data_spec.m.
This determines which data is stored, and places unbreakable
restrictions on that data.
In particular, the choice of up to 5 indexing parameters is
made here.
Write intrinsics that translate between the data in its
original representation and in its record representation.
Step 3: Update the writing functions.
Edit the file write.m.
Step 4: Collect the data.
Write all required data as records in one or more files.
It is essential that the data is written to these files
so that it can be read into a single Magma session in
increasing order (with respect to the chosen indexes).
Step 5: Build the binary data and index files.
Step 6: Move the binaries to the data libraries.
Step 7: Final cosmetics.
Write as Magma package code any cosmetic wrappers or
search routines that are to be used with the new database.
Document these intrinsics.
[Next][Prev] [Right] [Left] [Up] [Index] [Root]
|