next up previous contents
Next: Experimental Results Up: Case Studies Previous: Spring 2000, versions v0.90   Contents


Fall 2000, versions v1.04 - v1.15

The Dorm_View GUI and the automatic upgrading capability were in place. For the first time, Ranville had the tools to make manual assignments with more complete knowledge of the consequences of each move. The FINAL_OCC attribute added to HMS provides her the means to effortlessly identify who can be moved. Dorm_View supports this working model of manual upgrades by providing detailed results in terms of the objective function before the changes are committed.

Ranville remarked how quickly she was able to modify the initial results of the DAO with Dorm_View (Figure 4.1) -- she made 38 changes in a few hours. She used the blocked/unblocked room lens, and the final/moveable/new/moved student lens. Gliding over the rooms with the mouse she could also see the gender of the room. She chose to view all the dorms in one window to facilitate the Find Student function, and the waiting list in a separate window. The scrolling messages documented the moves she made so she could regain state between interruptions.

After two weeks, Ranville had improved the overall results since her first post-DAO attempts, giving 82 additional students one of their three requested hall choices. Analyzing her changes, it appears the first_timer and mixed_study_late constraints could have been smaller, and the better_bed constraint used. Keeping in mind that it is easier to modify a few bad bed assignments than to change coefficients that have a global impact, the output will occasionally require the human touch to break the rules.

We learned a critical lesson with these first few manual upgrades: Students moved to different beds in the same hall also had to be `de-bedded', otherwise HMS would search for another place if the suggested bed is occupied. The de-bedding process took eleven key strokes per student in HMS, so too many beds changes would make auto-upgrading unusable in the current environment.[*]

Subsequent test runs produced over 650 same hall bed changes to improve 25 hall assignments; we do not know how many were necessary or just because there was no reason not to. In version v1.12, we gave it a reason slightly less dramatic than never accepting a lateral move -- the different_bed constraint, designed to delicately tag moving bed positions in the same hall. Same hall bed changes dropped by a factor of six in test runs.

With only a few cancellations automatic upgrading was not used this semester. A smaller resident population and more group matches was credited for the small number of cancellations. Though the automatic upgrading feature and the different_bed constraint were not tried, Ranville found power in the interactive Dorm_View tool to upgrade students manually, faster and better.[*]

Three subsequent DAO runs placed 100, 90, and 69 more new students -- only 16.4% of the 1,578 students in the initial run. These runs were made with the more desireable dorms blocked, forcing the system to place the late-comers into the unpopular dorms. This legacy blocking practice provides control and is well-understood.

At the end of August, based on 1715 residents, the results showed: A total score of 100,417,531 with 94.0% satisfaction, and 829 students with perfect grades.

Figure 4.1: Dorm_View Screenshot
\includegraphics[scale=.75, angle=270, clip=true]{images/screenshot2.eps}


next up previous contents
Next: Experimental Results Up: Case Studies Previous: Spring 2000, versions v0.90   Contents
elena s ackley 2002-01-20
download thesis