Re: tabbie adjudicator allocation

[Klaas van Schelven]

On Nov 30, 2007 11:20 PM, Meir Maor <meir...@gmail.com> wrote:

I added a little check to make sure no adjudicator is allocated twice.

I also looked over the changes made to support variable size pannels,
I discovered the algorithm creates pannels with an even number of adjudicators,
I believe this should be avoided, pannels of strength 3 and 5 are to
br prefered over pannels of 3 and 4 adjudicators.

I don't know - I can imagine arguments for both scenarios.... maybe we should make both configurable...

Also I noticed that the feature allowing to rerun the simulated annealing
is problematic since every time you re run the simulated anealing the
tempreature is reset back to 1.
Specificlly I noticed cases in which after one or two runs the algorithm gets
a near perfect result and there is one adjudication swap to made
to make it perfect(score=0) but running the simulated annealing again
from where it last stopped never finds the one move it needs to make,
this is because the initiall energy is too high, so it makes a few bad moves
before it finds the good one, and then it needs to cancel out the bad moves.
When I manually changed the initial tempreature to start at a low value(0.1)
and ran the algorithm again it found the correct move and the score
improved to zero.

I propose to allow a method of adjusting the initiall tempreature and
or alpha for subsequent
runs of the simulated annealling algorithm.
So that we could re run the simulated annealling each time starting at
a lower temprature
and spreading out the annealing schedule to match.
If you would store the last starting temprature we could start the
next annealiing run
with half the previous starting temprature and calculate Alpha so that
after RUNS(20,000)
iteration the temprature will reach a predefined epsilon value.

I agree that there's lots of space for improvement in this area.... I've just rewritten it to be incrementally adjustable which has opened a lot of opportunities. We've both talked about the possibility of auto-updating with JavaScript, which is one of my personal favourites - I think the ideas you're proposing here could be well combined with that.

 Me.

Anyway - right now I'm focussing on getting version 1.4.1 out (some minor adjustments). Then I'd like to create a branch for the 1.4 family so we can have some isolated changes on the Worlds program.... once that's out of the way we could take the program to lots of places. I'm getting less eager to create a full new program from scratch - I'd prefer to start refactoring the DB, extract SQL and such to includable functions etc. I also think the current code base can be at least halved.... This should then create some new space for extra features such as "Different Debate Formats", support for after the preliminaries (semis, finals etc).

Anyway - worlds is the main priority for me now (as to Tabbie is concerned).

Klaas