source: git/IntegerProgramming/globals.h @ 10b7a4

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