PrevUpHome

Activity Configuration Fine Points

If a course load contains half courses that run in both terms, the choice of taking these courses in one term or the other gives rise to multiple activity configurations. Each activity configuration has its own set of possible timetables. Therefore, after selecting the courses that make up the course load, and before generating timetables for this course load, one must specify for which activity configuration(s) should timetables be generated. This specifying can be done in a number of ways.

The simplest case is when there are no half courses that run in both terms, so that only one activity configuration is possible. In this case, SelectCourses() automatically selects that one configuration, and one can go on straight to GenerateTimetables().

The next simplest case is when there are multiple activity configurations, but only one of them is desired. In this case, after calling SelectCourses(), one should call SpecifyTerm() to specify, for each half course that is offered in both terms, which term it should be taken in. Then a call to GenerateConfigurations() will generate the single activity configuration that satisfies the constraint imposed by the calls to SpecifyTerm() and auto-select it, and one is once again ready to call GenerateTimetables().

The above two use cases should be sufficient for many (maybe even most) API clients.

If generating timetables for multiple activity configurations is desired, the desired activity configurations need to be specified using some combination of SpecifyTerm() and SelectConfigurations(). The general workflow is to:

  1. Make 0 or more calls to SpecifyTerm() to specify that a certain course must be taken in a certain semester.
  2. Call GenerateConfigurations(). If the calls to SpecifyTerm() unambiguously specify the desired set of activity configurations (that is, given the calls to SpecifyTerm() that were made, only one set of possible activity configurations could have been intended), these activity configurations are auto-selected and one can go on to call GenerateTimetables().
  3. Otherwise, call SelectConfigurations() to select a subset of the generated configurations before calling GenerateTimetables().

An important assumption that is made is that when specifying the set of desired activity configurations, whatever information can be specified using SpecifyTerm(), is specified using SpecifyTerm() rather than using SelectConfigurations(). The rationale for this is that the calls, or absence of calls, to SpecifyTerm() model a user's three-way choice for each half course that runs in both terms: take it in the Fall Term, take it in the Spring Term, or take it in either term. The choices "take it in the Fall Term" or "take it in the Spring Term" are communicated by making the appropriate call to SpecifyTerm() for that course. The choice "take it in either term" is communicated by not calling SpecifyTerm() for that course. Many sets of desired activity configurations can be specified entirely by making these three-way choices for each half course that is offered in both terms. In such cases, the best workflow is to make the appropriate calls to SpecifyTerm(), call GenerateConfigurations(), and then select all of the generated configurations via SelectConfigurations() (if they weren't already auto-selected by GenerateConfigurations()).

The ability to use SelectConfigurations() to select a subset of the configurations generated by GenerateConfigurations() is meant to give a little more expressive power for cases where calls to SpecifyTerm() cannot completely specify the set of desired activity configurations. For example, suppose the course load includes four half-courses that are offered in both terms: CSC148H1, CSC165H1, CHM138H1, and CHM139H1. Suppose the user is open to taking any of these courses in either term, but the Chemistry Department imposes the restriction that CHM138H1 and CHM139H1 cannot be taken in the same term. This restriction cannot be expressed by any combination of calls to SpecifyTerm() without also taking away choices from the user that are not excluded by this restriction. In cases like this, an API client can resort to calling GenerateConfigurations() without making any calls to SpecifyTerm(), and then calling SelectConfigurations() to select precisely the configurations that satisfy the restriction.

Finally, a note about the set of activity configurations generated by GenerateConfigurations(). This function does not generate all possible activity configurations, only ones that are balanced between the two terms, whenever that is possible. An activity configuration is considered balanced if the number of courses taken in either term is the same (or, if the total number of courses taken is odd (counting a full-year course once for each term), if the number of courses taken in the two terms differs only by 1). A course load is considered balanceable if it has one or more balanced activity configurations. For a balanceable course load, GenerateConfigurations() will only generate the balanced configurations. For a non-balanceable course load, GenerateConfigurations() will generate the single configuration that brings the course load the closest to being balanced (that is, it places all half-courses that run in both terms, into the term that has the fewer courses). If calls to SpecifyTerm() had been made prior to calling GenerateConfigurations(), GenerateConfigurations() will pretend that the courses for which SpecifyTerm() was called only run in one term (the term that was specified in the call to SpecifyTerm()).

This behaviour regarding generating only balanced configurations whenever possible means that there is no way to use GenerateConfigurations() to generate multiple activity configurations if one of them is not balanced. If this is desired, an API SetConfigurations() is provided (to be called instead of SpecifyTerm() and GenerateConfigurations()) which allows specifying precisely the set of desired activity configurations.


PrevUpHome