I recommended the score being simply the total number of tries, with the restriction that each program is tested with the same multiset of solutions. I'd now like to augment this with the condition that there be only a few (say three) different (v, p) pairs tested (in the scoring runs at least), and the score and winner computed separately for each pair, because the submissions can behave really differently for each pair, so there's no fair scoring algorithm that works. (I also suggested elsewhere in this thread that these few parameter pairs be published in advance.)
(And yes, I want to write a submission, I even have an idea, but I don't have much time on my hands now because of, you know, Real Life occupations. Sorry.)
(Update: I'm not saying I'll write a well-scoring solution or have a good idea, I just mean some working submission and some idea.)
| [reply] |
| [reply] |
You can't brute force the largest case where v = 10 and p = 36 by far. More importantly my problem with your formula is that if it's taken seriously, it might favor solutions that run within a millisecond and are optimized for speed in complicated ways, which I wouldn't quite like. As a compromise, how about at least changing your formula in the following way:
score = (totalTries - minimumTries) * max((totalTime - timeInCheckSub) / totalTries, smallTimeConstant)
On second thought, do as you want, I probably don't really care about any scoring or winning here, I'd like to write a solution that satisfy me, and learn from it. If you make a common and mostly mechanical framework, it should rather rigorously test the solutions for correctness and be a developer's aid rather than select a winner.
| [reply] |
Now we'll only need more solution proposals, or else all this meta discussion will remain rather academic :-)
| [reply] |
| [reply] |