A Genetic Algorithm Solving

a Weekly Course-Timetabling Problem

Wilhelm Erben and Jürgen Keppler

Department of Computer Science, Fachhochschule Konstanz, D-78462 Konstanz
(e-mail: erben@fh-konstanz.de, jkeppler@fh-konstanz.de)

Abstract. In this paper we describe a heavily constrained university time-

tabling problem, and our genetic algorithm based approach to solve it. A pro-
blem-specific chromosome representation and knowledge-augmented genetic
operators have been developed; these operators ‘intelligently’ avoid building
illegal timetables. The prototype timetabling system which is presented has
been implemented in C and PROLOG, and includes an interactive graphical
user interface. Tests with real data from our university were performed and
yield promising results.

1 Introduction
The course-timetabling problem essentially involves the assignment of weekly lectures
to time periods and lecture rooms. Because there are quite a lot of versions of the
timetabling problem, differing from one school to the next, we focus on constructing
course timetables at our own university rather than on trying to develop a universal
program.
Faced with increasing student numbers, with new courses introduced, with shortage of
lecture rooms and laboratories and with growing numbers of lessons open for students
of different departments, and hence with a large number of conflicting constraints,
timetables which can be largely accepted by teachers and students are very difficult to
schedule at our university.
We present a prototype of a system for the automated construction of timetables which
is based on genetic algorithm techniques. It therefore aims not only at finding a fea-
sible solution to the problem, but it also searches for timetables people can be happy
with in that as many nice-to-have constraints as possible are satisfied.
A ‘natural’ chromosome representation was chosen, and the genetic operators we
developed make use of knowledge specific to the particular problem. In that way we
avoid building illegal timetables, and are not in need of any ‘repair algorithm’. This is
in contrast to approaches described in other papers (see e.g. [4], [5] and [13]).
The initialisation of a population, the evaluation, and the genetic operators were im-
plemented in PROLOG. These procedures are controlled by a program written in C,
which is combined also with an interface enabling the user to interact and modify
various parameter settings.
In section 2 our special timetabling problem is depicted in full detail. The genetic
algorithm, the underlying chromosome representation, the genetic operators, and the
evaluation function are presented in section 3. Some implementational aspects of our
timetabling system are described in section 4. Finally, section 5 presents computatio-
nal results and conclusions.

2 The Weekly Course-Timetabling Problem

Our weekly course-timetabling problem involves scheduling classes, teachers, course
modules and rooms to a number of periods (or time slots) in a week.
Each day of the week is divided into 6 periods (of 90 minutes’ duration). There are 5
working days per week. Hence, the set P of periods consists of 30 elements. We deno-
te these elements by mon1, mon2, ....., mon6, tue1, tue2, .........., fri6.
Our university offers a number of courses (e.g. Business Computing, Architecture,
Civil Engineering, ...) in different departments, and each course lasts eight semesters.
A class consists of all students studying a given course in the same semester. We
denote by C the set of all classes. For each class c ∈ C the (estimated) maximum
number of students must be given as part of the input to our system.
T is the set of all teachers (lecturers, tutors, etc.). Each lecturer requires a number of
free-time slots (or even one or two free days) where he or she is unavailable. These
data must also be present.
R is the set of all rooms available in the university. A room can be a laboratory (e.g.
for chemistry, or computing) or a lecture theatre. Some rooms can only be used by the
department to which they belong. Each room has a maximum capacity which must be
given.
Each department offers a number of course modules. A course module may be taken
by students of one or more classes. It may either be compulsory or optional.
A course module consists of one or more lessons. A lesson may be a lecture, a labora-
tory or a group exercise class, and it has a duration of 90 minutes. The lessons belon-
ging to one course module may be taught by different teachers. The set of all lessons
is denoted by L. For each l ∈ L the type of the lesson, its unique teacher and the
coordinate list of classes must be present.
The input data also specifies those lessons for which particular requirements exist:
Some lessons must be taught in special rooms, for instance in a computing lab. Some
lessons must be scheduled to more than one room (for instance, a lecture theatre and a
lab; this enables a teacher to decide each week in which of the two differently equip-
ped rooms his or her lesson should take place). Some lessons are prescheduled, i.e.
must appear in a specified period in the timetable. Some lessons must be blocked, i.e.
scheduled to consecutive periods.
A timetable is feasible if and only if the following hard constraints are satisfied:
• Each lesson l ∈ L is scheduled to exactly one period.
• There are no clashes at all: Neither a class nor a teacher nor a room is assigned to
more than one lesson in the same period.
• Teacher unavailabilities are considered.
• All allocated rooms are large enough to hold the students.
• Specific room requirements are taken into account.
• Lessons marked as prescheduled are scheduled to the specified time.
• Lessons are blocked, if so required.
There is also a huge list of second-order (or: soft) constraints which should be taken
into account if possible. Here are some examples:
• Students, as well as some teachers, do not like to have many ‘holes’ (empty peri-
ods between two lessons) in their timetables.
• Lessons should be spread uniformly over the whole week, in general.
• Some teachers, by contrast, wish to have all their lessons scheduled to consecutive
periods.
• Some teachers wish to have a special equipped classroom.
• In order to avoid much movement, lecture rooms should be close to the host de-
partment.
• Some lessons should not take place late in the evening.
• Each student may select a certain number of optional course modules; in order to
give a real choice, conflicts where 2 modules chosen by a student are scheduled at
the same period should be avoided.
• Rooms should be just large enough to hold the students.
We decided not to separate room assignment from time scheduling because one of the
main goals consists in achieving efficient room utilization rates. This is accomplished
in a more promising way by trying to do (or modify) time and room assignments si-
multaneously.

3 The Algorithm
3.1 Chromosome Representation
In a ‘classical’ genetic algorithm chromosomes are represented as bit strings. How-
ever, we believe that problem-specific knowledge should be incorporated in the re-
presentation of solutions to our timetabling problem, and the chromosome represen-
tation should be ‘natural’: It should contain all the relevant information and be close
to the original problem.
In this sense it is straightforward to define a timetable to be a map
f : C × T × L × R × P → {0 ,1},
where f ( c, t , l , r , p ) = 1 if and only if class c and teacher t have to meet for a lesson l
in room r at period p. Such a mapping is easily translated into PROLOG facts of the
form
timetable( Class, Teacher, Lesson, Room, Period ).
A fact is either a member of the timetable database and therefore true, or it simply
does not exist. A gene, in this representation, may also be considered as an element of
a 5-dimensional matrix, with an allelic value of 0 (false) or 1 (true).
Recall that the input data of our system specifies for each lesson a unique teacher.
Therefore, we can simplify the definition of a chromosome slightly:
f : C × L × R × P → {0 ,1} .
Different classes, by contrast, can share common lessons. Let us denote by Lc the set
of all lessons which are offered to class c. Then, for a timetable f to be feasible it is
necessary that
f ( c , l , R , P ) = {0} , if l ∉ Lc ,
and
f ( c , l , r , p ) = f ( c ′ , l , r , p ) , if l ∈ Lc ∩ Lc′ .
Similarly, some lessons must be scheduled to more than one room (see section 2). In
order to take into account this requirement, actually, we deal with lists of rooms in-
stead of single elements r ∈ R . For the sake of simplicity, however, we do not descri-
be this in further detail.
Given an arbitrary timetable f and a subset π of the set P of periods (a ‘time window’
cut out of the week), we denote by L( f ; π ) the set of all lessons which are scheduled
in the timetable f to a period p ∈ π . For a c ∈ C , the set
Lc ( f ; π ) = L( f ;π ) ∩ Lc
contains only those lessons of L( f ; π ) which are attended by students of class c.
Clearly, L( f ; P ) = L and Lc ( f ; P ) = Lc .
Figure 1 shows a timetable f restricted to a specific class c (which is identified by the
symbolic name WI2). algoA, wengA, etc. are unique identifiers of lessons. Let π, for
instance, be the time window made up of the periods mon2, mon6, wed2, thu2 and
fri5; then
Lc ( f ; π ) = {bwl 2 A,anis2 C ,anis2 A,bwl 2 B} .
 Class WI 2

algoA g240 algoC g149 rarcA g042

anis2C g257 anis2A c109

wengA g042 bwl2C l100 rewe1B g042

rarcA g042 wimaA c109 anis2B g042

algoB g147 rewe1A g042 wengB l100 bwl2B g042

bwl2A l100

Fig. 1. Part of a Randomly Generated Timetable

3.2 Initialisation
The initialisation procedure creates at random a population of feasible solutions (as
defined in section 2). Our objective, valid for the whole algorithm, is to start with
legal timetables and never leave this search space. Otherwise, in a highly constrained
problem like ours, “one runs the risk of creating a genetic algorithm that spends most
of its time evaluating illegal individuals” [8], and the chances of an effective search
for good solutions would be very low.
The price we have to pay for this is that initializing a population (and defining advan-
ced genetic operators) is not a simple task. In fact, the timetable problem is known to
be NP-hard [11]. Nevertheless, our PROLOG-based assignment procedure succeeds
in producing an initial population. The members of this population, however, suffer
from very poor fitness, in general: They may contain a large number of ‘holes’, or
courses are allowed, for example, to run on Friday late evening, even though this
would not be accepted in practice. This is because the initialisation routine does not
care at all about soft constraints; otherwise the procedure would not have enough
degrees of freedom and would frequently fail. Handling soft constraints is left to the
evolutionary process that follows. Figure 1 shows part of a timetable which was gene-
rated by the initialisation procedure.
Of course, a number of necessary conditions for the existence of solutions must have
been checked before we start the initialisation process. For a timetable to be genera-
ted, those lessons that are fairly limited as to their possible allocation are considered
first: Having processed the (normally few) items which are marked as ‘presche-duled’,
the set of lessons requiring a special laboratory, or having to appear in the timetable in
consecutive periods, has preference to the set of those lessons which are almost entire-
ly free in this respect. Apart from this obvious strategy, lessons are selected in random
order, and each lesson is assigned to a randomly chosen period and lecture room
without violating any hard constraint. The rooms are selected according to a list of
priorities: rooms should be close to the home department if possible.
3.3 Evaluation
Our evaluation function is made up in the form

eval( f ) = 1+cos1t ( f )

where cos t ( f ) is a sum of weighted penalty values:

k
cos t ( f ) = ∑ wi ⋅ ni ( f )
i=1

(see [7], e.g.). Here, ni ( f ) is a penalty value imposed to the violation of a specific
soft constraint, and wi an attached weight. n1 ( f ) may count, for instance, the num-
ber of undesirable ‘holes’ in the timetable f. n 2 ( f ) could be the component measu-
ring the costs of having scheduled lessons so that some classes have to attend more
than four lectures during a day. n 3 ( f ) could be the number of large rooms allocated
to lessons attended by only a few students; etc. Note that we do not need to impose
penalties on violated hard constraints because the concept of our domain-specific
genetic operators is to produce only feasible solutions.
The values of the evaluation function range from 0 to 1, and our genetic algorithm
aims at finding a timetable which maximizes this function. We are still experimenting

with different settings {w1 , w2 , , w k } of weights for the components of the cost
function. Often it is hard to decide which soft constraints should be considered to be
more important than others. Students, for example, may be exhausted after 3 hours of
maths, whereas a teacher might insist in having his lectures in consecutive periods.
Some teachers are happy if all their lectures take place within two days of the week,
others might prefer to spread them over the whole week.

3.4 Mutation
Having selected a timetable f for mutation, a natural number m and a set π ⊆ P con-
sisting of m (not necessarily contiguous) periods are chosen at random and the set
L( f ; π ) (see section 3.1) is formed. A mutated timetable f ′ is produced by assigning
new periods or rooms only within the ‘time window’ π and by leaving the rest un-
changed. Taking π and L( f ; π ) , instead of P and L, as input, the initialisation proce-
dure described in section 3.2 does the job.
The window size m ranges between two values mmin and mmax which are parameters
of this mutation operator. Clearly, if m is too small, the mutation operator might fail in
finding a solution f ′ different from f. This is because even slight modifications of
period or room assignments are likely to produce invalid timetables, and some points
in the search space may be ‘isolated’, i.e. there might be no feasible timetable in a
neighbourhood local to the given one. On the other hand, if m is too large, f ′ may
lose similarities to f.
We have tested mutation with different parameter settings and have seen best results
for random numbers m between 4 and 15. As special cases of mutation we get operati-
ons like swapping time assignments between teachers or classes, shifting a lesson into
an empty slot, permuting the order of some lessons, or merely changing rooms, as long
as the feasibility conditions are not violated. In general, however, combina-tions of
these elementary operations arise.

Class WI 2

algoA g240 algoC g149 rarcA g042

bwl2A l100 bwl2B l100 anis2A l100

wengA g042 bwl2C l100 rewe1B g042

rarcA g042 wimaA c109 anis2B g042

algoB g147 rewe1A g042 wengB l100 anis2C g042

Fig. 2. Timetable of Figure 1 After Mutation

Figure 2 shows, as an example, part of a timetable f ′ which is a mutation of timetable

f from Figure 1. The set π includes the periods mon2, mon6, wed2, thu2 and fri5. The
lesson bwl2A was shifted from mon6 to mon2. For the lesson anis2A, scheduled to
thu2, only the room number was changed, from c109 to l100. The time assignments of
the lessons anis2C and bwl2B were swapped.
The kernel of our mutation algorithm could also be used if we wanted to modify a
given timetable slightly, rather than develop a new one from the scratch. We feel that
this is what a mutation in our timetabling problem should look like: It is a stochastic
operator which introduces new solutions into the population without destroying infor-
mation which belongs to ‘good’ timetables and which has already been accumulated.

3.5 Crossover
Having selected two parent timetables f and g, let us call them mother and father
respectively, we build offspring in such a way that each lesson and its time and room
assignment comes from one of the parents. This is done by generating, for each class
c ∈ C , a set π c ⊆ P of periods such that the timetable defined by
 f ( c,l ,r , p ), iff p∈π c
h( c, l , r , p ) =  g( c,l ,r , p ),
 else
is feasible. h is an offspring which has inherited some properties from mother f, others
from father g (see figures 3 to 5 for an example). A second offspring is simply
established by changing the roles of f and g.
In order to explain the mechanism in more detail we have to introduce the notion of a
cycle: Given a class c ∈ C and a period p ∈ P , a cycle for c generated by p (with
respect to the parents f and g) is a minimal set ζ c ( p ) ⊆ P containing p such that
Lc ( f ; ζ c ( p )) = Lc ( g ; ζ c ( p )) ,
i.e. the lessons of class c at the periods in ζ c ( p ) are the same in both mother timetable
f and father timetable g (though perhaps permuted).
Take c = WI 1 and p = fri 2 in figures 3 and 4, and

ζ c ( p ) = {tue1,tue2 , fri 1, fri 2 , fri 3}

as an example of a cycle for class WI1. This cycle is generated by using the following
algorithm: Starting with period fri2, which must belong to the cycle, we see that lesson
anis1B in mother timetable f corresponds to lesson bwl1B in father timetable g. In
timetable f again, lesson bwl1B can be found at period tue1. We therefore add tue1 to
the list of periods to be generated. This, in turn, implies that fri1 must also belong to
the cycle: lesson anis1A, scheduled to tue1 in father timetable g, is found at period
fri1 of mother timetable f. Proceeding in this way, the next step consists in looking at
period fri1 in timetable g: Because this is an empty time slot, we randomly choose an
empty period in timetable f which could be, for instance, fri3. In that case tue2 would
be the next period to be added. Finally, we return to period fri2 which is already on
the list. Hence, we have completed the cycle.
The crossover operator starts with a class c0 and a period p0 , both chosen at random,
and generates a cycle ζ c0 ( p0 ). This cycle will be part of the set of periods π c0
which we aim to construct: ζ c0 ( p0 ) ⊆ π c . Hence all assignments for class c0 wit-
0
hin the time window ζ c0 ( p0 ) will be taken from the mother timetable f, in order to
build the offspring h. If all other parts of timetable h were taken from father g, no
conflicts would arise as long as only the restriction of h to class c0 is considered: All
lessons for class c0 would have been scheduled then, and no student of class c0
would have to attend more than one lesson in a period.
But, suppose now that there exist a period p1 ∈ ζ c ( p0 ) and a teacher t with the
0
following property: At period p1 , t has to meet class c0 for a lesson l0 , according to
mother timetable f ; according to father g, on the other hand, teacher t is scheduled to
meet class c1 (≠c0 ) for a lesson l1 (≠l0 ) at period p1 . In that case, the crossover
procedure will generate a cycle ζ c ( p1 ).
1
See figures 3 and 4 for an example: The lesson l0 = bwl 1 B for class c0 = WI 1 is
scheduled by f to period p1 = tue1. In timetable g the lesson l1 = bwl 2 B for class
c1 = WI 2 appears in the same period. Suppose, both lessons have the same lecturer.

Class WI 1

bwl1B g240 algeA g250 anis1C g257 anis1A a026

bwl1C g240 hardD l101 strpB g250 anis1B a026

hardA l102 strpA g250 hardB l101 algeB c005

bwl1A n206 hardC l101 strpC g149

stdsA nk01 strpD g149

strpE g149

Class WI 2

algoA g042 rewe1A l100

rarcA l102 algoB g042 anis2A g150 wimaA l100 rewe1B g042

wengA l100 bwl2A g042 rarcB c109 anis2C g042

bwl2B g147 algoC g147 anis2B l100

bwl2C g147 wengB l100

Fig. 3. Mother Timetable f

 Class WI 1

anis1A l100 hardA l101 anis1C g257

anis1B l100 hardB l101 strpB g250 bwl1B g240

hardD l102 strpA g250 hardC l101 bwl1C g240

stdsA g147 algeA l102 strpC g149

bwl1A g042 algeB l102 strpD g149

strpE g149

Class WI 2

bwl2B g147 rarcB c109

rarcA l102 bwl2C g147 anis2A g150 anis2C g042

wengA l100 algoA g042 rewe1A l100 rewe1B g042

bwl2A g042 algoB g042 anis2B l100 wimaA l100

algoC g147 wengB l100

Fig. 4. Father Timetable g

Class WI 1

bwl1B g240 hardA l101 anis1C g257 anis1A a026

bwl1C g240 hardB l101 strpB g250 anis1B a026

hardD l102 strpA g250 hardC l101

bwl1A n206 algeA l102 strpC g149

stdsA nk01 algeB l102 strpD g149

strpE g149

Class WI 2

algoA g042 rarcB c109

rarcA l102 algoB g042 anis2A g150 rewe1B g042

wengA l100 bwl2A g042 rewe1A l100 anis2C g042

bwl2B g147 anis2B l100 wimaA l100

algoC g147 bwl2C g147 wengB l100

Fig. 5. Offspring Timetable h

Then, if we took the assignments for WI1 on early Tuesday morning from mother, and
those for class WI2 from father, a conflict would arise. Thus, if tue1 belongs to a cycle
which was already generated for class WI1, we should mark this period also for class
WI2 as to be taken from the mother timetable; in other words, we should generate the
cycle ζ WI 2( tue1).
Similarly, cycles have to be generated in order to avoid room conflicts, or in order to
have regard to lessons which are attended by students of more than one class. Then, if
for a class c disjoint cycles ζ c , ζ c′ , ζ c′′ , ... have been produced, the set π c is defined
by
π c = ζ c ∪ ζ c′ ∪ ζ c′′ ∪ 
Time windows π c typically look like the marked parts in the timetables of figures 3 to
5. For some classes c we may have π c = P , which means that timetable h inherits all
the assignments for class c from mother. If π c = ∅, to take the other extreme, the
offspring looks exactly like father in this respect.
Note that cycles generated by a period may contain empty time slots (‘holes’). That is
why they are not necessarily unique. Also, even if mother and father are totally diffe-
rent timetables, cycles consisting of only a few periods can normally be found.
Let C denote the number of elements of the set C. In the worst case, the crossover
procedure had to process all C ⋅ ( C − 1) pairs (c,c′) of classes in the way described
above. However, in practice the complexity is much lower because classes from diffe-
rent departments, such as architecture and telecommunication, rarely share common
teachers or lessons. Therefore the search for potential clashes can be restricted to pairs
of classes belonging to the same or to related courses.

4 Implementation
Before we could start the implementation of our timetabling program, some funda-
mental considerations had been necessary. We wanted the system to be equipped with
a hardware independent graphical user interface, in order to be able to use it on diffe-
rent workstations. We further desired that it should be easily possible to manage the
input data, consisting of the facts and rules out of which feasible timetables are produ-
ced. Constraints often have transitive dependence; therefore to have an inference
mechanism seemed to be worthwhile.
 Main Program ( C )
Quintus Interface Library
User Interface
Genetic Operators ( Prolog ) (C )

Motif (Xm) Library

Quintus Prolog TT Library
(C) Xt Intrinsics Library
QP Libraries Xlib Library

HP-UX Operating System

Fig. 6. Program Library Model

For the realization of the graphical user interface we use the X Window system which
is available on our HP workstations. The X and Motif libraries, however, exist only
for the C programming language. On the other hand, we are in need of a programming
language like PROLOG which is useful for solving problems that involve objects and
relationships between them; with the power of logic programming constraints are
easily handled. In order to be able to combine these completely different languages we
use Quintus Prolog, which provides an interface to foreign programming languages
and is also available for HP workstations.
The main program of our timetabling system interacts with all layers of the windowing
system, the operating system, and the Quintus interface library. The user interface, by
contrast, is restricted to the Motif, Xt, and Xlib libraries (see figure 6), in order to
support its portability. It is implemented in C, whereas the genetic operators are writ-
ten in PROLOG.
The genetic operators can be reached by the main program only by using functions of
the Quintus Interface Library. They can interact with the main program using our TT
Library which is written in C, and use Quintus Prolog and its libraries.

Fig. 7. Parameter Input Window

We designed the user interface with two different windows, one for the input of pa-
rameters and starting the program (see figure 7), and the other for the output of a
timetable (see figures 1 to 5). In the input window, among other parameters, the cross-
over and mutation probabilities, the population size and the number of iterations can
be set. By pushing certain buttons, the generation of a random population of timeta-
bles can be initiated, and the iterations of the genetic algorithm can be controlled.
It is possible to look at each timetable produced by the system from different views: A
given lecturer’s timetable can be displayed, as well as the timetable of a specific class
or room. A view can be selected by pushing the corresponding button.

5 Results and Conclusions

We have been testing our system using a large data sample and incorporating all types
of possible constraints. The results are promising, but a number of refinements still
have to be made during the next few months. In particular, we still have to find the
optimal parameter settings.
In figure 8, results from a test run with a crossover rate of 0.8 and a mutation rate of
0.2 are shown. The run was stopped after 2500 generations. It took almost 30 minutes
to generate the initial population of 25 chromosomes, and about 8.5 hours were nee-
ded for the iterative process.
Recall that our evaluation function takes values between 0 and 1, and has to be ma-
ximized. The fitness values of the initial population range from 0.36 to 0.48, whereas
after 2500 generations values between 0.91 and 0.93 have been achieved. These figu-
res have to be compared with a value of approximately 0.91, which has been calcula-
ted for the hand-made timetable of the last year.
Next steps will be tests with full data (about 300 teachers, more than 80 classes,
approximately 1500 lessons, nearly 100 rooms) and will include experimentation on
parallelizing the algorithm. We shall have to improve and extend the heuristics used in
our genetic operators. The effect of incorporating local search and/or elitism will be
investigated. In order to get accepted by a timetabler at our university, the algorithm
has to be made more transparent. The user should be able to modify, to a certain ex-
tent, the evaluation function according to his own understanding of a ‘good’ timetable.
Finally, we shall expand the graphical user interface such that basic input data, inclu-
ding second-order constraints, is entered or modified easily.
best fitness values
1

0,9

0,8

0,7

0,6

0,5

0,4

0,3
0 500 1000 1500 2000 2500
generations
Fig. 8. Results from a Test Run
References
[1] Abramson, D. (1991): Constructing School Timetables Using Simulated Annealing:
Sequential and Parallel Algorithms. Management Science 37/1: 98-113
[2] Burke, E.K.; Elliman, D.G.; Weare, R. (1994): A Genetic Algorithm for University
Timetabling. Proceedings of the AISB Workshop on Evolutionary Computing, Leeds
[3] Burke, E.K.; Elliman, D.G.; Weare, R. (1995): A Genetic Algorithm Based University
Timetabling System. In: Proceedings of the 2nd East-West International Conference on
Computer Technologies in Education, Sep. 19-23, Crimea, Ukraine, Vol. I: 35-40
[4] Colorni, A.; Dorigo, M.; Maniezzo, V. (1990): A Genetic Algorithm to Solve the Time-
table Problem. Technical Report No. 90-060, Politecnico di Milano, Italy
[5] Colorni, A.; Dorigo, M.; Maniezzo, V. (1991): Genetic Algorithms and Highly Con-
strained Problems: The Time-Table Case. In: Schwefel, H.-P.; Männer, R. (eds.): Paral-
lel Problem Solving from Nature. Proceedings of the First Workshop PPSN I, Dort-
mund, Oct. 1-3. Springer, Berlin: 55-59
[6] Corne, D.; Fang, H.-L.; Mellish, C. (1993): Solving the Module Exam Scheduling Pro-
blem with Genetic Algorithms. In: Chung; Lovegrove; Ali (eds.): Proceedings of the
Sixth International Conference on Industrial and Engineering Applications of Artificial
Intelligence and Expert Systems: 370-373
[7] Corne, D.; Ross, P.; Fang, H.-L. (1994): Fast Practical Evolutionary Timetabling. In:
Fogarty, T.C. (ed.): Evolutionary Computing. AISB Workshop, Leeds, U.K., April 11-
13. Selected Papers. LNCS 865. Springer, Berlin: 250-263
[8] Davis, L.; Steenstrup, M. (1987): Genetic Algorithms and Simulated Annealing: An
Overview. In: Davis, L. (ed.), Genetic Algorithms and Simulated Annealing. Morgan
Kaufmann Publishers Inc., Los Altos, CA: 1-11
[9] East, N. (1995): Genetische Algorithmen für Stundenpläne. Final Year Project Disserta-
tion, University of Nottingham, U.K., and Fachhochschule Konstanz, Germany
[10] Erben, W. (1995): Timetabling Using Genetic Algorithms, in: Pearson, D.W.; Steele,
N.C.; Albrecht, R.F. (eds.): Artificial Neural Nets and Genetic Algorithms. Proceedings
of the International Conference in Alès/France. Springer, Wien: 30-32
[11] Evan, S.; Itai, A.; Shamir, A. (1976): On the Complexity of Timetable and Multicom-
modity Flow Problems. SIAM Journal of Computing vol. 5, no.4: 691-703
[12] Kang, L.; White, G.M. (1992): A Logic Approach to the Resolution of Constraints in
Timetabling. European Journal of Operational Research 61: 306-317
[13] Ling, S.E. (1992): Integrating Genetic Algorithms with a Prolog Assignment Program
as a Hybrid Solution for a Polytechnic Timetable Problem. In: Männer, R.; Manderick,
B. (eds.): Parallel Problem Solving from Nature, Proceedings of the Second Conference
on PPSN, Brussels, Sep. 28-30. North-Holland, Amsterdam: 321-329
[14] Michalewicz, Z. (1992): Genetic Algorithms + Data Structures = Evolution Programs.
Springer, Berlin
[15] Werra, D. de (1985): An Introduction to Timetabling. European Journal of Operational
Research 19: 151-162