Up : Main
Prev : Rasmol
Next : Internal constants
CaGe V0.3
Codes
In this section the codes which are read and written by CaGe are
described. For a detailed description and an introduction to other codes
see the original manual of gconv.
writegraph2d:
This is a Combinatorica format. It is ASCII, so it can be read by loading
the related file into an editor.
The file begins with one of the following headers:
>>writegraph2d<<
>>writegraph2d planar<<
Then the graph information follows. For each graph the information
is given as follows: Vertices are numbered 1,...,n.
For each vertex x there is one line in the file. The first number in the
line is the vertex number x to which the following numbers are related,
then two float coordinates follow. They contain the
position of vertex x in the plane. After that,
the numbers of those vertices
which are adjacent to vertex x follow (the neighbours of x).
After the last vertex there is a line that contains only a zero. Then the
next graph follows. So more than one graph can be stored in one file.
If the order in which the vertex neighbours are listed indicates
a planar embedding, then the header contains the parameter planar
right after the code name. If the header does not contain the parameter
planar, this does not automatically mean that the codes are no planar
embeddings.
Here is an example file (containing the two fullerenes with 28 vertices):
>>writegraph2d planar<<
1 500 866.025 12 13 2
2 1000 0 1 3 23
3 500 -866.025 2 20 4
4 327.062 -561.364 3 5 24
5 18.681 -505.199 4 19 6
6 108.393 -344.286 5 7 25
7 -88.795 -157.214 6 17 8
8 5.716 2.986 7 9 26
9 -89.192 165.809 8 16 10
10 102.363 346.616 9 11 27
11 19.263 511.485 10 14 12
12 327.451 561.554 11 1 28
13 -500 866.025 1 14 21
14 -305.74 552.598 13 11 15
15 -447.152 241.398 14 16 22
16 -344.259 88.378 15 9 17
17 -342.855 -75.43 16 7 18
18 -443.29 -234.616 17 19 22
19 -308.899 -538.802 18 5 20
20 -500 -866.025 19 3 21
21 -1000 0 20 13 22
22 -644.641 5.733 21 15 18
23 634.271 -6.36 2 24 28
24 436.421 -267.701 23 4 25
25 255.983 -261.512 24 6 26
26 189.348 4.006 25 8 27
27 258.3 261.219 26 10 28
28 430.465 273.377 27 12 23
0
1 500 866.025 12 13 2
2 1000 0 1 3 21
3 500 -866.025 2 19 4
4 321.919 -581.442 3 5 22
5 3.725 -536.829 4 18 6
6 19.874 -385.553 5 7 23
7 -260.627 -228.273 6 17 8
8 -141.191 41.533 7 9 25
9 -285.077 262.325 8 15 10
10 -42.105 428.45 9 11 26
11 -29.18 564.25 10 14 12
12 271.706 615.179 11 1 27
13 -500 866.025 1 14 20
14 -334.507 573.974 13 11 15
15 -447.472 277.783 14 9 16
16 -636.953 0.808 15 17 20
17 -432.968 -266.301 16 7 18
18 -314.325 -567.202 17 5 19
19 -500 -866.025 18 3 20
20 -1000 0 19 13 16
21 662.252 -73.473 2 22 28
22 458.915 -309.832 21 4 23
23 315.913 -254.598 22 6 24
24 355.774 24.301 23 25 28
25 122.788 118.125 24 8 26
26 197.526 323.948 25 10 27
27 336.98 354.08 26 12 28
28 467.657 117.43 27 21 24
0
If a graph is not embedded before storing it, then all coordinates are zero.
writegraph3d: See writegraph2d,
but with three coordinates for each vertex and with the appropriate code
name inside the header (writegraph3d).
planar_code:
This code is binary and so it cannot be read on a screen. It does not
provide coordinates, so the adjacency information of graphs is all what
can be stored using this code.
The file begins with a header which is one of the following:
>>planar_code<<
>>planar_code le<<
>>planar_code be<<
Here "le/be" stands for "little endian"/"big endian" (this will not be
discussed here). After the header, for each graph the following information
is given: First the number
of vertices of the graph appears. Vertices are numbered 1,...,n. Let's
assume that we have already embedded the graph into the plane. First
the neighbours of vertex 1 are listed in clockwise direction, followed by a
zero. Then the same continues with vertex 2,3,...,n. After the last zero,
the next graph follows.
The above example file would look like this
(where the numbers are binary, not readable, and the commas are
meta symbols which are not contained in the file):
>>planar_code<< 28, 12 13 2 0,
1 3 23 0,
2 20 4 0,
3 5 24 0,
4 19 6 0,
5 7 25 0,
6 17 8 0,
7 9 26 0,
8 16 10 0,
9 11 27 0,
10 14 12 0,
11 1 28 0,
1 14 21 0,
13 11 15 0,
14 16 22 0,
15 9 17 0,
16 7 18 0,
17 19 22 0,
18 5 20 0,
19 3 21 0,
20 13 22 0,
21 15 18 0,
2 24 28 0,
23 4 25 0,
24 6 26 0,
25 8 27 0,
26 10 28 0,
27 12 23 0,
28,
12 13 2 0,
1 3 21 0,
2 19 4 0,
3 5 22 0,
4 18 6 0,
5 7 23 0,
6 17 8 0,
7 9 25 0,
8 15 10 0,
9 11 26 0,
10 14 12 0,
11 1 27 0,
1 14 20 0,
13 11 15 0,
14 9 16 0,
15 17 20 0,
16 7 18 0,
17 5 19 0,
18 3 20 0,
19 13 16 0,
2 22 28 0,
21 4 23 0,
22 6 24 0,
23 25 28 0,
24 8 26 0,
25 10 27 0,
26 12 28 0,
27 21 24 0
Normally the code entries are of type unsigned char (1--byte size,
i.e. numbers between 0 and 255). But if the
number of vertices for one graph is higher than 252, then the code for this
graph begins with a zero (unsigned char) and then each following entry is of
the type unsigned short (2 bytes). In this case it makes a difference
whether the entry is stored in little endian or big endian style (the endian
determines whether a number like 19 is stored by storing the 1 or the 9 first).
The output style that is produced always depends on the definition
of the
internal constant ENDIAN_OUT (see section
constans
.
) which value
is usually
consistent to the endian of the computer. The input style that is assumed
depends
on the definition of the constant ENDIAN_IN. But if the input file begins with
a header that contains a "be" or "le"--parameter, then the input style is
big endian or little endian, respectively. If the file contains no graphs with
more than 252 vertices, then it is not important if the style is little endian
or big endian.