Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

A Constraint Processing Approach to Assigning Graduate Teaching Assistants to Courses | NRES 476, Papers of Zoology

Material Type: Paper; Class: Mammalogy; Subject: Natural Resources ; University: University of Nebraska - Lincoln; Term: Unknown 2001;

Typology: Papers

Pre 2010

Uploaded on 08/30/2009

koofers-user-6fu-1
koofers-user-6fu-1 🇺🇸

10 documents

1 / 27

Toggle sidebar

Related documents


Partial preview of the text

Download A Constraint Processing Approach to Assigning Graduate Teaching Assistants to Courses | NRES 476 and more Papers Zoology in PDF only on Docsity! A Constraint Processing Approach to Assigning Graduate Teaching Assistants to Courses Robert Glaubius Honors Thesis Constraint Systems Laboratory Department of Computer Science and Engineering University of Nebraska-Lincoln glaubius@cse.unl.edu December 23, 2001 Abstract In recent years, scheduling problems have been advantageously modeled as Constraint Satisfaction Problems (CSPs) and effectively solved by constraint propagation and processing techniques. In this document, we discuss one such application: the assignment of graduate teaching assistants (GTAs) to courses as instructors or grading assistants in a university setting. We analyze and model this problem in the real-world setting of the Department of Computer Science and Engineering of the University of Nebraska-Lincoln. This problem has traditionally been over-constrained. The results of our investiga- tions are as follows. We enrich the definition of the problem by including students’ own preferences to be assigned to courses. We propose, implement, and evaluate a representational model of the enti- ties and constraints that constitute this problem, and explain how the current model has emerged from, and improves upon, a series of modeling attempts. We also propose, implement, and test various op- timization criteria that model ’satisfactory’ solutions. Finally, we describe, implement and test various computational mechanisms for solving this problem such as ordering heuristics, constraint propagation mechanisms, and search mechanisms. 1 Contents 1 Introduction 2 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Data Collection 5 2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Refining data collection: preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Modeling 7 3.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Optimization objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 Previous models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.1 Binary model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.2 Initial non-binary model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4 Processing 15 4.1 Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Solution techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5 Implementation 18 6 Experiments 19 6.1 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2 Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7 Conclusions and future research 21 7.1 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2 Ideas for reformulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1 Figure 1: Map of the United States of America. Each of these variables has the set of colors {red, blue, green, gold, orange} as its domain. For example: DNM = {red, blue, green, gold, orange} (2) The constraints in the problem specify that no two adjacent states can have the same color. For example, there would be a binary constraint between GA and AL : CGA,AL = {((GA,x), (AL, y)) | (x ∈ DGA) ∧ (y ∈ DAL)(∧x 6= y)} (3) We also model each of the restrictions listed above as a constraint. The first and second ones are unary constraints: CNE = {(NE, red)} (4) CFL = {(FL, green), (FL, orange)} (5) The last is a ternary constraint: CNE,CA,OR = {((NE,x), (CA, y), (OR, z)) | (x = gold ∧ y 6= gold ∧ z 6= gold) ∨ (6) (x 6= gold ∧ y = gold ∧ z 6= gold) ∨ (x 6= gold ∧ y 6= gold ∧ z = gold)} 4 1.2 Overview This document is structured as follows. In Section 2, we discuss the data collection process. In particular, we identify the attributes of courses and graduate teaching assistants that need to be specified for the task of assigning GTAs to courses. In Section 3, we report on our strategies for modeling GTAs, courses, and the constraints that dictate under what conditions we were able to assign a given GTA to a particular course. In Section 4, we discuss the constraint processing techniques we have considered for solving this problem. Section 5 describes our current implementation. Section 6 presents and discusses the results of our experi- ments on two data sets pertaining to the academic semesters Spring 2001 and Fall 2001. Finally, Section 7 concludes this documents and draws directions for future research. 2 Data Collection In this section, we discuss our methods for data collection. This includes the methods in place when we began our study, our modifications to this process, as well as a description of the collected data. The type of data collected heavily impacts the types of relationships we can model. For a parallel, in the map coloring example earlier, if we were given the name of the states to be colored, but not their relative locations and borders, it would not be possible to model the problem in a meaningful fashion. By this same token, without acquiring key data for our problem, it is impractical to attempt to solve a model of the problem, as it will bear little or no resemblance to the actual problem seen in practice. 2.1 Background Previous to our study, when a graduate student applies for a teaching assistantship (TAship) in the Depart- ment of Computer Science and Engineering (CSE) at the University of Nebraska-Lincoln (UNL), he or she is asked to submit information about his or her academic history. The department has designed paper forms that the students fill to provide this information. A sample form is included as an appendix to this paper. Once assistantships are awarded, the information submitted by each graduate teaching assistant (GTA) is then used, in addition to other information such as ITA certification status and previous TA experience. This data is then used to determine the courses that the student may potentially be assigned to. Further, depending upon the availability of funds or their involvement in research projects, graduate stu- dents may receive one of two types of teaching assistantships. These are half or full teaching assistantships. 5 Typically, GTAs that receive a half TAship are assigned to fewer or smaller courses, while students with full TAships receive a more demanding workload. With the above information in hand, faculty and administration members then proceed to manually assign the GTAs to scheduled courses. Typically this procedure results in barely satisfactory assignments. GTAs frequently have time conflicts with courses that they are assigned to and requiring their physical attendance. Sometimes, they are inadequately prepared for the material of their assigned courses. These conflicts are sometimes detected and GTAs are swapped between courses or brought up to speed. The detection and correction of these conflicts result in frustration and a loss of time and effort for for the students enrolled in the classes, the GTAs, the teaching faculty, and the administrators. Our goal in automating this task is to reduce the quantity and magnitude of conflicts observed in prac- tice, while proposing solutions that better satisfy the involved parties – the faculty, students, and the GTAs themselves. At the time that we began this project, the information listed was collected by the department for each GTA. The majority of these items are briefly mentioned here. • Enrollment status: A list of courses that a GTA is enrolled in. • ITA Certification: A boolean value that indicates whether an international student has or has not passed the International Teaching Assistant Evaluation. • Half/Full TAship: Indicates whether a GTA is employed full-time or half-time. • Faculty advisor: The GTA’s individual advisor. • Course deficiencies: Courses required for completion of the graduate program that have yet to be taken. • Past TA experience: A list of courses that the GTA has been assigned to in previous semesters. • Grade point average (GPA): An indicator of scholastic aptitude. Of the above, a GTAs advisor, deficiencies, experience, and GPA are not taken into account in the current version of the problem model. The rest of these attributes are discussed in Section 3. 2.2 Refining data collection: preferences We observed that the data collected by the department from the students thus far is actually sufficient to avoid conflicting decisions such as the ones mentioned above. Consequently, it is quite realistic to implement an 6 represented by two variables. Similarly, classes with load of 0 do not have a variable representation. Typi- cally a given semester in CSE has around 70 variables; for example, the Fall 2001 semester is modeled with 66 variables. 3.2 Domains The domain of a CSP variable is the set of values that can be assigned to it. In our model, each value is a graduate teaching assistant. Initially, the domain of each variable consists of the pool of all available GTAs. Each GTA has a number of relevant attributes that should be checked before including him or her in the domain of a variable. These include the following: • Enrollment: The enrollment status is a list of courses that a GTA indicates he or she will enroll in during the semester in question. It serves two purposes in our model. First, it is used to determine when a given GTA is not available as an instructor. Second, it is used to prevent a student from being assigned as either a grader or instructor to a course that he or she is actually enrolled in. • ITA Certification: International students constitute the majority of our pool of GTAs. Due to various considerations, it is required for these students to acquire International Teaching Association (ITA) certification prior to assignment as instructors for courses. Incoming international students are usually not ITA certified. This procedure may take a semester or two before an incoming international student becomes ITA certified; in the meanwhile, he or she can be assigned only as a grading assistant. For instance, during the Fall 2001 semester, 14 out of all 34 GTAs hired required but did not possess ITA certification. • Half/Full TAship: As mentioned in Section 2.1, graduate students may receive either a half or full TAship. Typically, it is desirable to rely more directly on GTAs with full teaching assistantships. In practice, a GTA with a half-TAship will be assigned courses with the sum of their loads equal to 1, while a GTA with a half-TAship is assigned a to courses with a load total of 0.5. • Preferences: Preferences, as discussed in Section 2.2, are integer values ranging from 0 to 5 associated with each class for a given GTA. These are used in the optimization criterion that discriminates among consistent solutions. Each of these attributes is taken into account before assigning a GTA to a given course. The values of these attributes are checked by the constraints, which we will discuss next. 9 3.3 Constraints There are several different types of constraints considered when assigning a GTA to a course. This system uses unary (arity = 1), binary (arity = 2), and n-ary constraints to represent the variety of relations that dictate valid instantiations. Several of these constraints were hinted at in previous sections; all constraints that we model are covered in detail here. The unary constraints are: • ITA certification - As touched on in Section 3.2, international students are required to be ITA certified prior to instructing any courses. The ITA certification constraint is a unary constraint that enforces this condition upon any variable that requires a GTA as an instructor. • Enrollment - The enrollment constraint is a unary constraint that prevents GTAs from being assigned to courses that they are taking. Clearly it would be disadvantageous to allow a student to grade his or her own work! • Overlap - Overlap constraints prevent any GTA from being assigned as an instructor to a course that he or she cannot attend. This is based on the GTAs enrollment status, using the meeting times of courses he or she is enrolled in to indicate when he or she is unavailable. • Zero Preference - Zero preference constraints prevent any GTA from being assigned to a course for which he or she has indicated preference value zero. This constraint serves to restrict attention only to those GTAs that have some desire (or little objection) to instructing or grading for a given course. There is only one type of binary constraint used in this model: • Mutex - Mutex constraints3 are binary constraints in place between any two courses that require GTAs as instructors and meet during overlapping times. This enforces the condition that a GTA must attend courses he or she is instructing. We choose to use non-binary constraints to model the capacity restrictions and containment situations observed in practice. While the majority of processing techniques in CSPs have focussed on binary con- straints and relied on reformulation techniques for mapping [1] non-binary formulations into binary ones, it is commonly acknowledged that the representation should remain as faithful to the real-world constraint (i.e., a capacity constraint should be represented as a non-binary constraint) and the processing should use the encoding that is most likely to yield efficient processing. Few investigations have been carried out to 3a.k.a. constraints of difference, or coloring constraints. 10 establish the superiority of a binary versus a non-binary formulation with respect to the efficiency of the processing technique. This is a new research area and no definite conclusions exist yet. We implement 3 types of high arity constraints: • Equality - Equality constraints are n-ary constraints between a set of courses, all of which should be assigned the same GTA. • Capacity - Capacity constraints are n-ary constraints that prevent any GTA g from being assigned more than some maximum load maxg. This is enforced by restricting g’s current load currg ≤ maxg, where currg is the sum of the load of all courses that g has been assigned to. • Containment - Containment constraints are n-ary constraints, similar in spirit to the aforementioned mutex constraint. In general, a number of lab and recitation courses may be associated with a given lecture course; for instance, the lecture course “Introduction to Computer Science I”, section 1, has had as many as five associated labs. It is desirable that GTAs assigned to instruct one of these labs not be assigned to any other course, unless it is another lab associated with this same lecture section. Containment constraints enforce this condition. Since a GTA can be assigned to multiple courses, containment constraints enforce assignments of a specific GTA to a subset of labs or recitations asso- ciated to a same lecture section after he or she has been assigned to any one of these sections. In addition to our stated goals – to find good solutions that cover many courses while optimizing solution preference – we have two other goals in mind while modeling this problem. First, we wish to obtain solutions that match the criteria used in practice. Secondly, we want to produce a model that does not force model processing to be too complex. The introduction of many complex constraints can often increase the amount of effort that is expended in finding a solution. We intend our model to be descriptive, yet practical. In order to do this, we feel that non-binary constraints are the most effective technique for modeling these complex criteria, such as capacity and containment constraints. While the superiority of non-binary over binary representations is still an open question Bacchus:98, the non-binary approach allows an intuitive approach to handling these constraints. The capacity and containment constraints, in particular, are very loose, highly disjunctive constraints, and as such, typical methods for translating binary problems into non- binary ones can become expensive using either an intensive or extensive constraint definition. An initial approach to our problem, that utilized only unary and binary constraints is discussed in Section 3.5. 11 3.5 Previous models Our model is the result of several prior attempts. While the variables, domains, and optimization criteria have remained fairly unchanged, the constraints have undergone several modifications. The past models can be broken up into two distinct precursors – an initial model with binary constraints, and a previous model using non-binary constraints. Examination of these two models will yield some insight into the design decisions and problems we faced in representing the GTA assignment problem. 3.5.1 Binary model Early in this project we tried to model this problem using only unary and binary constraints, in order to take better advantage of and build off of existing research. All of the unary and binary constraints in this early model we still utilize in the current model. Containment constraints and equality constraints were not modeled. Capacity constraints were simulated by replacing the current k-ary constraint with a fully- connected graph of mutex constraints between all k variables in the simulated capacity constraint’s scope. This solves the problem of preventing GTAs from being overloaded; however, it restricts GTAs to at most one assignment. As a workaround, GTAs were then replicated, allowing each GTA to be assigned to a maximum of two courses. This replication strategy increased the size of the CSP substantially. For a given CSP with n = |V| and d = |D|, the size, or number of possible solutions of a CSP is dn. Methods for solving CSPs rely on navigating this search space in order to find a solution; by uniformly doubling domain size, we increase the size of the solution space by a factor of 2n, with a direct impact on run-time and effectiveness of search. This size problem was the primary motivation for moving to our second, non-binary model. 3.5.2 Initial non-binary model In the second model, we eliminated the fully-connected mutex networks and replaced them with a non- binary capacity constraint. In addition to maintaining the solution space to dn size, this also allows a degree of flexibility in specifying workload. Capacity constraints can be given a parameter, maximum capacity, that sets a cutoff limit to the amount of load GTAs can be assigned. While we have only utilized capacity constraints with a maximum capacity of two load units for full GTAs, it is possible to configure this maximum to allow GTAs to take larger loads when an insufficient number of GTAs is available, or it can be lowered if there is a surplus of GTAs. The difference between this non-binary model and the model in use is the inclusion of the equality 14 constraint, and the containment constraint. The addition of these two constraints was motivated by a desire for increased accuracy in fitting to new department strategies. 4 Processing Generally, problem instances involve around 70 courses and 35 GTAs. Courses tend to have an expected load of about 1 unit, though many have less, and few have load of more than 1. Due to this and many of the constraints on the problem, it is expected that many problem instances will be unsatisfiable. However, it is essential that we find some partial solution in the absence of any global solutions. For this reason, the assignment of the empty value φ to a a variable Vi is considered consistent with any constraint Ci,j,...,m such that Vi ∈ Scope(Ci,j,...,m). In other words, this system necessarily will consider an instantiation to be consistent even when some courses are not assigned GTAs. We focus our research on the use of systematic techniques for solving CSPs. These methods are based on a systematic, depth-first search of the solution space. We select these methods for their soundness and completeness. Other solution techniques, such as local search, are powerful methods, but lack completeness. As this project presents proof-of-concept, we desire the guarantee to find a consistent global solution, when one exists. In addition to the solution methods mentioned above, we’ve experimented with various methods for constraint propagation. These methods attempt to reduce the effort of search by eliminating domain elements in a variable’s domain if they are found to be inconsistent with the constraints. For example, enforcement of node consistency is used to propagate the effects of unary constraints prior to search. For instance, if GTA Winston Smith is enrolled Information Retrieval, he will be removed from Information Retrieval’s domain when node consistency is enforced due to the enrollment constraint that is in place on the course. In this section, we will first examine some of the propagation methods we have experimented with, and then discuss the solution methods that we have implemented. 4.1 Propagation The most basic propagation algorithm is node consistency (NC). Node consistency is enforced by examining each value a in the domain of each variable Vi. If a is not consistent with some unary constraint C defined on Vi, a is removed from the domain of Vi. This simple algorithm tends to yield a significant reduction to the size of GTA assignment problems, increasing the speed of finding a solution. In Section 3.5.1, we referred to an earlier model that represented the capacity constraint as a network 15 of mutex constraints. It is worth mentioning here some of our findings in using the arc-consistency propa- gation method for mutex constraints proposed by Régin [10]. This filtering algorithm is based on finding a variable-to-value maximal matching in a fully-connected network of mutex constraints. The network of variables is first transformed into a bipartite graph, with one set of nodes representing variables and the other representing values. Edges between these sets tie each variable to the values in its domain. A matching in this graph is a set of edges such that each variable is associated with a unique value 4. Independent of all other constraints besides the mutices, this matching represents a solution to this set of variables. However, due to the presence of other constraints, Régin’s algorithm then uses this initial matching to find all possible matchings. For each value in the graph, if it is not incident upon an edge in any matching, it can be filtered from the problem, as it cannot be included in any global solution. This algorithm proves useful when we are searching specifically for a global consistent solution. How- ever, since we do not focus on finding a global solution (due to the fact that in many cases they do not exist), this algorithm was not often particularly useful. Once the problem model evolved away from the binary model, and large networks of mutex constraints were replaced by capacity constraints, this algorithm was removed from the solver system. Node consistency and Régin’s mutex filtering algorithm are the two stand-alone constraint propagation algorithms that we’ve implemented and used in this system. Other methods for constraint propagation that we have tested are forward-checking [6], and forward-checking for non-binary constraints [2]. These methods are used during search; they will be covered in the next section. 4.2 Solution techniques We utilize systematic search techniques based on depth-first search to solve the GTA assignment problem. In order to cope with the problem size, we include some look-ahead strategies when searching. Earlier models have used standard forward-checking to propagate the effect of past assignments; the current implementation uses a form of forward-checking for non-binary constraints. Branch-and-bound mechanisms are another feature integrated into our search strategy. Forward checking (FC) is perhaps best described by Prosser in [9]. This is a strategy used in CSPs con- taining only unary and binary constraints. Each time an assignment is made, all future variables (variables that have not yet been assigned at the current point in search) have values removed from their domains if these values are not consistent with the new assignment. Alterations to the model that involved the inclusion of non-binary constraints forced a change in the 4The algorithm used to compute this matching is attributed to Hopcroft and Karp [8]. 16 reductions list acts as a stack of values filtered from the domain (See [9] for a more in-depth discussion of each of these structures). There are a wide variety of constraint objects in our system. We use an extensive enumeration of valid tuples for the unary constraints, while using an intensive enumeration of the valid tuples for constraints with arity ≥ 1. Extensively defined constraints use a list to store acceptable tuples, and have a generic associated consistency check method. Each intensively-defined constraint uses a specialized consistency check method. This could be remedied by storing a constraint predicate as a member of the constraint object. 6 Experiments 6.1 Data We studied and experimented with two sets of data obtained from the CSE department. These sets pertained to the Spring and Fall 2001 semesters. GTA half and full TAships and course loads were not defined in our data for Spring 2001. In our tests, we used the default of full TAship, and a default course load of 0.5. Preferences were not provided for the entire Fall 2001 data; in this case we artificially enforced a default preference value of 3 for GTAs who did not report preferences. 20 GTAs did not report preferences in this data set. Spring 2001 Fall 2001 GTAs 25 34 Lectures 40 44 Labs 24 24 Recitations 3 3 Half-semester 6 7 Table 2: Description of test data 6.2 Experiment Design We tested our system’s performance on these two data sets using 8 tests per data set. Each test involved one of the two possible evaluation functions, maximizing the minimum or the geometric mean. Values were ordered according to one of two value ordering heuristics, and variables were ordered according to one of two variable ordering heuristics. These heuristics are described briefly below. We implemented static value ordering heuristics; the first ordered all values by sorting according to preference such that values with high preference would be considered first. The second heuristic considered 19 values that occurred in the fewest domains before those that occurred in many. Ties were broken according to preference, with higher preferences considered first. These heuristics were used in conjunction with either least-domain variable ordering, or domain-degree ratio ordering. Least domain variable ordering considers first the variable with smallest domain, while domain-degree ratio ordering chooses the variable that has the smallest ratio |domain||degree| , where degree is the number of constraints on the variable. Each test was run for approximately one hour. We report here the best solution found during that time by each test. Table 3 shows these results in terms of constraint checks, nodes visited, CPU time, and solution quality in terms of solution size and the two evaluation criteria. Preferences Test CC NNV Time Size GM 1 2 3 4 5 Spring 2001 GM-DP-LD 167301144 219282 3454900 49 3.7717085 5 1 6 8 29 GM-DP-DD 295782625 87074 2943150 51 3.8908036 3 5 4 6 33 GM-MIN-LD 72185616 51698 1288900 49 2.2945633 16 7 10 4 12 GM-MIN-DD 9889354 4853 155170 52 2.8628445 11 4 11 9 17 MM-DP-LD 166043703 212144 3444040 49 3.7717085 5 1 6 8 29 MM-DP-DD 193803188 50099 1901350 51 3.8908036 3 5 4 6 33 MM-MIN-LD 71184570 50068 1277380 49 2.2945633 16 7 10 4 12 MM-MIN-DD 9176961 3668 124400 52 2.8628445 11 4 11 9 17 Fall 2001 GM-DP-LD 5886422 112 32690 56 3.167192 7 0 28 0 21 GM-DP-DD 3249132 51 18820 40 3.8350053 1 0 15 6 18 GM-MIN-LD 7094746 1764 65880 51 2.8961947 8 0 28 3 12 GM-MIN-DD 5249870 123 27100 48 2.976746 4 3 29 4 8 MM-DP-LD 5886422 106 31680 56 3.167192 7 0 28 0 21 MM-DP-DD 3249132 51 19340 40 3.8350053 1 0 15 6 18 MM-MIN-LD 6978914 1448 53970 51 2.8961947 8 0 28 3 12 MM-MIN-DD 97282099 51256 1640270 48 3.0200438 3 4 29 4 8 Table 3: Best solution found during one hour interval for each test; each test is described by GM (geometric mean) or MM (maximize minimum) evaluation, DP (preference ordered) or MIN (value that occurs in fewest domain) value ordering, and LD (Least-domain) or DD (domain degree ratio) variable ordering. Categories are CC (constraint checks), NNV (number of nodes visited), CPU time (10ms resolution), GM (geometric mean) and the number of occurrences of each preference. When viewing the results in table 3, it is important to keep in mind how constraint checks are counted. In the binary case, it is typical to count each constraint check once. However, in the non-binary case, a single count is not likely to be indicative of the amount of work performed. For this reason, every constraint check increments the total number of checks according to the arity of the constraint. For example, checking a 57-ary capacity constraint increases the number of constraint checks by 57. 20 Our tests indicate that the geometric mean and maximization of minimum preference evaluation func- tions lead to the same result in most cases. The only exception to this are the GM-MIN-DD and MM-MIN- DD tests. In these tests, the maximization of minimum preferences (MM) evaluation function seems to find these similar solutions with slightly less effort, in terms of node expansion, constraint checks, and CPU time than does the Geometric mean function. Maximizing the minimum was likely able to backtrack earlier, as some path was discarded more quickly under this strategy than it was using maximization of the geometric mean. This allowed the MM test to improve its solution at least one more time before the time limit was reached. No single variable-value ordering combination appears to dominate in these tests. It appears that the effectiveness of each combination varies strongly between these two test sets. Since variable/value ordering heuristics seem to have a strong effect on the performance of our system, experiments with more powerful orderings is likely to be beneficial. 7 Conclusions and future research We have shown that it is feasible to use CSPs to model and solve this problem using this approach. There are several apparent improvements that can be made to the system, that we briefly discuss in this section. This system has been used in practice at the time of this writing, with satisfactory results. We were able to reduce the amount of time spent on this task by a large interval. In practice, scheduling GTAs often would take four or five days before a satisfactory solution was found, as GTAs were shuffled between courses. We were able to generate solutions that reduced the time spent to one day. We intend to further reduce this over the course of further work on this project. 7.1 Future research There are many possible approaches that may improve the run time performance and accuracy of our system. Below are some of the techniques we intend to employ in future research on this task. • Aggregation and Reformulation - We expect that the implementation of the methods discussed in section 7.2 will improve the performance of this system. • Parallelization - The implementation of parallel solvers presents an interesting approach to CSPs in general. We intend to explore the usefulness of asynchronous methods (as described in [11] and [3]), as well as the potential for using decomposition strategies in conjunction with parallel programming. 21 [10] Jean-Charles Régin. A filtering algorithm for constraints of difference in constraint satisfaction prob- lems. In AAAI94P, pages 362–437, AAAI94L, 1994. [11] Makoto Yokoo and Katsutoshi Hirayama. Algorithms for distributed constraint satisfaction: A review. Autonomous Agents and Multi-Agent Systems, 3(2):185–207, 2000. 24 Figure 2: GTA data collection sheet SURVEY ON SPRING 2001 ASSISTANTSHIP (Complete both sides and return to Marilyn Augustyn, by Menday, January 29, 2001) INCOMPLETE FORMS WILL BE SUBJECT TO PENALTY! Name Advisor: Degree program: [] M.S. (thesis) [7] M.S. (project) [] PhD. Semester admitted Expected graduation date # Years supported by CSE Undergraduate GPA (if available): Graduate GPA: Icurrently [] have [] donothave a teaching assistantship in the CSE Dept. My current assistantship is in the amount of §, (per semester) Last 2 teaching assignments: Course Semester Instructor Deficiencies still to be taken: GRE: Oo General C1 Subject Verbal % Area Quantitative % Score % Analytical % Numbcr of talks attcnded in the past year: Colloquia O Ph.D. oral Oo MS. oral Oo Foreign students only SPEAK test: Date. Score ITA (Institute for International Teaching Assistants): Date passed Date failed Did not attend (over) 25 Figure 3: GTA preference collection sheet NAMI SPRING 2001-'TA Preferences Courses you Test inflate yor rcerencen are aking m .) makiug all eounes between O and $ Come Comsch Sec. tome Day Spring 2001 | (indiowing high pesence) Computer Science Fundamentals ino) om000I5P_ 4k ‘Conpute Sieuoe Fudamenals Lab TORE go!” 1936-1220" R Computer Seienos Fendamentas a ofl voz 01300500r —_W Compute Scenes Fondant Lab Joi 03 _Os004r30P Tipo to Computer Programming Ee 1501s) 1930-0120" “Me 150 ‘ooo 190 a30-09208 M1 15 tasciso0a WP 155 1930-10208 155 (o30.10268 135 10-1220 —__-W { 155 1130-12206 Me | 155, owe MW Ft 135 caanoona Ww tah 1 1036.11208_¥4 tah 1s 1236-01208 x Tne Comp Seb 1S 1s ooo MW La i000 E Tse Comp Sei eso.12en Mw _ La ORIG O82O 1 Lab 2 a630.1080A We Lab 136.1220" F ak 23060820" Mt Inge Comp Sef HB01QUAM WP as 1200-0250P z my 1130:6320"" ME Computer Ongsieuion cnoone WF Compunsr Orgnieaion Lab 083010208 z Campatr Organiraion Lab (0830-10208 F ‘Computer Crganizon Lab ios0-1220 1 cmon MWe | anes ‘Computer Uiganizaon ‘Camprter Organization Tab Honars Tho 9 Hissrve Srmcmrce MWe ea ‘50-0020 E esi oui Ww. Resi OOM Ww _ 0830-0920 T OR 1 0530-09208 TR C Programining 3/14/2600) UNIX Progrunung V-272772001 TINT Programming W16.27280001 ooo WF TENE Proprmming 152072001 3510953 Mo.cwso_T Tendon H2-AZTIODL 2siy051_olsoanaur WF Kaine 324/200) Bey 95) _100.08807 7 Cou Pogransning saa gol _Oss0-05mP _W Fare Proazi 2520 wi 0430.0saar Mh i avs Soe. Algoiime 310 wn onsonom mw WP | umerea! Analyst OEE og) MONI? TP Human. Comparer interaction 25 oo) 100M M WF __ ‘eign and Analy of Algondins cD og) NODS TE “Compile: Coverruetion| 25/025: OOP Mw OF (| Conus Aue 39551 00) C30-TI90A MW VLSI Deyo 534 1 Ono.cnme WF ‘psctng Sypeams Prncigles SIA wo moo TE Distibwed Operating Sens A55R55 yi IOI WF Sofie Eagan a6i/S61 601 _Oe201089A TR ‘Comm. Neswarks McQ 00) 0550-0? MW I Sufwage Des Mesias AGS oop Vid TE t Compute: Geiss 70870 yo: _ooocaIs TR Too Aten! Tigme HOA coi MOA WF Compute Beginsering Pol De eon) Oho 1ta_W Cempucr Eng Senor Design Comme ___ 4850 _0530-1000a WWF Spee Tye lered Computing 20S god O30. GKRP MW FE Masters Projet Sofa Design 3009 MODIS TE ‘Adv Tope 9 Danhae Systems yoo) 130-018 TR | Soph Algor 74 oot mone TR ‘hy Compe Srchtenie 0 oo WADIA M WF Mich Theory af Fate Amore 355 qo! usocnzor WF ate Recognition sre co) I MW Generic Alas 4 co: nommanr vw | 7 Sens Ouial Can Nese so ew: OTSA ‘Seiuiuat-Network Systems 390 ons HOMSTSCA > van0e 26
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved