Programming Contest Nieuwe Stijl: Contest 4 *Score-update*

Het is zeker de bedoeling om bij de volgende contest te zorgen dat mensen wat meer betrokken blijven, en dat betekend dus ook dat de scores snel bekend moeten zijn. Dat zul dus zeker een van de dingen zijn die we in ons achterhoofd hebben bij de volgende contest.

Even een snelle braindump.

Is het misschien een idee om bij de start van een nieuwe contest al een webinterface naar een simpele validator aan te bieden? Dus een systeempje dat op 1 of andere manier een inzending beoordeelt, door er wat testcases op los te laten.

Voordelen:
* direct duidelijkheid over regels - liggen vastgelegd in validatie-testcases
* deelnemers hoeven niet zelf een validator te maken
* makkelijk vergelijken met prestaties van anderen, indien er ook iets als een "performance" testcase gedefinieerd is
* framework makkelijk te gebruiken voor uiteindelijke contest, door zwaardere testcases te gebruiken ipv simpele validatie testcases
* deze aanpak kan voor elke toekomstige contest gebruikt worden
Kortom, automatisering.

Nadelen:
* hoe de inzending te bouwen en beoordelen?
* kost misschien wat rekenkracht
* zelf validator maken is ook wel leuk eigenlijk

Schiet maar af, of werk maar uit!

Nog even los van hoe we een volgende contest aan gaan pakken wil ik nog wel even op je punten reageren:

quote:

JFeitsma schreef op zaterdag 06 juni 2009 @ 10:22:

Voordelen:
* direct duidelijkheid over regels - liggen vastgelegd in validatie-testcases

Het goed (kunnen) interpreteren van de omschrijving was altijd onderdeel van de opdracht.

quote:

* deelnemers hoeven niet zelf een validator te maken

Zelf een validator maken zul je toch moeten doen. Je zult in je AI immers moeten bepalen of een set geldig is of niet.

quote:

* makkelijk vergelijken met prestaties van anderen, indien er ook iets als een "performance" testcase gedefinieerd is

Met een validator valt de performance van je algoritme natuurlijk niet zo best te testen. Wanneer het gaat om het draaien op de server, dat is erg lastig. Dat is alleen goed mogelijk waneer we de toegestane platformen beperken tot een paar. Dat was nu juist iets wat we niet wilden doen.

quote:

* framework makkelijk te gebruiken voor uiteindelijke contest, door zwaardere testcases te gebruiken ipv simpele validatie testcases

Veel makkelijker dan het nu is gaat het niet worden vermoed ik. We hebben gewoon een berg sets die aan de specs voldoen en daar draaien we de inzendingen mee. Meer niet eigenlijk. Daarnaast geld ook hiervoor weer dat we geen beperking op de platformen willen leggen.

quote:

* deze aanpak kan voor elke toekomstige contest gebruikt worden
Kortom, automatisering.

Deze zie ik niet. Elke contest is weer dermate verschillend dat de overeenkomstige code maar marginaal, en dus verwaarloosbaar is.

Sinds de GoTBoT ben ik nooit meer met een contest bezig geweest. (Had die contest trouwens ook niet afgemaakt )
Ik hoop dat ik de volgende keer mee kan doen als het iets leuks is.

Oh noes

Wilde net even mijn evt score valideren, krijg ik een mooie out of bounds move. Blijkt dat mijn code niet zo slim omgaat met de newlines in het speeldveld.txt bestand. Omdat de laatste regel geen newline bevat telt mijn veld een regel minder. En omdat de y coordinaat van boven telt zijn alle moves waardeloos totdat een move niet kan.

Ik heb dit niet tijdens het ontwikkelen gevonden omdat vim standaard een file eindigt met een newline. Dit omdat veel programma's dit nodig zouden hebben. Blijkbaar heb ik ze allemaal wel eens geedit. Open en write zonder ook maar iets te doen is genoeg om die newline erbij te krijgen.

Nou ja. Ik haal iig meer dan 0 punten!

Les voor de volgende keer: test met een schone download van de testset.

Ik denk dat ik me er maak ook een keer aan ga wagen bij een nieuwe contest

Ik ben ook wel benieuwd naar nieuwe contest

quote:

Eskimootje schreef op vrijdag 05 juni 2009 @ 20:24:
Nee was weer een tijdje geleden dat ik wat geprogrammeerd heb, multithreading en echt slimme code was dus iets te veel van het goede. Hopelijk dat ik een volgende keer mee kan doen voor de prijzen. Als ik hem nog een keer draaide had ik weer precies 20982650. Hoe dat toeneemt met een snellere cpu is maar afwachten.

Ik heb hem ook gedraaid en haal ook precies 20982650 punten met jouw programma. Dus hij heeft ieder geval altijd dezelfde output.

quote:

Sh4wn schreef op zondag 07 juni 2009 @ 18:38:
Ik ben ook wel benieuwd naar nieuwe contest

Ik zal eerst deze eens afronden van het weekend.

quote:

Woy schreef op dinsdag 09 juni 2009 @ 09:06:
[...]

Ik heb hem ook gedraaid en haal ook precies 20982650 punten met jouw programma. Dus hij heeft ieder geval altijd dezelfde output.

Hmm dan ga ik maar eens mn code induiken, altijd dezelfde output kan natuurlijk niet goed zijn als hij op verschillende snelheden rekent. Ik denk dat er iets in mn tree selectie mechanisme niet goed is en hij kennelijk altijd dezelfde neemt. Wel lekker constant iig

Heb nog niets vreemds kunnen vinden helaas. Is een beetje lang geleden, maar hopelijk komt er bij de review van de modjes nog wat uit. Zou graag mn code hier posten maar heb geen space. Als iemand interesse heeft in een C# programma mag die pm'en dan stuur ik de code op.

Ik heb je code even vluchtig doorgekeken en heb wel een paar opmerkingen. Een daarvan is dat er wel wat commentaar tussen had gemogen . Op zich is het wel duidelijk, maar commentaar had het wat makkelijker gemaakt.

Al zie ik niet direct waardoor je altijd dezelfde uitslag zou hebben.

Woy wijzigde dit bericht 10-06-2009 23:51 (14%)

quote:

Eskimootje schreef op woensdag 10 juni 2009 @ 22:30:
Heb nog niets vreemds kunnen vinden helaas. Is een beetje lang geleden, maar hopelijk komt er bij de review van de modjes nog wat uit. Zou graag mn code hier posten maar heb geen space. Als iemand interesse heeft in een C# programma mag die pm'en dan stuur ik de code op.

Als je maar 1 thread hebt dan zal de algoritme waarschijnlijk altijd dezelfde "ideale" route nemen waardoor je ook aldoor dezelfde score krijgt.

Mogen er suggesties worden gegeven voor de volgende contest?

Iig lijkt het me bv leuk als je inzending tegen een iemand anders progsel moet spelen... dus... eerste ronde, tweede ronde, kwart finale, etc...

Ehm, wanneer wordt de broncode vrijgegeven?

quote:

Woy schreef op woensdag 10 juni 2009 @ 23:49:
Ik heb je code even vluchtig doorgekeken en heb wel een paar opmerkingen. Een daarvan is dat er wel wat commentaar tussen had gemogen . Op zich is het wel duidelijk, maar commentaar had het wat makkelijker gemaakt.

Al zie ik niet direct waardoor je altijd dezelfde uitslag zou hebben.

Commentaar had het idd nog duidelijker gemaakt. Zal ik de volgende keer zeker doen (heb zoveel mogelijk tijd in de code zelf gestopt commentaar is daardoor even achterwege gebleven).

quote:

Als je maar 1 thread hebt dan zal de algoritme waarschijnlijk altijd dezelfde "ideale" route nemen waardoor je ook aldoor dezelfde score krijgt.

Het algo zou zichzelf moeten tunen aan de hand van de tijd per stap. Op zich lijkt dat goed te gaan omdat de runtime altijd 15 minuten is. Het enige probleem is dat de score met verschillende cpu's (en bij mij thuis verschillende settings) geen verschil oplevert.Dit op compleet verschillende cpu's dus tijd per stap die doorlopen word.

quote:

NMe schreef op dinsdag 09 juni 2009 @ 10:45:
[...]

Ik zal eerst deze eens afronden van het weekend.

Sure, take your time Volgende contest ga ik wel iets insturen

quote:

Wouser schreef op donderdag 11 juni 2009 @ 05:59:
Mogen er suggesties worden gegeven voor de volgende contest?

Iig lijkt het me bv leuk als je inzending tegen een iemand anders progsel moet spelen... dus... eerste ronde, tweede ronde, kwart finale, etc...

smaken verschillen maar dat lijkt mij dan weer prut! Gaat iedereen dan obfuscaten zodat anderen minder kans hebben?

quote:

roy-t schreef op zaterdag 13 juni 2009 @ 10:43:
[...]


smaken verschillen maar dat lijkt mij dan weer prut! Gaat iedereen dan obfuscaten zodat anderen minder kans hebben?

Klopt, in het extreemste geval spelen de nummer 1 en 2 (qua scores) in de eerste ronde tegen elkaar, waardoor anders nummer 2 nu helemaal niet in de picture is.
Daarnaast moet het altijd weer goed uitkomen met een 2^N aantal teams (om het makkelijk te houden:) )

De eerlijkste manier om programma's tegen elkaar te laten spelen is denk ik een halve competitie (een hele mag ook, maar zou niets uit mogen maken). Hoewel je natuurlijk wel de kwestie krijgt of de oplossingen in de tussentijd mogen 'bijleren', zodat ze een volgend potje beter kunnen spelen.

Een halve/volledige competitie gaat natuurlijk wel lang duren. We hadden nu 20 inzendingen, stel dat je uit gaat van maximaal 30, dan moet je voor een halve competitie al 435 wedstrijden spelen. Stel dat je twee identieke dedicated servers kan ritselen (of eentje waarbij je kunt fixen dat een programma niet buiten zijn beurt CPU gebruikt) en je wil de boel binnen 24 uur kunnen doorrekenen, dan kun je al iets meer dan 3 minuten per potje doen, wat neerkomt op anderhalve minuut per programma. En dat is onder de aanname dat je alles perfect hebt geautomatiseerd met weinig downtime tussen de spellen.

Verder had de crew al een plan voor een volgende contest; ik denk dat je er wel vanuit mag gaan dat ze deze keer gekozen hebben voor een organisatorisch mínder veeleisende opzet, en dan kun je zo'n competitie wel uitsluiten.

Trouwens, ik hoop dat iedereen die directe competie ook wel leuk vind, komend najaar gewoon meedoet aan de Codecup (en dat de topics daarover niet elke keer na twee pagina's doodbloeden).

quote:

Soultaker schreef op zaterdag 13 juni 2009 @ 12:38:
Een halve/volledige competitie gaat natuurlijk wel lang duren. We hadden nu 20 inzendingen, stel dat je uit gaat van maximaal 30, dan moet je voor een halve competitie al 435 wedstrijden spelen. Stel dat je twee identieke dedicated servers kan ritselen (of eentje waarbij je kunt fixen dat een programma niet buiten zijn beurt CPU gebruikt) en je wil de boel binnen 24 uur kunnen doorrekenen, dan kun je al iets meer dan 3 minuten per potje doen, wat neerkomt op anderhalve minuut per programma. En dat is onder de aanname dat je alles perfect hebt geautomatiseerd met weinig downtime tussen de spellen.

Daarvoor hebben ze een knockout systeem uitgevonden, of als je dat oneerlijk vind, double elimination.

KO: = 29 matches (en dus 58 runs van een inzending)
DE: = 58/59 matches. (en dus 116/118 runs van een inzending)

wel redelijk veel meer, maar wel manageable imho

Iemand die bij een knockout in de eerste ronde eruit gespeeld wordt door de uiteindelijke winnaar wordt vrij laag gerankt terwijl het in een andere volgorde net zo goed de nummer twee had kunnen zijn. Knockout is dus geen goeie manier om inzendingen te kunnen ranken, en alle andere oplossingen duren nogal even om alle programma's te laten draaien.

Wat was er mis met gewoon iedereen tegen elkaar? Waren al meer dan genoeg runs om te doen gewoon n runs waar n = deelnemers lijkt me toch echt het simpleste .

@Soultaker I would als die topics niet doodgaan voordat ik ze zie .

roy-t wijzigde dit bericht 14-06-2009 13:12 (18%)

quote:

Soultaker schreef op zaterdag 13 juni 2009 @ 12:38:
Trouwens, ik hoop dat iedereen die directe competie ook wel leuk vind, komend najaar gewoon meedoet aan de Codecup (en dat de topics daarover niet elke keer na twee pagina's doodbloeden).

De reden dat de codecup niet succesvol is naar mijn mening het aantal toegestane programmeertalen. De enige jonge, hippe taal bij de codecup is Python. De meeste jonge mensen (waar de codecup op gericht is) programmeren tegenwoordig in java/.net/(php). Ik heb dit jaar als deelnemer van de informatica olympiade ook geprobeerd deel te nemen aan de codecup. Ik heb echter nooit iets ingezonden, omdat ik geen tijd/zin had om C++/Pascal/Python te leren. Ik kan prima met C# en VB.Net uit de voeten, en ik zie op dit moment geen reden om enorm veel tijd te stoppen om in een andere taal net zo vloeiend te worden als in de talen die ik al beheers.

Elke taal heeft zijn voor- en nadelen bij zo'n wedstrijd. Wat mij betreft moet het meedoen met een taal (zover het technisch realiseerbaar is) gewoon mogelijk zijn. Een beetje programmeur weet zelf wat de sterke en zwakke kanten van zijn taal zijn, en kan ook zelf zijn kansen uitrekenen bij een bepaalde opgave. De "snelle" talen zoals C(++) en pascal hebben bij wedstrijden met een hele lange inzendtijd (zoals de programmeercontests hier op got) gewoon een voordeel qua performance. Dat neemt niet weg dat andere mensen er een uitdaging in kunnen zien om het in een andere taal te proberen.

Bij tijdsgebonden wedstrijden (zoals bijv. de nederlandse en internationale olympiade, waar in de eindrondes alleen c(++) en pascal toe zijn gestaan), is het zelfs nog veel interessanter om alle talen toe te staan. De c(++) en pascal mensen hebben het voordeel van de hoge performance, terwijl de python/java/.Net-coders het gemak van het snelle programmeren hebben en dus minder snel in tijdsnood komen. Iedereen kan het beste uit zijn taal halen: een fair call wat mij betreft. Schijnbaar denken ze er daar nog anders over, wat ik zeer spijtig vind

Je zag bij de olympiade in de ranking van ronde 1 trouwens ook dat er een redelijk grote groep van mensen was die in opgaven 1 en 2(alle talen toegestaan) met java/c#/vb.net hoog scoorden maar in de codecup(opgave 3) geen inzending hadden, bewijst eigenlijk een beetje wat ik hier boven beweer. Ik ben door dezelfde beperking in ronde 3 van de nederlandse olympiade hoogstwaarschijnlijk ook laatste geworden.

Goed, tot zover mijn semi-off-topic gezever, misschien wilde ik stiekem ook gewoon even mijn frustraties kwijt voor mijn grandioze nederlaag vorige zaterdag bij de olympiade

gerrymeistah wijzigde dit bericht 14-06-2009 20:33 (1%)
Reden: shitload aan typo's