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

[Woy]

.oisyn schreef op woensdag 03 juni 2009 @ 01:23:
[...]

Geh. Wat ik me afvraag, gebruikt ie in Wine wel alle cores? Onder Win XP x64 op een quad core heeft hij een CPU utilization van ~80%. Dit itt die van Pete, die slechts rond de 72% gebruikte (en 55% op de client VM ). Maar jouw 261% vind ik dramatisch slecht moet ik zeggen... (hoe moet ik dat interpreteren, als 261/8 = 32% total load?)

OMG I fucking love Google Chrome. M'n bak rebootte net spontaan terwijl ik deze post aan het tikken was, en na het opnieuw opstarten van Chrome zei ie dat niet alles correct was afgesloten en of ik de windows wilde herstellen, en mijn hele post stond er gewoon nog

Is de inzending die jij opgestuurd hebt een 64 bits executable?
Ik krijg op een dual Xeon quad core op Win Server 2008 64 bits namenlijk een (iets) lagere score met jouw inzending dan dat jij hier hebt

.oisyn schreef op dinsdag 02 juni 2009 @ 17:40:
Hmm vaag, ik had 1.6 build 11, maar die zegt dus HotSpot Client VM. Heb net de laatste versie geinstalled (build 14), en nu zegt ie wel Server VM.

Dit was iig met de oude build:

.oisyn
Score....................: 37245550 points
Total moves..............: 99999
Succesful moves..........: 99999
Bad moves................: 0
Average score per move...: 372 points
Move with highest score..: #62909 (2200 points)

[.oisyn]

Woy schreef op donderdag 04 juni 2009 @ 11:34:
[...]

Is de inzending die jij opgestuurd hebt een 64 bits executable?

Nee, die was langzamer dan de 32 bits versie

Ik krijg op een dual Xeon quad core op Win Server 2008 64 bits namenlijk een (iets) lagere score met jouw inzending dan dat jij hier hebt

Niet zo gek, hij is namelijk niet deterministisch en het hangt heel erg af van de snelheid van je systeem. Hij probeert er ook 897 seconden over te doen om 100.000 moves te doen, wat betekent dat ie zo'n 111.5 moves/s aanhoudt. Dit heeft invloed op de zoekbreedte.

[Woy]

.oisyn schreef op donderdag 04 juni 2009 @ 11:42:
[...]
Niet zo gek, hij is namelijk niet deterministisch en het hangt heel erg af van de snelheid van je systeem. Hij probeert er ook 897 seconden over te doen om 100.000 moves te doen, wat betekent dat ie zo'n 111.5 moves/s aanhoudt. Dit heeft invloed op de zoekbreedte.

Ok maar jij test met een enkele quad-core, dan verwacht ik dat het op een machine met 2 quad cores en 16 Gb snel geheugen toch sneller zou zijn. Of maak je stiekem gebruik van de video kaart die is in die machine niet zo snel

[.oisyn]

M'n implementatie is voornamelijk memory bandwidth limited, dus ik weet niet wat voor geheugen je erin hebt zitten en wat je FSB is? En gezien je setup zal er ook wel ECC / registered mem in zitten, of niet?

[Woy]

Ja het is wel ECC / registered. Ik zal zo de complete setup even opzoeken. Ik ben de Top 4 ieder geval even opnieuw aan het draaien. En de Java implementaties daarbij met 5GB geheugen en op de server VM.

Er zitten ieder geval 2* deze in: http://processorfinder.intel.com/details.aspx?sSpec=SLANU

[Woy]

Ik heb de Top4 even opnieuw gedraaid en dit zijn de resultaten

DaCoTa		= 40.364.550
Pete		= 39.658.450
Bomberboy	= 38.657.650
.oisyn		= 37.078.600

De java inzendingen gerund met

java -Xms128m -Xmx5000m -server -jar <jarfile>

Met de JRE-6 update 14 64bits

[.oisyn]

Dat komt idd meer overeen met de verwachtingen die gekweekt zijn in deze draad bij het opscheppen over individuele uitslagen

Kun je ook aangeven wat de CPU usages zijn van de verschillende entries?

[ Voor 48% gewijzigd door .oisyn op 04-06-2009 12:38 ]

[Woy]

.oisyn schreef op donderdag 04 juni 2009 @ 12:37:
Dat komt idd meer overeen met de verwachtingen die gekweekt zijn in deze draad bij het opscheppen over individuele uitslagen

Kun je ook aangeven wat de CPU usages zijn van de verschillende entries?

Ik zal ze zo allemaal nog even een minuut of wat laten lopen en ongeveer de CPU usage bekijken.

[roy-t]

YAy10101 De scores, thx NME dat je toch tijd hebt gevonden en bedankt voor je dikke huid zodat we toch allemaal lekker konden (en nu doen) zeuren zonder dat je het erg vondt.

Kan niet wachten op de volgende contest .



(now kill me )

[ Voor 21% gewijzigd door roy-t op 04-06-2009 13:13 ]

[Matis]

roy-t schreef op donderdag 04 juni 2009 @ 13:12:
(now kill me )

Nope, eerst rapen, daarna pas lynchen!

Edit:
Zijn er ook nog leuke hints/tips voor de 5e contest? Wat het onderwerp/richting gaat worden!?! Of wordt dit alleen maar binnen de muren van de kelder van PRG geopperd?

[ Voor 35% gewijzigd door Matis op 04-06-2009 13:21 ]

[BtM909]

Matis schreef op donderdag 04 juni 2009 @ 13:15:
[...]


Nope, eerst rapen, daarna pas lynchen!

Edit:
Zijn er ook nog leuke hints/tips voor de 5e contest? Wat het onderwerp/richting gaat worden!?! Of wordt dit alleen maar binnen de muren van de kelder van PRG geopperd?

hint:

spoiler:

Het heeft niks met deze contest te maken

[Matis]

No shit Sherlock
Ik stelde alleen de vraag, want wanneer de 5e contest geopend wordt, zal het plan ook al wel duidelijk zijn. Daarom denk ik, vraag het even

spoiler:

 

[compufreak88]

Ik ben ook benieuwd naar de volgende contest. Ik hoop dat ik er deze keer wat serieuzer aan mee kan doen.

[Woy]

Ik heb ook even de processor usage bekeken van de 4 tests die ik gedraaid hebt

DaCoTa		= 75% - 90%
Pete		= 75% - 85%
Bomberboy	= 65% - 90%
.oisyn		= 50% - 60%

Dit heb ik gewoon een beetje gekeken in de Task Manager.

Bij DaCoTa viel me op dat af en toe alle core's naar de ~ 0% schieten op 1 core na


Bij .oisyn viel het me op dat er maar 1 core boven de 90% zit de rest zit tussen de 40% en 50%

[.oisyn]

Interessant... Als ik m'n parallellisatie beter kan krijgen zou ik dus evt. ook een paar plekken hoger kunnen eindigen.

[Woy]

Kan het zijn dat je een producer thread hebt, die blijkbaar niet genoeg werk aan kan leveren voor je consumers?

[.oisyn]

Dat is precies wat er aan de hand is

[Pete]

Mijn threading systeem kon ook beter. Maar ja, er kan altijd iets beter.

[DaCoTa]

Woy schreef op donderdag 04 juni 2009 @ 15:47:
Kan het zijn dat je een producer thread hebt, die blijkbaar niet genoeg werk aan kan leveren voor je consumers?

Ja, ik houd in de producer inderdaad wel rekening met een aantal cores voor workers, maar niet met zoveel cores. Op een single en op een dual core heb ik gezien dat ik met 2 workers per core de hoogste snelheid behaalde, maar dat gaat dus niet op met 16 workers op een octocore Als ik het me goed kan herinneren kunnen er 4 workers redelijk onafhankelijk van elkaar werken, omdat er in 4 moves tegelijk gerekend wordt. Bij meer workers gaat er dan een boel overhead zitten in locking tussen workers.

Waar de piekload op 1 core vandaan komt weet ik niet. Dat heb ik zelf nooit gezien.

[ Voor 23% gewijzigd door DaCoTa op 04-06-2009 17:50 ]

[.oisyn]

Pete schreef op donderdag 04 juni 2009 @ 16:54:
Mijn threading systeem kon ook beter. Maar ja, er kan altijd iets beter.

Zoals runnen met -server bedoel je?

[roy-t]

.oisyn schreef op donderdag 04 juni 2009 @ 17:55:
[...]

Zoals runnen met -server bedoel je?

flauw

[Eskimootje]

Als ik de speelset op mn eigen notebook draai haal ik een score van 20982650 niet zo hoog maar hij doet het wel. Ik ga hem nog eens draaien kijken of de score veranderd.

[Woy]

Ik zal hem maandag nog even op de machine draaien waar ik de andere op getest hebt, dan weet je ieder geval ongeveer hoe je score is in verhouding met de rest.

Maar als ik hem op mijn pc ( dual core ) run dan trekt hij maar 1 core vol, dus je parallelisatie lijkt niet zo goed te werken. Dus ik verwacht niet zo'n hoge score op een octo-core

edit:
Ah als ik in je code kijk zie ik ook geen threading code, dat verklaart het

[ Voor 11% gewijzigd door Woy op 05-06-2009 19:16 ]

[Eskimootje]

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.

[Arjan]

misschien een tip voor de organisatie, als jullie duidelijk omlijnen hoe de executable moet werken dan kunnen jullie al tijdens de contest een stukje software schrijven dat de resultaten runt

Als de deadline is gekomen dan verzamelen jullie alle meuk, zetten voor het slapen gaan even de pc aan en voila! 's ochtends alle resultaten in een csv filetje

Ik zou het in ieder geval wel kunnen waarderen als de resultaten snel bekend zijn na afloop. Ik heb nu namelijk geen interesse meer om me in te gaan lezen in m'n eigen code, laat staan die van anderen.. Iets dat ik wel heb 'in the heat of the moment'.

[Woy]

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.

[Verwijderd]

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!

[Janoz]

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

Verwijderd 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.

* 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.

* 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.

* 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.

* 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.

[Jegorex]

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.

[veldsla]

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.

[GrooV]

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

[Sh4wn]

Ik ben ook wel benieuwd naar nieuwe contest

[Woy]

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.

[NMe]

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.

[Eskimootje]

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

[Eskimootje]

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.

[Woy]

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.

[ Voor 14% gewijzigd door Woy op 10-06-2009 23:51 ]

[Jegorex]

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.

[Chip.]

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...

[Verwijderd]

Ehm, wanneer wordt de broncode vrijgegeven?

[Eskimootje]

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).

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.

[Sh4wn]

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

[roy-t]

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?

[Matis]

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:) )

[dcm360]

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.

[Soultaker]

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).

[Silentuz]

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

[NMe]

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.

[roy-t]

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 .

[ Voor 18% gewijzigd door roy-t op 14-06-2009 13:12 ]

[Gimmeabrake]

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

[ Voor 1% gewijzigd door Gimmeabrake op 14-06-2009 20:33 . Reden: shitload aan typo's ]

[Soultaker]

gerrymeistah schreef op zondag 14 juni 2009 @ 20:31:
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).

Java is gewoon supported hoor? Bij deze GoT contest was er geen restrictie op programmeertalen, en in de top vijf zijn drie Java, één C en één C++ applicatie (de andere inzendingen weet ik niet precies). Alledrie deze talen worden óók bij de Codecup ondersteund. Het lijkt er dus op dat de Codecup best redelijk aansluit bij de talen die mensen zelf kiezen als ze vrije keuze hebben.

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.

Vanuit praktische overwegingen moeten alle inzendingen op Linux-systemen moeten draaien, vandaar dat .NET niet echt supported is, en meer obscure talen als Pascal en (voor dit doel) Python wel.

Overigens ben ik niet tegen een competitie-achtige contest op GoT, maar mijn punt was meer dat de Codecup zo'n soort wedstrijd al jaarlijks organiseert, waarbij je als deelnemer een maand of vier de tijd hebt om aan je oplossing te werken, wat ook ongeveer de timeframe van deze contest was (al dan niet bedoeld).

Dan heb ik liever dat de devschuur crew een iets ander type contest organiseert, dan dat er twee soortgelijke contests georganiseerd worden; zeker als de vrijwilligers van de crew niet genoeg tijd kunnen vrijmaken om een competitie-contest goed te organiseren.

[Gimmeabrake]

Soultaker schreef op zondag 14 juni 2009 @ 22:28:
[...]

Java is gewoon supported hoor?

Whoops, java had ik inderdaad over het hoofd gezien. You got me there Je moet wel niet vergeten dat de codecup is gestart voor de nederlandse informatica olympiade. Dat voor de rest iedereen kan meedoen, is een leuke feature, maar niet de hoofdzaak van de contest. De deelnemers van de olympiade zijn middelbare scholieren, en op middelbare scholen zijn (correct me if I'm wrong) java, php, pascal/delphi en basic de gebruikelijke programmeertalen. De codecup sluit dus maar gedeeltelijk aan zijn hoofdzakelijke doelgroep aan. Dat er maar zo weinig deelnemers van ronde 1 van de olympiade iets hebben ingezonden voor de codecup, terwijl ze voor de andere 2 opdrachten uit deze ronde wel iets hebben ingestuurd, bevestigt dit alleen maar.

Vanuit praktische overwegingen moeten alle inzendingen op Linux-systemen moeten draaien, vandaar dat .NET niet echt supported is, en meer obscure talen als Pascal en (voor dit doel) Python wel.

In ronde 2 van de olympiade werden C# en VB.Net keurig en volledig geautomatiseerd ondersteund (mono anyone?). Een van de organisatoren vertelde mij vorige zaterdag dat er maar liefst 24 talen zijn gebruikt tijdens ronde 2, en dat ging allemaal keurig goed in een geautomatiseerd unix-inzendsysteempje (peach - toen wel nog versie 2). Dat lijkt me het probleem dus niet.

Misschien is het een idee om een systeem als peach te gebruiken, dat zal waarschijnlijk eenmalig een pokke karwei zijn om het aan de praat te krijgen, maar ik denk dat iedereen er baat bij heeft als de evaluatie snel gaat en er een systeem is dat binnen luttele seconden test of je inzending de juiste output geeft bij een testcase: niets is immers zuurder als een briljant programma schrijven en er na afloop achter komen dat het foutief output (klassieker bij de olympiade: een /n vergeten aan het einde van het bestand)

[Soultaker]

gerrymeistah schreef op zondag 14 juni 2009 @ 23:50:
Dat voor de rest iedereen kan meedoen, is een leuke feature, maar niet de hoofdzaak van de contest.

Wat maakt dat uit? De organisatie staat expliciet iedereen toe om mee te doen, dus als je dat leuk vind, waarom zou je dat niet doen?

In ronde 2 van de olympiade werden C# en VB.Net keurig en volledig geautomatiseerd ondersteund (mono anyone?).[ Een van de organisatoren vertelde mij vorige zaterdag dat er maar liefst 24 talen zijn gebruikt tijdens ronde 2, en dat ging allemaal keurig goed in een geautomatiseerd unix-inzendsysteempje (peach - toen wel nog versie 2). Dat lijkt me het probleem dus niet.

Tuurlijk is het allemaal wel mogelijk, maar het is wel lastiger om onder verschillende platforms dezelfde constraints aan geheugengebruik, processorgebruik (niet buiten je beurt denken) en communicatie tussen processen mogelijk te maken. De NIO zelf is makkelijker in die zin omdat er minder strenge constraints zijn; programma's hoeven alleen maar invoer te lezen en uitvoer te schrijven en wat 't verder doet maakt niet zoveel uit.

Je ziet al bij deze GoT contest dat het heel lastig is om alle inzendingen te draaien in een optimale omgeving (anders gaan de deelnemers zeuren) én onder vergelijkbare omstandigheden, en dat was nog alleen Windows. Natuurlijk, in theorie is alles mogelijk, maar in de praktijk is het handig om een paar beperkingen op te leggen.

Misschien is het een idee om een systeem als peach te gebruiken, dat zal waarschijnlijk eenmalig een pokke karwei zijn om het aan de praat te krijgen

Wat, voor GoT bedoel je? Ik denk dat de crew juist geen zin heeft in dat "pokke kawei". Het zijn allemaal vrijwillegers hè, en vziw heeft Tweakers.net geen dedicated servertjes staan voor het runnen van dit soort contests (zou wel een uitkomst zijn trouwens).

.. niets is immers zuurder als een briljant programma schrijven en er na afloop achter komen dat het foutief output (klassieker bij de olympiade: een /n vergeten aan het einde van het bestand)

diff -b

Maar om een lang verhaal kort te maken: niet miepen, gewoon meedoen.

[Gimmeabrake]

Soultaker schreef op maandag 15 juni 2009 @ 01:40:
[...]

Maar om een lang verhaal kort te maken: niet miepen, gewoon meedoen.

Dat was ik sowieso al van plan

[Bozozo]

Proefballonnetje voor een volgende contest: path finding + excecution.

Een pad vinden tussen twee punten zal voor de meesten niet zo'n probleem zijn maar het efficient verplaatsen van veel units tegelijk (die elkaar in de weg zitten) is echt een uitdaging. Een speelveld zou kunnen bestaan uit een groot aantal tegels waarvan een aantal ontoegankelijk is, met daarop verspreid vele units die naar verschillende doelen willen.

Het nadeel van zo'n onderwerp is misschien dat deze contest ook al een plan-de-beste-move contest was, maar dat zijn nu eenmaal aansprekende problemen.

Schiet maar lek

[Matis]

Bozozo schreef op maandag 15 juni 2009 @ 10:37:
Proefballonnetje voor een volgende contest: path finding + excecution.

Een pad vinden tussen twee punten zal voor de meesten niet zo'n probleem zijn maar het efficient verplaatsen van veel units tegelijk (die elkaar in de weg zitten) is echt een uitdaging. Een speelveld zou kunnen bestaan uit een groot aantal tegels waarvan een aantal ontoegankelijk is, met daarop verspreid vele units die naar verschillende doelen willen.

Het nadeel van zo'n onderwerp is misschien dat deze contest ook al een plan-de-beste-move contest was, maar dat zijn nu eenmaal aansprekende problemen.

Schiet maar lek

Ik heb een maand-of-wat geleden exact hetzelfde aan roy-t voorgesteld met een DM. Ik had het voornamelijk over path-finding (zoals bij TomTom), maar dat wordt met A* te eenvoudig. Mulit path en trage voertuigen en snelle voertuigen en opstoppingen e.d. lijken me echt vet.

Maar dan heb je altijd weer de boze BtM909 met z'n spoilers
BtM909 in "Programming Contest Nieuwe Stijl: Contes..."

[roy-t]

Matis schreef op maandag 15 juni 2009 @ 10:42:
[...]


Ik heb een maand-of-wat geleden exact hetzelfde aan roy-t voorgesteld met een DM. Ik had het voornamelijk over path-finding (zoals bij TomTom), maar dat wordt met A* te eenvoudig. Mulit path en trage voertuigen en snelle voertuigen en opstoppingen e.d. lijken me echt vet.

Maar dan heb je altijd weer de boze BtM909 met z'n spoilers
BtM909 in "Programming Contest Nieuwe Stijl: Contes..."

Plan de beste move problemen zijn ook heel universeel en ingewikkeld, van vooraad tot bergpad tot efficient typen het is allemaal een pad probleem. Ik vind het zelf leuk als je een eigen AI moet bouwen zoals oa wel naar voren kwam in deze contest (helaas had ik geen tijd). Een soort van "Traffic" is misschien best leuk voor de volgende contest maar dan moet er wel goed opgelet worden dat er niet een "off the shelve" algo is dat gebruikt kan worden. (Wat bij alleen pathfinding toch snel Dykstra/A* wordt).

[Elvis]

Het word interessanter als de opdracht een "traffic jam" omvat die zélf met oplosbare puzzels moet komen.

[stereohead]

TSP dan misschien?

[Matis]

stereohead schreef op woensdag 17 juni 2009 @ 09:05:
TSP dan misschien?

Dan kunnen we ook deze erbij pakken: Wikipedia: Knapsack problem of Wikipedia: Knapzakprobleem, probleem daarbij is dat er al heel veel onderzoek/theorieen/algoritmes voor zijn. Maar dat is wel leuk om te doen

[ Voor 9% gewijzigd door Matis op 17-06-2009 09:08 ]

[Bolukan]

Op pagina 1 en op de pagina met de uitslag 4x tm 54 kan ik geen source codes van de oplossingen vinden (los van een verwijzing). Kijk ik iets over het hoofd? De source wordt toch vrijgegeven na sluiting van de deadline?
Dan kunnen we ook iets kwijt over "Beste documentatie", "Mooiste oplossingsrichting", etc.

[BalusC]

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

Ik zal eerst deze eens afronden van het weekend.

Niet lullig bedoeld, maar het feit dat er al 3 weekenden voorbij zijn geweest sinds je dat hebt gemeld en dat er haast 5 maanden zijn verstreken eer uitslag is, maakt die smiley wel heel erg misplaatst.

[NMe]

Er is destijds iets tussen gekomen en ik heb tot nu toe nog geen tijd gehad om én die andere resultaten uit te laten draaien én de code te reviewen. Maar je hebt gelijk, dat moet mijn probleem zijn, niet dat van jullie.

Als alles goed gaat heb ik zondag wel een paar uurtjes over waarin ik wel met de laptop in de zon kan gaan zitten voor de afronding hiervan.

[KoW]

dcm360 schreef op maandag 01 juni 2009 @ 22:41:
[...]
Dat is nog t/m 12 juli (12 juni is 5 maanden)

Nou, dat is het toch bijna

[NMe]

Running stuff as we speak.

[Matis]

NMe schreef op maandag 06 juli 2009 @ 22:37:
Running stuff as we speak.

Good Good

Keep up the good work


* Matis can't wait for the next attempt

[Serpie]

Ben ook benieuwd, hoop dat ik wat tijd vrij kan maken voor de volgende contest. Ik vind het altijd leuk om te doen.

[Dricus]

Is het geen idee om gewoon de volgende contest te starten, of moet daar nog het nodige voor uitgewerkt, bedacht of geregeld worden? Er is al een soort van officieuze uitslag (zonder code review welliswaar). Daarnaast kan ik me voorstellen dat een uitslag na 6 maanden voor de inzenders sowieso al een behoorlijke mosterd na de maaltijd belevenis is . Ik heb er wel zin in moet ik zeggen.

[KoW]

NMe schreef op maandag 06 juli 2009 @ 22:37:
Running stuff as we speak.

Is ie vastgelopen

[Matis]

KoW schreef op woensdag 15 juli 2009 @ 15:49:
[...]

Is ie vastgelopen

[NMe]

Nee, alles is gerund. We hebben alleen de code review nog niet afgerond, en daar heb ik zaterdagmiddag tijd voor gemaakt.

[Mammon]

NMe schreef op woensdag 15 juli 2009 @ 20:12:
Nee, alles is gerund. We hebben alleen de code review nog niet afgerond, en daar heb ik zaterdagmiddag tijd voor gemaakt.

Is het allemaal gelukt? Ik ben erg benieuwd naar de nieuwe contest.

[NMe]

Ik dacht alles gerund te hebben maar was de beloofde recompile van DirkW's code vergeten. Die heb ik ook gedaan maar om de een of andere reden herkent onze validator 99.999 van de 100.000 regels niet, terwijl die at first glance wel zouden moeten valideren, of in elk geval verder dan de eerste stap. Ik wacht even een reactie van RobIII af om te zien of hij als schrijver van de validator ziet waar het misgaat maar ik verwacht dat ik morgenavond laat gewoon alle resultaten kan posten.

[BalusC]

NMe schreef op zondag 19 juli 2009 @ 03:41:
maar om de een of andere reden herkent onze validator 99.999 van de 100.000 regels niet

Wellicht een "verkeerde" linebreak?

[NMe]

Dat klopt inderdaad. Maar nadat ik dat gefixt had, had ik nog steeds dezelfde problemen. Na al deze tijd wil ik het ook echt helemaal afronden dus vandaar dat ik hier nog even achteraan ga; als het morgen niet opgelost is heb ik het in elk geval geprobeerd.

Als iemand mee wil helpen met gekke dingen eruit halen: http://crew.tweakers.net/...G/004/entries/uitvoer.txt
Dit is de originele file die ik nog niet gefixt heb voor "dubbele" line breaks.

Overigens, jouw inzending heb ik ook nog eens gerund met de server-VM en 1.5GB geheugen (ik heb alle Java-inzendingen opnieuw gedaan) en helaas gaat die op dezelfde zet mis.

[ Voor 18% gewijzigd door NMe op 19-07-2009 04:28 ]

[BalusC]

Die zet-fail is gewoon een stomme bug dat ik nog moet uitzoeken als ik zin heb

[Verwijderd]

NMe schreef op zondag 19 juli 2009 @ 04:26:
Dat klopt inderdaad. Maar nadat ik dat gefixt had, had ik nog steeds dezelfde problemen. Na al deze tijd wil ik het ook echt helemaal afronden dus vandaar dat ik hier nog even achteraan ga; als het morgen niet opgelost is heb ik het in elk geval geprobeerd.

Als iemand mee wil helpen met gekke dingen eruit halen: http://crew.tweakers.net/...G/004/entries/uitvoer.txt
Dit is de originele file die ik nog niet gefixt heb voor "dubbele" line breaks.

Overigens, jouw inzending heb ik ook nog eens gerund met de server-VM en 1.5GB geheugen (ik heb alle Java-inzendingen opnieuw gedaan) en helaas gaat die op dezelfde zet mis.

00000000: 3231 2031 3620 5a[red]0d 0d0a[/red] 3234 2033 204f  21 16 Z...24 3 O
00000010: [red]0d0d 0a[/red]31 3420 3136 204f [red]0d0d 0a[/red]31 3120  ...14 16 O...11 
00000020: 3134 204f 0d0d 0a31 3220 3136 205a 0d0d  14 O...12 16 Z..
00000030: 0a31 3420 3134 204f 0d0d 0a31 3420 3133  .14 14 O...14 13
00000040: 204f 0d0d 0a32 3420 3133 205a 0d0d 0a39   O...24 13 Z...9
00000050: 2031 3320 4f0d 0d0a 3920 3620 4f0d 0d0a   13 O...9 6 O...
00000060: 3020 3520 4f0d 0d0a 3231 2031 3620 4f0d  0 5 O...21 16 O.

Twee keer carriage return en slechts één linefeed. Dah ken volgens meh nie.

[Dirk]

Grappig, dat moet dan aan de compiler liggen ofzo, want in mijn eigen outputbestand heb ik gewoon een enkele CR en LF.

ik gebruik ook het volgende simpele regeltje code om de boel te outputten:

C++:

fprintf (outputFile, "%u %u %c\x0D\n", x, y, dir);

Maar bij mij wordt die \n enkel naar een LF vertaald, dus ik heb er handmatig een CR aan toegevoegd.

Overigens nu ik de code weer terug zie, zie ik dat ondanks dat het over het algemeen prima voor zichzelf spreekt, ik her en der toch wel wat meer commentaar had mogen toevoegen....

[ Voor 20% gewijzigd door Dirk op 19-07-2009 13:57 ]

[Pete]

NMe schreef op zondag 19 juli 2009 @ 04:26:
Dat klopt inderdaad. Maar nadat ik dat gefixt had, had ik nog steeds dezelfde problemen. Na al deze tijd wil ik het ook echt helemaal afronden dus vandaar dat ik hier nog even achteraan ga; als het morgen niet opgelost is heb ik het in elk geval geprobeerd.

Als iemand mee wil helpen met gekke dingen eruit halen: http://crew.tweakers.net/...G/004/entries/uitvoer.txt
Dit is de originele file die ik nog niet gefixt heb voor "dubbele" line breaks.

Overigens, jouw inzending heb ik ook nog eens gerund met de server-VM en 1.5GB geheugen (ik heb alle Java-inzendingen opnieuw gedaan) en helaas gaat die op dezelfde zet mis.

Script (op linux)

Perl:

#!/usr/bin/perl
use strict;

while(<>) {
  chomp;
  s/[^NWZU]+$//g;

  print;
  print "\r\n" if(length($_) > 0);
} 

Geeft deze uitvoer. Aantal punten: 24600

Kunnen jullie dan nu de uitslag posten?

Dirk schreef op zondag 19 juli 2009 @ 13:50:
Grappig, dat moet dan aan de compiler liggen ofzo, want in mijn eigen outputbestand heb ik gewoon een enkele CR en LF.

ik gebruik ook het volgende simpele regeltje code om de boel te outputten:

C++:

fprintf (outputFile, "%u %u %c\x0D\n", x, y, dir);

Maar bij mij wordt die \n enkel naar een LF vertaald, dus ik heb er handmatig een CR aan toegevoegd.

Overigens nu ik de code weer terug zie, zie ik dat ondanks dat het over het algemeen prima voor zichzelf spreekt, ik her en der toch wel wat meer commentaar had mogen toevoegen....

Van wikipedia:

When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character.

Het klopt dus dat jouw code op windows \r\r\n output.

[ Voor 32% gewijzigd door Pete op 20-07-2009 10:09 ]

[NMe]

Dirk schreef op zondag 19 juli 2009 @ 13:50:
Maar bij mij wordt die \n enkel naar een LF vertaald, dus ik heb er handmatig een CR aan toegevoegd.

Alleen een linefeed was ook genoeg geweest volgens de specificaties, juist om dit soort dingen te voorkomen.

Anyway, als ik straks thuiskom heb ik even een half uurtje vrij voor het posten van de uiteindelijke scores. Ik moet de code review nog even afronden dus dat wordt later vanavond of morgenmiddag. Ik denk dat er wel een paar mensen blij gaan zijn met de nieuwe runs die ik gedaan heb.

[veldsla]

Als we toch zo ruim met de specs omgaan, mag ik dan ook een extra LF bij de input files erbij?

[Pete]

NMe schreef op maandag 20 juli 2009 @ 10:29:
...
Ik denk dat er wel een paar mensen blij gaan zijn met de nieuwe runs die ik gedaan heb.

Ik ben hoopvol

Maar, betekent dat niet automatisch dat er een ook paar mensen minder blij zullen zijn?

[NMe]

veldsla schreef op maandag 20 juli 2009 @ 12:35:
Als we toch zo ruim met de specs omgaan, mag ik dan ook een extra LF bij de input files erbij?

Is dat wat er bij jou misgaat? Want ik heb jouw code ook zelf gecompileerd en dat deed niets meer dan het aantal rijen/kolommen laten zien en de startsituatie van het speelveld.

Pete schreef op maandag 20 juli 2009 @ 12:36:
[...]

Maar, betekent dat niet automatisch dat er een ook paar mensen minder blij zullen zijn?

Da's afhankelijk van hoe serieus die mensen deze contest nemen.

[ Voor 26% gewijzigd door NMe op 20-07-2009 12:48 ]

[veldsla]

NMe schreef op maandag 20 juli 2009 @ 12:47:
[...]

Is dat wat er bij jou misgaat? Want ik heb jouw code ook zelf gecompileerd en dat deed niets meer dan het aantal rijen/kolommen laten zien en de startsituatie van het speelveld.

Dat is vreemd. Als ik mijn gesubmitte code compile (gcc -O3 bejeweled.c) en de a.out run op de vers geunzipte speeldata dan loop ie wel (maar fout) en met een LF op beide files erbij loopt ie zoals het hoort (hoop ik ). Maar hij doet wel altijd wat

[NMe]

Nou, de door jou ingeleverde executable deed niks (illegal instruction was de melding geloof ik), dus heb ik zelf het zaakje gecompileerd en dat doet dus het bovenstaande: niks, maar dan anders.

[veldsla]

Ik heb je een mail gestuurt met een i386 binary. Als die het ook niet doet doe ik in de toekomst geen gecompileerde talen meer!

[NMe]

Ik zal vanavond eens kijken.

edit:

The original e-mail attachment "a.out"
is on the list of unacceptable attachments for this site and has been
replaced by this warning message.

Da's niet zo handig. Overigens weet ik niet wat ik met een .out file zou moeten doen.

[ Voor 80% gewijzigd door NMe op 20-07-2009 13:41 ]

[veldsla]

We zijn eruit. Jij compileert onder windows en ik onder linux/osx. Waarschijnlijk heb ik ook last van de \n conversies die een win compiler uitvoert.

Jammer, maar helaas.

[Soultaker]

NMe schreef op zondag 19 juli 2009 @ 04:26:
Als iemand mee wil helpen met gekke dingen eruit halen: http://crew.tweakers.net/...G/004/entries/uitvoer.txt
Dit is de originele file die ik nog niet gefixt heb voor "dubbele" line breaks.

Na verwijderen van de dubbele linebreaks kom ik met mijn verifier op een nette 19.309.050 punten na 100.000 zetten.

veldsla schreef op maandag 20 juli 2009 @ 14:45:
Ik heb je een mail gestuurt met een i386 binary. Als die het ook niet doet doe ik in de toekomst geen gecompileerde talen meer! [..] Jij compileert onder windows en ik onder linux/osx. Waarschijnlijk heb ik ook last van de \n conversies die een win compiler uitvoert.

Hoe heb je de Windows-versie precies gecompileerd dat 'ie illegal instructions produceert? Lijkt me dat je daarbij een architectuur gespecificeerd hebt die niet overeenkomt met de jurycomputer (-march=native meegegeven aan GCC ofzo?)

Wat betreft I/O is de truc in C om vooral niet zelf met carriage returns te gaan prutsen (zoals DirkW deed) maar gewoon bestanden in tekstmode moet openen (fopen(path, "rt"); en fopen(path, "wt");) dan gaat conversie van regeleindes vanzelf goed op alle platforms (Linux, Mac OS, Windows). Onder Linux moet je dan nog wel de testbestanden converteren (met dos2unix ofzo) als je lokaal wil testen.

Ik heb geen enkele wijziging in mijn code hoeven maken om de boel onder Windows goed te laten werken (en kan zelfs crosscompilen voor Windows vanuit Linux) dus in principe hoef je gecompileerde talen vanwege platformverschillen niet links te laten liggen.

[ Voor 61% gewijzigd door Soultaker op 20-07-2009 15:29 ]

[veldsla]

Soultaker schreef op maandag 20 juli 2009 @ 15:07:
Wat betreft I/O is de truc in C om vooral niet zelf met carriage returns te gaan prutsen (zoals DirkW deed) maar gewoon bestanden in tekstmode moet openen (fopen(path, "rt"); en fopen(path, "wt");) dan gaat conversie van regeleindes vanzelf goed op alle platforms (Linux, Mac OS, Windows).

Ik heb geen enkele wijziging in mijn code hoeven maken om de boel onder Windows goed te laten werken (en kan zelfs crosscompilen voor Windows vanuit Linux) dus in principe hoef je gecompileerde talen vanwege platformverschillen niet links te laten liggen.

Point taken

[Pete]

NMe schreef op maandag 20 juli 2009 @ 10:29:

Anyway, als ik straks thuiskom heb ik even een half uurtje vrij voor het posten van de uiteindelijke scores. Ik moet de code review nog even afronden dus dat wordt later vanavond of morgenmiddag. Ik denk dat er wel een paar mensen blij gaan zijn met de nieuwe runs die ik gedaan heb.

Kun je al de scores posten? Of probeer je eerst veldsla's inzending nog werkend te krijgen?

[veldsla]

Ik heb mijn prog op mijn eigen bak gerund en de output opgestuurd. Mijn score komt 'ter info' ergens tussen staan. Ik haal toch geen top3 dus das geen probleem.

[.oisyn]

Dirk schreef op zondag 19 juli 2009 @ 13:50:
Grappig, dat moet dan aan de compiler liggen ofzo, want in mijn eigen outputbestand heb ik gewoon een enkele CR en LF.

ik gebruik ook het volgende simpele regeltje code om de boel te outputten:

C++:

fprintf (outputFile, "%u %u %c\x0D\n", x, y, dir);

Maar bij mij wordt die \n enkel naar een LF vertaald, dus ik heb er handmatig een CR aan toegevoegd.

Onder Windows wordt een \n bij een tekstfile omgezet naar \r\n (ja dat heet een \r, \x0d is wat overdreven ). Onder linux blijft het gewoon een \n, en op de Mac wordt het een \r. Tenzij je de files als binary opent, dan vindt er geen vertaling plaats.

[NMe]

Pete schreef op dinsdag 21 juli 2009 @ 18:24:
[...]

Kun je al de scores posten? Of probeer je eerst veldsla's inzending nog werkend te krijgen?

#	Naam	Score	Run tijd (minuten)	Ongeldige zet na	Totaal aantal zetten	Commentaar
1.	Pete	35.976.250	15		100.000	Niet met "java -Xms128m -Xmx2500m -server -jar jewelsmit.jar" gerund maar met "java -Xms128m -Xmx1500m -server -jar jewelsmit.jar"
2.	DaCoTa	35.896.350	15		100.000	Lagere score met server-VM.
3.	.oisyn	35.616.000	15		100.000
4.	Bomberboy/neonlamp	35.321.100	15		100.000
5.	Soultaker	33.124.300	15		99.998	Uit zichzelf gestopt, maar mist toch twee moves?
6.	dotcode	27.542.500	14		100.000
7.	TweakPino	27.284.500	15		92.900
8.	veldsla	25.304.700	?		100.000	Gerund vanaf een andere (Linux) pc omdat de Windows-compilatie niet wilde werken.
9.	.knop	23.849.900	11		100.000
10.	Eskimootje	20.982.650	15		100.000
11.	TheFoxNL	20.879.000	15		100.000
12.	zwippie	20.403.300	7		100.000	Invalide uitvoer.txt, per move stond de score erachter vermeld. Genoemde score is na het repareren van die uitvoer. Rerun in server-VM maakte de run 2 minuten sneller maar beïnvloedde de score niet.
13.	Arjan	19.982.450	15		100.000
14.	king_charles	19.491.000	15		100.000
15.	DirkW	19.309.050	15		100.000	Verkeerde enters in de uitvoer en moest opnieuw gecompileerd worden om in Windows te draaien
16.	KoW	11.519.100	15		100.000
17.	DCM360	1.191.600	1		7.878
18.	Megamind	67.050	15	777	8.916	Geeft wel aan klaar te zijn na 15 minuten, maar wil alsnog verder runnen. Programma aflsuiten werkt niet, moest het killen.
19.	BalusC	23.900	6	303	100.000	Eindsituatie die getoond wordt komt niet overeen met het inputspeelveld
20.	vistu	2.850	5	13	100.000
21.	compufreak88	2.150	15		100.000
22.	PinQ	0	0		0	Foutmelding in Windows, geen logging

[ Voor 9% gewijzigd door NMe op 21-07-2009 23:36 ]

[Soultaker]

NMe schreef op dinsdag 21 juli 2009 @ 23:00:

Naam	Score	Run tijd (minuten)	Ongeldige zet na	Totaal aantal zetten	Commentaar
DirkW	24.600	15	278	31.194	Verkeerde enters in de uitvoer en moest opnieuw gecompileerd worden om in Windows te draaien

Was dit nou de uitvoer die je hier postte? If so, dan kom ik toch op een iets heel anders uit?

[NMe]

Je hebt gelijk, fixed.

[Pete]

Wow, dat is leuk Ik had eigenlijk niet meer verwacht dat ik Dacota nog voorbij zou komen!

Interessant dat sommige code een slechtere score geeft op de server-vm!

NMe schreef op maandag 20 juli 2009 @ 10:29:
... Ik denk dat er wel een paar mensen blij gaan zijn met de nieuwe runs die ik gedaan heb.

Ik ben iig blij!!!

[ Voor 62% gewijzigd door Pete op 22-07-2009 05:16 ]

[Eskimootje]

Tiende plek, vind ik niet slecht aangezien ik niet zo vaak programmeer. Is in ieder geval een reden om de volgende keer weer mee te doen en mezelf te verbeteren.

[DaCoTa]

Jeuj nieuwe scores! Ik had al zoiets verwacht.

Wat gaat nu de uiteindelijke scorewaardering worden? Ik wil niet die oude koe weer uit de sloot trekken, maar ik kijk toch nog even naar het kadaver onder water. Beide tabellen heb een geldigheid, aangezien in beide tabellen iedereen met dezelfde settings gedraait heeft.

Ik zeg maar zo: Jury, maak er iets moois van. Ik vertrouw in jullie integriteit

[Pete]

Ik zie nu dat Dacota's originele score hoger was dan die van mij nu. Dan lijkt het me eerlijk dat voor iedereen de hoogste score aangehouden wordt. Mijn suggestie: Dacota op 1, Pete op 2


(Wat is de status voor de code reviews?)

[ Voor 11% gewijzigd door Pete op 22-07-2009 09:05 ]