# Optimizing the Scheduling of Teaching Activities in a Faculty
## 7 Results
Running the algorithm for 12 h helped the solver assign lessons to classrooms and timeslots without violating any hard constraints, significantly enhancing the soft constraint score from 7629 to 8121. However, the extended runtime also increased medium constraint violations from 2102 to 2183, indicating that while the solution became more optimal regarding soft constraints, it struggled to minimize medium constraint violations effectively over the extended duration. The low medium constraint score can be related to the limited access to information from course lecturers, excluding those who teach seminars or laboratories. The assumption that these lecturers also teach the course, seminar, and laboratory was adopted. Despite imposing the constraint that a professor could not teach more than 12 h per day, the system recorded instances where a professor was allocated 13 or 14 h of lecture, resulting in scores of \(-1\) and \(-2\) accordingly. This also applies to student groups that are limited to 10 h of instruction per day. Furthermore, the implementation of the constraints considering teachers' preferences lacks precision. Instead of assigning estimated periods during which each teacher can teach, we assigned specific time slots. This leads to instances where a teacher is allocated to a time slot that he is unavailable for, despite being capable of teaching during that time without any difficulty. The performance on the MacBook Air M1 revealed that shorter runtimes resulted in higher unassigned counts and lower soft constraint scores. The algorithm possibly needs at least 16 h to achieve a feasible solution with all timeslots and rooms assigned, but even then, there is no guarantee that the medium constraints violation will decrease over time. This indicates that while the algorithm can assign more lessons over time, it reaches a point where additional runtime does not significantly improve medium or soft constraint scores. Using a configuration that assigned timeslots first resulted in hard and medium \begin{table}
\begin{tabular}{c c c c} \hline \hline \multirow{2}{*}{**Machine**} & \multirow{2}{*}{**Hours**} & \multirow{2}{*}{**Score**} & \multicolumn{2}{c}{**Score Calculation Speed**} \\ \hline M1 Air (I) & \(5\) & \(\begin{array}{c}-3122\) init/0 hard/ \\ \(-462\) medium/3417 soft \\ \end{array}\) & \(8703\)/s \\ \hline M1 Air (II) & \(8\) & \(\begin{array}{c}-1938\) init/0 hard/ \\ \(-798\) medium/5531 soft \\ \end{array}\) & \(6666\)/s \\ \hline M1 Air (III) & \(11\) & \(\begin{array}{c}-1102\) init/0 hard/ \\ \(-1246\) medium/6571 soft \\ \end{array}\) & \(5478\)/s \\ \hline M1 Air (alt. config) & \(8\) & \(\begin{array}{c}-10\) hard/ \(-5602\) medium/3361 soft \\ \end{array}\) & \(664\)/s \\ \hline M1 Pro (I) & \(8\) & \(\begin{array}{c}-262\) init/0 hard/ \\ \(-2113\) medium/7647 soft \\ \end{array}\) & \(8401\)/s \\ \hline M1 Pro (II) & \(12\) & \(\begin{array}{c}0\) hard/ \(-2183\) medium/8121 soft \\ \end{array}\) & \(6342\)/s \\ \hline Simulation (M1 Air) & \(6\) & \(\begin{array}{c}0\) hard/\(-1778\) medium/8265 soft \\ \end{array}\) & \(73\),\(135\)/s \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Comparative execution results on different machines. constraint violations, indicating a less effective approach for meeting all constraints. The higher medium constraint violations suggest that the initial assignment of timeslots without considering room assignments leads to suboptimal solutions. A Spring Boot REST API simulation on a MacBook Air M1 demonstrated that generating a feasible solution with instantiated objects in Java required only 6 h. This result suggests that, while the full-stack solution involving Angular and Spring Boot provides comprehensive functionality, the backend algorithm alone can operate more efficiently when separated from the additional overhead introduced by the web application context. The simulation began with an initial score of \(-8320\) init/0 hard/0 medium/0 soft.