Assigning Classes

Abigail abigail at
Tue Sep 10 11:35:11 BST 2013

On Tue, Sep 10, 2013 at 11:18:47AM +0100, Nicholas Clark wrote:
> On Tue, Sep 10, 2013 at 11:42:25AM +0200, Philippe Bruhat (BooK) wrote:
> > On Tue, Sep 10, 2013 at 11:24:10AM +0200, Abigail wrote:
> > > 
> > > There's also the lazy solution: randomly assign students to classes.
> > > Tell them they're allowed to make any change they want, provided
> > > that: 1) it gets a buy-in from any student involved in the change,
> > > and 2) no class exceeds the max capacity and no class has just one
> > > student.
> > 
> > I'd say it's more of a distributed solution, since the work is distributed
> > over the computing power of the students. It also has the nice benefit
> > that the more dissatisfied a student initialy is, the more computing
> > power they'll apply to improving the solution. Which should improve the
> > overall satisfaction.
> It might be impractical in this case. If the bandwidth and latency of the
> interconnects between the distributed nodes isn't good enough, then it may
> not be possible for the hive mind to find a solution before classes need to
> start.

And then they will be dissatisfied. That will give them an incentive to
not wait till the last night to optimize their schedule, and start sooner.
(It's just like writing slides the last night before giving a talk, once
you find out that it doesn't result in the best possible talk, you wise up,
and start sooner the next time. Oh, wait, that hasn't quite worked for me...)


More information about the mailing list