1 | // globals.h |
---|
2 | |
---|
3 | // In this file |
---|
4 | // - some facilities as the g++ input/output routines are included, |
---|
5 | // - the general data type can be chosen (the people of Singular do not like |
---|
6 | // templates), |
---|
7 | // - some makros are defined for an easier handling of the program, |
---|
8 | // - some flags and constants can be set to observe the behaviour of the |
---|
9 | // algorithms when using different strategies. |
---|
10 | |
---|
11 | #ifndef GLOBALS_H |
---|
12 | #define GLOBALS_H |
---|
13 | |
---|
14 | // Include facilities needed by several files: |
---|
15 | |
---|
16 | #include <stdio.h> |
---|
17 | #include <iostream.h> |
---|
18 | #include <fstream.h> |
---|
19 | #include <iomanip.h> |
---|
20 | #include <stddef.h> |
---|
21 | #include <stdlib.h> |
---|
22 | #include <math.h> |
---|
23 | #include <limits.h> |
---|
24 | #include <string.h> |
---|
25 | |
---|
26 | // Include a BigInt class from a foreign library: |
---|
27 | // This is needed by the LLL algorithm. If no such class is included, |
---|
28 | // it computes with long ints; this results in overflows and unexpected |
---|
29 | // behaviour even when computing with relatively small instances. |
---|
30 | |
---|
31 | #define GMP |
---|
32 | |
---|
33 | #ifdef GMP |
---|
34 | |
---|
35 | #include "BigInt.h" |
---|
36 | |
---|
37 | #else // GMP |
---|
38 | |
---|
39 | typedef long BigInt; |
---|
40 | |
---|
41 | #endif // GMP |
---|
42 | |
---|
43 | // Define the general data type: |
---|
44 | // short seems to be sufficient for most practicable instances. |
---|
45 | |
---|
46 | typedef short Integer; |
---|
47 | // The general data type to deal with can be short, long or int... |
---|
48 | |
---|
49 | #define _SHORT_ |
---|
50 | // For an overflow control for thE result of the LLL algorithm, we have to |
---|
51 | // know the data type used. |
---|
52 | |
---|
53 | |
---|
54 | |
---|
55 | // Define a BOOLEAN data type etc. for an easy-to-read code: |
---|
56 | |
---|
57 | typedef char BOOLEAN; |
---|
58 | #define TRUE 1 |
---|
59 | #define FALSE 0 |
---|
60 | |
---|
61 | #define MAXIMUM(a,b) (a>b? a:b) |
---|
62 | |
---|
63 | #define INHOMOGENEOUS 0 |
---|
64 | #define HOMOGENEOUS 1 |
---|
65 | // For a more comfortable call of the term_ordering constructors. |
---|
66 | |
---|
67 | |
---|
68 | |
---|
69 | |
---|
70 | // Enumerate the algorithms: |
---|
71 | // The ideal constructor (builds an ideal from the input matrix) depends on |
---|
72 | // the algorithm. The constants are defined to make constructor calls easier |
---|
73 | // (you do not need to remember a number). |
---|
74 | |
---|
75 | #define CONTI_TRAVERSO 1 |
---|
76 | #define POSITIVE_CONTI_TRAVERSO 2 |
---|
77 | #define POTTIER 3 |
---|
78 | #define HOSTEN_STURMFELS 4 |
---|
79 | #define DIBIASE_URBANKE 5 |
---|
80 | #define BIGATTI_LASCALA_ROBBIANO 6 |
---|
81 | |
---|
82 | |
---|
83 | |
---|
84 | |
---|
85 | // Enumerate the criteria to discard unnecessary S-pairs: |
---|
86 | // The constants are defined to allow an easier call of BuchbergerŽs algorithm |
---|
87 | // with different criteria. This algorithm takes as an argument a short int |
---|
88 | // which represents the combination of criteria to be used (with a default |
---|
89 | // combination if no argument is given). |
---|
90 | // The method to compute the argument for a certain combination is simple: |
---|
91 | // Simply add the constants that belong to criteria you want to use. As the |
---|
92 | // constants are chosen to be different powers of 2, each short int (in the |
---|
93 | // range of 0 to 31) gives a unique combination (cf. the read-write-execute |
---|
94 | // rights for files in UNIX systems). |
---|
95 | // EXAMPLE: |
---|
96 | // If you want to call BuchbergerŽs algorithm with the criterion "relatively |
---|
97 | // prime leading terms" and the second criterion for the ideal I, write: |
---|
98 | // |
---|
99 | // I.reduced_Groebner_basis_1(REL_PRIMENESS + SECOND_CRITERION); |
---|
100 | // or |
---|
101 | // I.reduced_Groebner_basis_1(17); |
---|
102 | // |
---|
103 | // The argument 0 means that no criteria are used, the argument 31 leads to |
---|
104 | // the use of all criteria. |
---|
105 | |
---|
106 | #define REL_PRIMENESS 1 |
---|
107 | #define M_CRITERION 2 |
---|
108 | #define F_CRITERION 4 |
---|
109 | #define B_CRITERION 8 |
---|
110 | #define SECOND_CRITERION 16 |
---|
111 | |
---|
112 | // The names of tehse criteria are chosen according to the criteria |
---|
113 | // described in Gebauer/Moeller (except from the last). |
---|
114 | // The first one (relatively prime leading terms) is a local criterion |
---|
115 | // and the most effective. |
---|
116 | // The last four criteria are global ones involving searches over the |
---|
117 | // generator lists. But although the lcm-computations performed by these |
---|
118 | // checks are not much cheaper than a reduction, most of the criteria seem to |
---|
119 | // accelerate the computations. |
---|
120 | // REL_PRIMENESS should always be used. |
---|
121 | // The Gebauer/Moeller-criteria (M,F,B) seem to improve computation time in |
---|
122 | // the general case; Buchberger's second criterion seems to improve it in |
---|
123 | // more special cases (for example the transportation problem). They should |
---|
124 | // be switched on and off according to these results, but never be enabled |
---|
125 | // together; the overhead of too many criteria leads to a rather bad |
---|
126 | // performance in all cases. |
---|
127 | // The relatively primeness criterion is tested first because it |
---|
128 | // is very easy to check. The order of the Gebauer/Moeller-criteria does not |
---|
129 | // really affect computation. The relative order of the Gebauer/Moeller |
---|
130 | // criteria and the second criterion (if they are enabled together) has almost |
---|
131 | // the same effect as switching off the last criterion in this order. |
---|
132 | // There is no possibility to change the order in which the criteria are |
---|
133 | // tested without changing the program! |
---|
134 | |
---|
135 | |
---|
136 | |
---|
137 | |
---|
138 | // Enumerate the term orderings that can be used to refine the weight: |
---|
139 | // W_REV_LEX will give a term ordering in the classical sense if and only if |
---|
140 | // all weights are positive. It has been implemented because several |
---|
141 | // algorithms need a reverse lexicographical refinement. (Of course, these |
---|
142 | // algorithms control if they have a positive grading.) |
---|
143 | // A warning will be output when using W_REV_LEX in an insecure case. |
---|
144 | |
---|
145 | #define W_LEX 4 |
---|
146 | #define W_REV_LEX 5 |
---|
147 | #define W_DEG_LEX 6 |
---|
148 | #define W_DEG_REV_LEX 7 |
---|
149 | |
---|
150 | |
---|
151 | |
---|
152 | // Enumerate the term ordering used for the block of elimination variables: |
---|
153 | |
---|
154 | #define LEX 1 |
---|
155 | #define DEG_LEX 2 |
---|
156 | #define DEG_REV_LEX 3 |
---|
157 | |
---|
158 | ////////////////////////////////////////////////////////////////////////////// |
---|
159 | /////////////// TEST PARAMETER SECTION //////////////////////////////// |
---|
160 | ////////////////////////////////////////////////////////////////////////////// |
---|
161 | |
---|
162 | // Set flags concerning the basic operations and the course of Buchberger's |
---|
163 | // algorithm: |
---|
164 | |
---|
165 | #define SUPPORT_DRIVEN_METHODS |
---|
166 | // possibilities: |
---|
167 | // SUPPORT_DRIVEN_METHODS |
---|
168 | // NO_SUPPORT_DRIVEN_METHODS |
---|
169 | |
---|
170 | // This flag allows to switch of and on the use of the support vectors in |
---|
171 | // the binomial class; these are used to speed up tests for reducibility of |
---|
172 | // binomials, relative primeness etc. |
---|
173 | |
---|
174 | #define SUPPORT_DRIVEN_METHODS_EXTENDED |
---|
175 | // possibilities: |
---|
176 | // SUPPORT_DRIVEN_METHODS_EXTENDED |
---|
177 | // NO_SUPPORT_DRIVEN_METHODS_EXTENDED |
---|
178 | |
---|
179 | // This flag allows to switch of and on the extended use of the support |
---|
180 | // information. This includes the splitting of the ideal generators into |
---|
181 | // several lists according to their head support. This discards many |
---|
182 | // unnecessary tests for divisibility etc. |
---|
183 | // SUPPORT_DRIVEN_METHODS_EXTENDED should only be enabled when |
---|
184 | // SUPPORT_DRIVEN_METHODS is set, too! The combination |
---|
185 | // NO_SUPPORT_DRIVEN_METHODS and SUPPORT_DRIVEN_METHODS_EXTENDED is quite |
---|
186 | // senseless and will only work if your compiler automatically initializes |
---|
187 | // integers to zero. |
---|
188 | |
---|
189 | const unsigned short List_Support_Variables=8; |
---|
190 | |
---|
191 | // This is the number of variables considered to create and maintain the |
---|
192 | // generator lists of an ideal if SUPPORT_DRIVEN_METHODS_EXTENDED is |
---|
193 | // enabled. As there are 2^List_Support_Variables lists, this number |
---|
194 | // should not be too big (to avoid the overhead of many empty lists). |
---|
195 | // The best number may depend on the problem size and structure... |
---|
196 | |
---|
197 | #define SUPPORT_VARIABLES_LAST |
---|
198 | // possibilities: |
---|
199 | // SUPPORT_VARIABLES_LAST |
---|
200 | // SUPPORT_VARIABLES_FIRST |
---|
201 | |
---|
202 | // This flag determines whether the first or the last variables are considered |
---|
203 | // by the support methods. So this setting will only affect the computation if |
---|
204 | // such methods are enabled. |
---|
205 | // The reason for the introduction of this flag is the following: |
---|
206 | // The Conti-Traverso algorithm for solving an integer program works in two |
---|
207 | // phases: Given an artificial solution in auxiliary variables, these |
---|
208 | // variables are first eliminated to get a feasible solution. The elimination |
---|
209 | // variables are for technical reasons always the last. In a second phase, |
---|
210 | // this solution is reduced to a minimal solution with respect to a given |
---|
211 | // term ordering. |
---|
212 | // If SUPPORT_VARIABLES_LAST is set, the first phase will probably take |
---|
213 | // less time as if SUPPORT_VARIABLES_FIRST is set. If one is only interested |
---|
214 | // in finding a feasible solution (not necessary minimal), |
---|
215 | // SUPPORT_VARIABLES_LAST might be the better choice. |
---|
216 | |
---|
217 | #endif // GLOBALS_H |
---|
218 | |
---|