Este adevărat că în programul nostru, parcurgerea în ordine aleatorie a listei claselor este esenţială pentru obţinerea unui orar; totuşi, unele clase ar trebui să fie cumva favorizate – de exemplu, o clasă care are 4 ore ar fi de abordat înaintea celor cu 6 ore, fiindcă altfel, întâlnind-o mai spre sfârşit, cel mai adesea profesorii acelei clase ar avea deja ocupate primele 4 ore.

Anterior, obţineam în serie un număr destul de mare de orare (chiar şi 1000) pentru lecţiile unei zile – constatând astfel ce aşteptări putem avea de la programul respectiv, pentru diverse ordonări iniţiale a listei profesorilor (cam în cât timp s-ar genera un orar şi cam câte ferestre are acesta). Acum vom compacta cumva lucrurile (mai realist şi poate, „mai bine”), formulând un program care să producă un orar al lecţiilor zilei (ţinând seama de constatările făcute anterior).

Exprimam odată bănuiala că pentru o obţine orare cu „puţine” ferestre, ordinea profesorilor trebuie să corespundă cumva „cu aceea în care fiecare să aibă cât mai puţine clase în comun, cu cei care îl preced”; încercând să formalizăm această bănuială – asupra poziţionării fiecărui profesor în raport cu ceilalţi, condiţionată de prezenţa unor clase comune – ajungem la "betweenness" şi la cea mai bună strategie de exploatare a funcţiei noastre de generare a orarelor, mountHtoDay().

Cum depinde numărul de ferestre, de ordinea iniţială a profesorilor? Cazul când ordonăm după un anumit „grad” (empiric), eventual cu ordine arbitrară în cazurile de egalitate.

Faţă de [1], ne-a rămas încercarea (cam tulbure) de a investiga legăturile dintre orientarea iniţială a listei profesorilor, ordinea în care sunt abordate pe rând clasele şi numărul de ferestre de pe orarul obţinut; dacă am găsi ceva relevant, atunci vom putea şi să îmbunătăţim funcţia mountHtoDay() (prin care generăm orarele) sau măcar, ne vom da seama cum să o exploatăm cât mai bine, în situaţii concrete.