Timetable Clashes
Determining which classes are clashing is a three step process:
Collect all clashing classes into one array with
checkClashes
Sort clashes by time and day with
sortClashesByTime
andsortClashesByDay
. Each day’s clashes is its own array.Group clashes into the final data structure with
groupClashes
as described below
The final data structure used to store clashes is a list of lists of lists. The first level of lists correspond to each day, e.g. groupedClashes[0]
are all the clashes for Monday. Within the array for each day, there are arrays corresponding to each clash group.
The way this array is constructed is:
The first class automatically goes to a new clash array in the corresponding day array
If the next class clashes, it joins that list, if it doesn't then it is added to a new clash group
For example, Monday:
clash 1: 9am - 12pm (consisted of 3 classes)
clash 2: 4pm - 7pm (consisted of 2 classes)
{
0: [ // monday
[class 1, class 2, class 3], // clash 1
[class 4, class 5], // clash 2
],
2: [], // tuesday
3: [], // wednesday
...
}
Next, for each class, its clashWidth
, clashIndex
and clashColour
are computed with getClashInfo
.
clashWidth
is the width of the card of a clashing class. It is found by dividing the default width of a card (100) with the number of clashes in its clash group.clashIndex
is the index of the card within its clash group so that the chronological order of the classes is maintained.clashColour
is the outline colour of the cards in the clash group.transparent
for not clashingorange
for permitted clashesred
for non-permitted clashes
Any class with just a lecture is a non-permitted clash. Non-permitted clashes include a tute + tute, tute + exam etc.
The complexity of this algorithm could be improved because it repeats the same calculation for each clash in a clash group. But it seems like a tradeoff between code simplicity and efficiency and I believe the former is more important.