Programming Contest Nieuwe Stijl: Contest 1 *uitslagen!*

[RobIII]

Aloys schreef op maandag 18 december 2006 @ 16:37:
(Of is deze vraag niet toegestaan?)

Ik verwacht niet dat je veel reactie hierop zult krijgen buiten "globale uitleg", maar die spreekt eigenlijk voor zich. Maar here goes:

Je moet gewoon een blokje op een zo goed mogelijke manier zien in te passen in het bestaande veld. De clue is natuurlijk het "zo goed mogelijk" gedeelte van die zin. Definieer "zo goed mogelijk" en je bent er Daarna is het een kwestie van blokjes 1 voor 1 "zo goed mogelijk" inpassen (evt. met een lookahead e.d.) en gaan.

[ Voor 11% gewijzigd door RobIII op 18-12-2006 16:46 ]

[DaCoTa]

Denk eens goed na hoe je het spelletje zelf zou spelen. Probeer daar een patroon in te zien. Zet dat in een kilometer if-then-else statements en je hebt je eerste A.I. geschreven

[ Voor 4% gewijzigd door DaCoTa op 18-12-2006 20:56 ]

[Aloys]

Dat lijkt me inderdaad wel een goed idee... Ik moet toch ergens beginnen . Verder ben ik geen programeer-noob. Maar ik heb gewoon nog nooit zulk soort dingen hoeven doen. Bedankt voor de reacties. Hopelijk zien jullie nog een progje van mij verschijnen.

[The Fox NL]

Zo, mijn validator is eindelijk klaar. Ik kan nu met de AI beginnen. Mijn validator is niet zo snel als die van TRRoads (mijne doet een paar seconden over de 6MB file), maar hij geeft wel de juiste antwoorden. Verder is mijn validator wat strenger, hij viel namelijk over de DEBUG regels in dat bestand, maar ja, dat zijn ook geen toegestane commando's natuurlijk .

[Bint]

The Fox NL schreef op zaterdag 23 december 2006 @ 23:03:
Zo, mijn validator is eindelijk klaar. Ik kan nu met de AI beginnen. Mijn validator is niet zo snel als die van TRRoads (mijne doet een paar seconden over de 6MB file), maar hij geeft wel de juiste antwoorden. Verder is mijn validator wat strenger, hij viel namelijk over de DEBUG regels in dat bestand, maar ja, dat zijn ook geen toegestane commando's natuurlijk .

negeer die dan ook

[Vaan Banaan]

Het valt me op, dat in game.txt van de 2 testsets de blokken 0 en 9 ongeveer 2 keer minder voorkomen dan de anderen (+/- 5600 t.o.v +/- 11000).
Is dat een foutje van een afronding, of moet ik bij 'random' rekening houden, dat sommige blokken veel vaker / minder langs kunnen komen dan anderen? Ik had namelijk wel een evenredige verdeling verwacht over 100.000 blokken.
RobIII in "Programming Contest Nieuwe Stijl: Contes..."
Vooral bij testset 1 is het crusiaal (IMO), omdat je met blok 9 juist die 5 rijen kan voltooien.

[RobIII]

Vaan Banaan schreef op woensdag 27 december 2006 @ 12:28:
Het valt me op, dat in game.txt van de 2 testsets de blokken 0 en 9 ongeveer 2 keer minder voorkomen dan de anderen (+/- 5600 t.o.v +/- 11000).
Is dat een foutje van een afronding, of moet ik bij 'random' rekening houden, dat sommige blokken veel vaker / minder langs kunnen komen dan anderen? Ik had namelijk wel een evenredige verdeling verwacht over 100.000 blokken.
RobIII in "Programming Contest Nieuwe Stijl: Contes..."
Vooral bij testset 1 is het crusiaal (IMO), omdat je met blok 9 juist die 5 rijen kan voltooien.

Je moet gewoon geen aannames doen wat betreft het aantal malen dat een blok voorkomt; in de uiteindelijke contest zouden we (bij wijze van natuurlijk) maar 3 blokjes kunnen gebruiken die 99% van de tijd voorkomen en de rest helemaal niet of zelden.

Het gaat er ook niet om ("cruciaal") dat je met dat ene blok toevallig 5 rijen kunt completeren; je moet gewoon met de gegeven blokkenset optimaal zien te scoren. Dat er toevallig een "lange van 5" tussen zit is leuk voor je score, maar ook zonder dat blok kun je voor een highscore gaan (ook al krijg je dan misschien geen complete 5 lijnen in 1 keer weggespeeld; als jij het niet kan kunnen andere deelnemers het namelijk ook niet en moet je dus gewoon de maximale score zien te persen uit wat je hebt).

[ Voor 21% gewijzigd door RobIII op 27-12-2006 13:31 ]

[Vaan Banaan]

Ok, sowieso tel ik de blokken toch wel, zodat mijn 'AI' tegen het eind met de blokken die nog over zijn, nog het maximale eruit probeert te halen. Maar door dat random ging ik er (misschien ten onrechte) van uit, dat het evenredig verdeeld zou zijn.
Dat er geen blok tussen zou kunnen zitten wat 5 rijen weg kan werken, had ik wel ingecalculeerd, alhoewel ik dat wel jammer zou vinden. Maar zoals je al meldt, blijft het toch voor alle deelnemers gelijk.

offtopic:
Nou, genoeg gepost. Ik ga weer verder prutsen, want ik kan nog niet eens een rij verwijderen. En ik wil eigenlijk voor 2007 minimaal een hele emmel output.txt voor testset 1 uit kunnen poepen.

[RobIII]

Vaan Banaan schreef op woensdag 27 december 2006 @ 14:06:
Maar door dat random ging ik er (misschien ten onrechte) van uit, dat het evenredig verdeeld zou zijn.

offtopic:
De test-sets zijn gegenereerd met een "effe vlug VB6 appje"
Het is al even geleden dat ik die sets genereerde en meen me iets te herinneren dat ik bepaalde blokken vaker heb laten voorkomen dan andere, maar anderzijds kan het ook gewoon liggen aan de (naar ik meen) brakke VB6 RNG
Hoe dan ook is het (in principe) niet interessant; er is immers (zo leerde ik onlangs) ook 54% kans op een meisje en 46% kans op een jongen (of was het andersom?) als je een kindje krijgt hoewel je toch gewoon 50/50 zou verwachten

Nog oftopic-er:
En die informatie blijkt niet eens te kloppen

[ Voor 14% gewijzigd door RobIII op 27-12-2006 14:38 ]

[.oisyn]

Vaan Banaan schreef op woensdag 27 december 2006 @ 12:28:
Het valt me op, dat in game.txt van de 2 testsets de blokken 0 en 9 ongeveer 2 keer minder voorkomen dan de anderen (+/- 5600 t.o.v +/- 11000).
Is dat een foutje van een afronding, of moet ik bij 'random' rekening houden, dat sommige blokken veel vaker / minder langs kunnen komen dan anderen? Ik had namelijk wel een evenredige verdeling verwacht over 100.000 blokken.

Een evenredige verdeling van een pure random functie is pas bij oneindig veel getallen - het kan natuurlijk gewoon voorkomen dat je 100.000 keer hetzelfde getal eruit krijgt. Net als dat je met een dobbelsteen ook 100.000 keer achter elkaar 6 kunt gooien. Goed, die kans is heel erg klein, maar dat wil niet zeggen dat het niet kan.

[ Voor 8% gewijzigd door .oisyn op 27-12-2006 19:01 ]

[H!GHGuY]

argh, had ik nou maar tijd!

Ik heb zo'n ideetje wat je een redelijke plaatsing op kan leveren
Elke opgevulde dot die naast het te plaatsen blokje ligt levert een pseudo score op. De rand telt hierin mee. Krijg je zeker in het begin en in randgevallen een beter aaneengesloten veld...

Misschien is het iets, doen jullie er maar iets mee als je kan...
Had ik nou maar tijd...

[The Fox NL]

H!GHGuY schreef op vrijdag 29 december 2006 @ 17:31:
argh, had ik nou maar tijd!

Ik heb zo'n ideetje wat je een redelijke plaatsing op kan leveren
Elke opgevulde dot die naast het te plaatsen blokje ligt levert een pseudo score op. De rand telt hierin mee. Krijg je zeker in het begin en in randgevallen een beter aaneengesloten veld...

Misschien is het iets, doen jullie er maar iets mee als je kan...
Had ik nou maar tijd...

Argh, hou je mond, dat idee had ik ook!

[.oisyn]

Euh, ik denk dat iedereen die iig al een oplossing heeft voor set 1 al zoiets heeft hoor

[ Voor 4% gewijzigd door .oisyn op 30-12-2006 14:59 ]

[zwippie]

Nog een paar weken en het is februari. Is er al een datum voor de finale bekend?

Mijn inzending zal wel geen klapper worden, maar goed.

Edit: Lezen, zwippie!

De sluitingsdatum van de contest is 1 februari 2007

Al moet er natuurlijk ook nog een datum voor de uitslag vast komen te staan, anders doen die luie modjes er weer maaanden over om alles na te kijken.

[ Voor 46% gewijzigd door zwippie op 02-01-2007 15:25 ]

[The Fox NL]

Zo, mijn eerste versie van de AI is klaar. Geen lookahead, enkel wat regeltjes.
Score op set 1:

code:

End of instructions
score: 2268400
blocksPlaced: 100000
total lines: 24121
total of 1 lines: 21861
total of 2 lines: 1063
total of 3 lines: 38
total of 4 lines: 5
total of 5 lines: 0
processing time: 0.625398 seconds

column height: 4,3,5,5,3,2,3,4,7,7,6,7,7,7,6,

Mijn schamele score op set 2:

code:

End of instructions
score: 3500
blocksPlaced: 110
total lines: 7
total of 1 lines: 5
total of 2 lines: 1
total of 3 lines: 0
total of 4 lines: 0
total of 5 lines: 0
processing time: 0.000955987 seconds

column height: 39,37,39,39,39,40,40,38,39,38,39,39,39,40,39,

Helaas is testset 2 nog te pittig voor mijn AI.

Ik hoop dat ik nog tijd heb voor een lookahead implementatie.

_edit:
Na een beetje spelen met de wegingen komt er een iets hogere score uit bij set 2:

code:

End of instructions
score: 8280
blocksPlaced: 283
total lines: 59
total of 1 lines: 45
total of 2 lines: 4
total of 3 lines: 2
total of 4 lines: 0
total of 5 lines: 0
processing time: 0.00492996 seconds

column height: 40,40,39,38,38,39,38,39,39,39,39,40,37,39,37,

[ Voor 19% gewijzigd door The Fox NL op 02-01-2007 23:21 ]

[Verwijderd]

-NMe- schreef op dinsdag 14 november 2006 @ 14:50:
Het aantal blokjes in dit bestand is in principe variabel, maar hou er rekening mee dat er een sequentie van wel 100.000 blokjes voor zou kunnen komen.

Mogen we hieruit opmaken dat 100.000 ook echt de bovengrens is? Zo niet, dan zou ik vanuit een praktisch oogpunt graag horen wat dan wél de bovengrens is. 10^6, 10^7, 2^32 of zelfs 2^64 ?

[RobIII]

Verwijderd schreef op zaterdag 06 januari 2007 @ 20:33:
[...]


Mogen we hieruit opmaken dat 100.000 ook echt de bovengrens is? Zo niet, dan zou ik vanuit een praktisch oogpunt graag horen wat dan wél de bovengrens is. 10^6, 10^7, 2^32 of zelfs 2^64 ?

Er is in pricipe geen bovengrens, maar als je daar programmeertechnisch moeite mee hebt anders mag je wat mij betreft 2^1024 aanhouden als bovengrens

Alle gekheid op een stokje; Veel meer dan 2Gb zal het niet worden (om voor de hand liggende redenen lijkt me zo). Het is natuurlijk de kunst om je programma dusdanig "slim" te maken dat het met een set van 1.000 blokjes overweg kan maar ook met (theoretisch) "onbeperkt".

[The Fox NL]

RobIII schreef op zaterdag 06 januari 2007 @ 21:25:
[...]

Er is in pricipe geen bovengrens, maar als je daar programmeertechnisch moeite mee hebt anders mag je wat mij betreft 2^1024 aanhouden als bovengrens

Alle gekheid op een stokje; Veel meer dan 2Gb zal het niet worden (om voor de hand liggende redenen lijkt me zo). Het is natuurlijk de kunst om je programma dusdanig "slim" te maken dat het met een set van 1.000 blokjes overweg kan maar ook met (theoretisch) "onbeperkt".

Je hebt de grens al op 2^31-1 gezet (max signed integer). 2^1024 zou wel een beetje te gek worden, ik heb nu al een 64-bits integer nodig om mijn score in op te slaan (mochten er sets zijn van 2^31-1 blokjes).

RobIII in "Programming Contest Nieuwe Stijl: Contes..."

[ Voor 5% gewijzigd door The Fox NL op 06-01-2007 21:56 ]

[EdwinG]

The Fox NL schreef op zaterdag 06 januari 2007 @ 21:55:
[...]


Je hebt de grens al op 2^31-1 gezet (max signed integer). 2^1024 zou wel een beetje te gek worden, ik heb nu al een 64-bits integer nodig om mijn score in op te slaan (mochten er sets zijn van 2^31-1 blokjes).

Wordt hier toch bevestigd? 2³¹ -1 is iets meer dan 2 miljard. En laat 2 miljard tekens a 1 byte/teken nou net 2 miljard bytes zijn (2 Gigabyte dus)

[The Fox NL]

EdwinG schreef op zaterdag 06 januari 2007 @ 22:10:
[...]

Wordt hier toch bevestigd? 2³¹ -1 is iets meer dan 2 miljard. En laat 2 miljard tekens a 1 byte/teken nou net 2 miljard bytes zijn (2 Gigabyte dus)

2^31-1 is iets specifieker.

[Verwijderd]

The Fox NL schreef op zaterdag 06 januari 2007 @ 21:55:
[...]


Je hebt de grens al op 2^31-1 gezet (max signed integer). 2^1024 zou wel een beetje te gek worden, ik heb nu al een 64-bits integer nodig om mijn score in op te slaan (mochten er sets zijn van 2^31-1 blokjes).

RobIII in "Programming Contest Nieuwe Stijl: Contes..."

2^31-1: check. Bedankt!
(Dit mag ook wel in de startpost.)

[.oisyn]

Waarom? Het slaat nergens op. Als je bang bent dat er bestanden gaan komen die je niet in een keer kunt laden moet je er maar gewoon voor zorgen dat je het niet in een keer hoeft te laden. Wat is er mis met het openen van een file en het bijhouden van een leespointer?

[KopjeThee]

Dit is een interessant probleem. Helaas heb ik geen tijd om op tijd een leuk algoritme te implementeren, maar ik wil jullie wel een paar ideetjes voorleggen (ben wel benieuwd of ze bruikbaar zijn).

Het meest voor de hand ligt een backtracking algoritme tot een bepaalde diepte (misschien tot +/- 10 blokjes vooruit haalbaar). Dan doe je de plaatsing die na 10 blokjes de hoogste score geeft.

Misschien moet er niet alleen gekeken worden naar de hoogste score na die 10 blokjes, maar kan er ook een soort "evaluatie" functie worden toegepast op die spelsituaties op de horizon van je lookahead. Die functie kan naar bepaalde eigenschappen van de situatie kijken die misschien wenselijk/onwenselijk zijn. (Hoe "vlak" de bovenkant van de situatie is bijvoorbeeld, en hoeveel onbereikbare gaten er zijn).

In de evaluatie kan je misschien nog wel gebruik maken van bepaalde eigenschappen van de blokjes die nog gaan komen. Misschien is er nog maar 1 type blokje die je situatie kan redden. Het kan dan nuttig zijn om te weten hoeveel blokjes er van elk type nog gaan komen in het spel. Op basis daarvan kan je schatten wat de kans is dat zo'n blokje nog op tijd komt.

[EdwinG]

.oisyn schreef op zondag 07 januari 2007 @ 02:13:
Waarom? Het slaat nergens op. Als je bang bent dat er bestanden gaan komen die je niet in een keer kunt laden moet je er maar gewoon voor zorgen dat je het niet in een keer hoeft te laden. Wat is er mis met het openen van een file en het bijhouden van een leespointer?

Daar zeg je me wat, ik heb de testset tot nu toe telkens in 1x ingelezen
Met de set van 100.000 is dat niet zo'n probleem, het script loopt nu in ieder geval niet vast op de geheugengrens.

[edit]
Na wat sleutelen vandaag, heb ik gemerkt dat ik niet erg zuinig met de systeembronnen omging. (Nu nog steeds verre van optimaal, denk ik.)
Heb nu bijna 2 seconden per blokje nodig, met een lookahead van 1.
Gelukkig kom ik niet in tijdsnood, aangezien mijn script na 822 blokken boven de 40 regels uitkomt.

[ Voor 21% gewijzigd door EdwinG op 07-01-2007 21:30 . Reden: toevoeging resultaten ]

[The Fox NL]

.oisyn schreef op zondag 07 januari 2007 @ 02:13:
Waarom? Het slaat nergens op. Als je bang bent dat er bestanden gaan komen die je niet in een keer kunt laden moet je er maar gewoon voor zorgen dat je het niet in een keer hoeft te laden. Wat is er mis met het openen van een file en het bijhouden van een leespointer?

Dat is het probleem niet bij mij, ik open die file gewoon met m'n ifstream en lees uit wat ik nodig heb. Tis meer voor de validators etc. Wil je de score bij gaan houden van een bestand van 2^1024 oid, dan heb je niet genoeg aan een 32/64 bits int.

[compufreak88]

Jammer dat er maar zo weinig gereageerd wordt de laatste tijd.

Ikzelf doe helaas niet mee, omdat ik te weinig tijd heb, maar ik vind het wel interessant om het te volgen.

[RobIII]

compufreak88 schreef op zondag 14 januari 2007 @ 19:59:
Jammer dat er maar zo weinig gereageerd wordt de laatste tijd.

Dat komt omdat we niet praten/overleggen maar devven

[compufreak88]

Vind ik jammer, want dan kunnen we het niet volgen . Noujah, dan bekijk ik de sources later maar.

[zwippie]

Hm, hier wordt er in ieder geval niet genoeg gedevt.

Mijn code er weer eens bij gepakt, maar om nieuwe geavanceerdere ideetjes te proberen moet ik toch eerst de 'raw speed' omhoog zien te krijgen. Mijn java progsel kan nu zo'n 40/45 duizend nieuwe velden per seconde genereren, blokje erin zetten en analyseren. Helaas is dat nog te weinig als je bijvoorbeeld verder vooruit wil gaan kijken of een heftigere analyse wil maken.

Is er iemand bezig met een Java progsel dat veel sneller is dan de mijne? Zo ja, roep een mooi getal en je hebt mij weer gemotiveerd om opnieuw hard aan de slag te gaan met dit project.

[RobIII]

zwippie schreef op maandag 15 januari 2007 @ 20:27:
Is er iemand bezig met een Java progsel dat veel sneller is dan de mijne? Zo ja, roep een mooi getal en je hebt mij weer gemotiveerd om opnieuw hard aan de slag te gaan met dit project.

250K

[zwippie]

RobIII schreef op maandag 15 januari 2007 @ 21:28:
[...]

250K

Kan niet! Onmogelijk!



_{ps: volgens mij ben jij meer into .net (al ben ik dan eigenlijk ook wel benieuwd naar échte cijfers)}

[CodeCaster]

Hè, wat vervelend... Ik had een beginnetje draaien, maar heb door drukte met school (Java projecten...) geen tijd meer om voor 1 februari met iets werkends voor de dag te komen. Jammer.

[Mithrandir]

40k dingen per seconde moet genoeg zijn. Je moet alleen zorgen dat je alle slechte oplossingen veel eerder wegsorteert.

Mijn ervaring is (ik studeer AI aan de UvA) dat je liever 40k blokjes kan controleren maar je ziet direct dat 60% van de mogelijke stappen geen goede oplossing is dan dat je maar 50% wegstreept maar 250k blokjes kan controleren per seconde.

[ Voor 3% gewijzigd door Mithrandir op 16-01-2007 00:17 ]

[DroogKloot]

Jep, dit soort tree-search AI staat of valt met de kwaliteit van de heuristiek om branches weg te snijden (maar je kunt ook vrolijk alles brute-forcen tot 1 of 2 dieptes minder, dat werkt meestal ook wel aardig ).

[Norjee]

Met 6 tentamens, 1 hertentamen * Norjee stupid, en ook nog een tussentijdse paper eind december en januari is het voor mij logisch dat die contest er bij blijft liggen.
Misschien maar beter ook, want ik heb er een week bijna 24/7 mee geknoeid, wat ook niet echt gezond was.
Misschien dat het me de laatste dagen van de maand nog lukt de python (iieeww) code om te zetten naar een echte taal, en anders who cares.. ik hoop wel dat de set blokjes waarmee de uiteindelijke tetris game gespeeld wordt na 1 februari bekend worden gemaakt zodat ik later, wanneer ik wel tijd heb, toch kan zien hoe mijn bijzonder wazige implementatie zich houdt

[ Voor 3% gewijzigd door Norjee op 17-01-2007 14:21 ]

[Gerco]

Ik ben er maar weer eens mee bezig gegaan, maar ik krijg het nog steeds niet voor elkaar om set 1 uit te spelen (kom tot 37000 blokjes) en mijn programma is veel te traag om vooruit kijken mogelijk te maken (dat krijg je als je overal een object van maakt he )

Nog maar eens verder prutsen. Winnen zat er toch al niet in, maar er is nog veel ruimte voor verbetering.

[Verwijderd]

Wow, ik zie dit ding nu pas! Ik zal eens kijken of ik snel wat in elkaar kan flanzen.

[H!GHGuY]

kunnen jullie progsels gebruik maken van dualcores??

[The Fox NL]

H!GHGuY schreef op zaterdag 20 januari 2007 @ 12:30:
kunnen jullie progsels gebruik maken van dualcores??

De mijne niet, en ik ga dat ook niet voor elkaar krijgen voor de deadline. Het is zelfs de vraag of ik nog tijd heb om look-ahead in te bouwen.

[Gerco]

Geen multithreading hier, al zou dat waarschijnlijk vrij eenvoudig in te bouwen zijn (alleen voor de lookahead). Veel zal ik er echter niet aan hebben, aangezien de snelheid mijn beperkende factor niet is. Het is de "intelligentie" die me opbreekt.

Het is anderen gelukt om set 1 uit te spelen zonder lookahead, dus mijn prog is gewoon nog niet slim genoeg

[edit]
Net een testset van 1 miljoen blokjes uitgespeeld met een lookahead van 1 blokje. Doet er alleen wel een beetje langer dan 2 uur over...

[edit2]
Yay!

code:

Pieces processed:            100000
Instructions processed:      634825
Pieces discarded:                 0
Pieces dropped:              100000
   No lines cleared:          77484
   Cleared 1 line(s):         20943
   Cleared 2 line(s):          1538
   Cleared 3 line(s):            34
   Cleared 4 line(s):             1
   Cleared 5 line(s):             0
Score:                      2290550

En ruim binnen de 2 uur. Volgende stap: Multithreading.

[ Voor 66% gewijzigd door Gerco op 22-01-2007 19:33 ]

[The Fox NL]

Crap, ik moet toch nog een lookahead gaan maken, wil ik nog een beetje hoog eindigen. Zonder lookahead kom ik maar tot 2,28 miljoen punten in testset 1 en 10250 punten in testset 2.

[RobIII]

Modbreak:

Attentie attentie: Hebben we in de
gaten dat de deadline in zicht is?

/exit projectmanager mode

[ Voor 40% gewijzigd door RobIII op 22-01-2007 23:00 ]

[Gerco]

Dat hebben we prima in de gaten RobIII, ik denk alleen dat door de 'eerste inzending telt' regel, veel mensen wachten tot het allerlaatste moment om de boel op te sturen

Multithreading is ingebouwd, maar erg veel winst behaalt het nog niet. Met 2 threads haal ik slechts 33% tijdwinst (15sec -> 10sec op een bepaalde test) en daarboven gaat de winst weer sterk omlaag. Ik draai het op een Dual Xeon HT, dus echte concurrency tot 4-5 threads zou steeds meer winst op moeten leveren.

Ik denk dat mijn tasks te kort zijn om echte winst te behalen. Iemand hier ideeën over? De gemiddelde task duurt zo'n 1-3 milliseconde, met uitschieters naar 10 en hoger. Dat is wat aan de korte kant idd.

[ Voor 12% gewijzigd door Gerco op 23-01-2007 00:00 ]

[Verwijderd]

/me heeft maakt te weinig tijd om zijn progsel af te bakken
Jammer maar helaas ... maar andere dingen zijn even belangrijker.

[Verwijderd]

Ik ga het prolly ook niet meer halen, heb er gewoon helemaal geen tijd voor gehad.

Om een of andere reden was m'n januari drukker als gemiddeld.

[NMe]

Gerco schreef op maandag 22 januari 2007 @ 23:39:
Dat hebben we prima in de gaten RobIII, ik denk alleen dat door de 'eerste inzending telt' regel, veel mensen wachten tot het allerlaatste moment om de boel op te sturen

Dat verwacht ik ook wel, maar mensen even extra op de deadline attenderen kan geen kwaad denk ik. We hebben nog maar een ruime week te gaan.

Verwijderd schreef op maandag 22 januari 2007 @ 23:52:
/me heeft maakt te weinig tijd om zijn progsel af te bakken
Jammer maar helaas ... maar andere dingen zijn even belangrijker.

Jammer, maar begrijpelijk. Overigens, als je wel iets hebt dat daadwerkelijk voldoet aan de gestelde eisen, maar misschien nog niet zo heel slim is, dan kun je het alsnog opsturen als je wil. Het kan, ook als het niet af is, leerzaam zijn voor anderen als de diverse oplossingen gepost worden. Uiteraard kunnen we dan ook bij je inzending erbij zetten dat je geen kans hebt gezien om hem af te maken.

[Marcj]

code:

Game over after 10434 rounds and 447.08 seconds
Nr of drops: 702080563
Flushing 35 fields
Current state:
|    #          |
|    ###        |
|    ###     # #|
|####### # # ###|
|## ############|
|############ ##|
|############## |
|###### ########|
|############ ##|
|############# #|
-----------------
Score: 396540
LowestClear: 10
Shift: 5  Rotate: 0
Cleared 5 lines: 79
Cleared 4 lines: 148
Cleared 3 lines: 78
Cleared 2 lines: 421
Cleared 1 lines: 1408
Cleared 0 lines: 8300

Ik heb mijn testrun op game 2 ff verder uitgetest en het gaat nu aardig vlot. Mijn implementatie is in Java en is nu multi-threaded (met 4 threads). Zoals je kunt zien doe ik zo'n 700M drops die ik allemaal bekijk en dat in 447 secs (dat is > 1,5M per sec op een X2 4200+ ). Hierbij kijkt mijn algoritme tot 7 stappen vooruit (op een slimme manier uiteraard ), en het resultaat mag er zijn. Ik ga de rest van de week de code nog een beetje opschonen etc., maar ik denk dat ik er niet al te veel meer aan wijzig.

ps. Ik heb zelf na iets meer dan 10.000 rounds gecancelled , dat duurt ook elke keer zo lang...

[EdwinG]

Ik ben absoluut niet goed bezig op het punt van snelheid, ik haal niet eens 1,5 blok/seconde, met een look-ahead van 1.
Waarschijnlijk heb ik het volledig verkeerd aangepakt.
Bij set2 haal ik overigens maar ca 200 blokjes.

[Gerco]

EdwinG: Waarin heb je het geschreven? Ik doe het Java en haal plm 25 blokjes/sec met een lookahead van 1 blokje. Snelheden als die van Marcj haal ik ook bij lange na niet (maar ik heb nog wel een paar optimalisaties in de hoge hoed zitten).

Er zit nog wat rek in, maar meer dan 50 blokjes/sec op een 2.4GHz P4 verwacht ik niet te halen (op een single core cpu, op een dual core haal ik 30-40% extra).

[edit]
Marcj: Ik haal plm 52000 drops/second op een 1.5GHz celeron mobile. Hoe krijg je het voor elkaar om zo vreselijk veel sneller te zijn? Ik wacht met smart op het aflopen van de contest, want die code *moet* ik zien

[ Voor 30% gewijzigd door Gerco op 24-01-2007 19:22 ]

[EdwinG]

Gerco schreef op woensdag 24 januari 2007 @ 10:52:
EdwinG: Waarin heb je het geschreven? Ik doe het Java en haal plm 25 blokjes/sec met een lookahead van 1 blokje. Snelheden als die van Marcj haal ik ook bij lange na niet (maar ik heb nog wel een paar optimalisaties in de hoge hoed zitten).

Er zit nog wat rek in, maar meer dan 50 blokjes/sec op een 2.4GHz P4 verwacht ik niet te halen (op een single core cpu, op een dual core haal ik 30-40% extra).

Ik heb het geschreven in PHP, op een Athlon 2600+ (Iets van 1.6GHz), Gelukkig heb ik ook nog enkele ideeën om alles wat sneller te krijgen.

[DaCoTa]

Ik krijg het niet voor elkaar om voor 1 feb mijn project in te leveren, ik heb geen vrije tijd meer om het af te kunnen ronden. Ik zal iig kijken of ik het as-is kan submitten.

[The Fox NL]

Gerco schreef op woensdag 24 januari 2007 @ 10:52:
[edit]
Marcj: Ik haal plm 52000 drops/second op een 1.5GHz celeron mobile. Hoe krijg je het voor elkaar om zo vreselijk veel sneller te zijn? Ik wacht met smart op het aflopen van de contest, want die code *moet* ik zien

Programma van Marcj:

code:

public static Tetris.main(String[] arg) {
  //JNI call naar supersnelle DLL geschreven in C
}

[Marcj]

The Fox NL schreef op woensdag 24 januari 2007 @ 20:24:
[...]


Programma van Marcj:

code:

public static Tetris.main(String[] arg) {
  //JNI call naar supersnelle DLL geschreven in C
}

Goed geschreven Java code hoeft nauwelijks langzamer te zijn dan C code. Waar denk ik de winst bij mij voornamelijk zit is het coderen van de velden en de manier waarop ik lijnen drop. Ik zal nog wat javadoc toevoegen voor de mensen die de code later willen lezen

[Gerco]

Marcj schreef op woensdag 24 januari 2007 @ 21:18:
Goed geschreven Java code hoeft nauwelijks langzamer te zijn dan C code.

Daar zit 'em de crux, denk ik

Ik heb nu de branching verminderd door wat optimalisaties, nu doorzoek ik vaak zelfs 30% minder mogelijkheden. Helaas is nu de multi cpu versie bijna precies even snel als de single core! Het multithreaden eist nu meer overhead dan het oplevert...

Vreemd genoeg staan tijdens het rekenen wel alle 4 de CPUs op 90% busy, maar haal ik toch zowat evenveel drops/sec als met een enkele CPU (die ook nog eens 1GHz langzamer is...).

Config	Threads	Drops/sec
1.5GHz Celeron mobile	1	49339
Dual 2.4GHz Xeon HT	1	47878
Dual 2.4GHz Xeon HT	2	67356
Dual 2.4GHz Xeon HT	4	65735

Hoe kom ik er nu achter waar de vertraging zit en waarom is de veel snellere CPU langzamer met 1 thread dan de langzame met 1 thread?

[ Voor 40% gewijzigd door Gerco op 24-01-2007 21:54 ]

[The Fox NL]

Marcj schreef op woensdag 24 januari 2007 @ 21:18:
[...]


Goed geschreven Java code hoeft nauwelijks langzamer te zijn dan C code. Waar denk ik de winst bij mij voornamelijk zit is het coderen van de velden en de manier waarop ik lijnen drop. Ik zal nog wat javadoc toevoegen voor de mensen die de code later willen lezen

Ik zit maar te dollen he! Eigenlijk zou je met Java zelfs sneller kunnen zijn als de VM platform/cpu specifieke optimalisaties inbouwt die je in een gecompileerd C programma niet zou hebben.

Gerco schreef op woensdag 24 januari 2007 @ 21:28:
[...]

Daar zit 'em de crux, denk ik

Ik heb nu de branching verminderd door wat optimalisaties, nu doorzoek ik vaak zelfs 30% minder mogelijkheden. Helaas is nu de multi cpu versie bijna precies even snel als de single core! Het multithreaden eist nu meer overhead dan het oplevert...

Vreemd genoeg staan tijdens het rekenen wel alle 4 de CPUs op 90% busy, maar haal ik toch zowat evenveel drops/sec als met een enkele CPU (die ook nog eens 1GHz langzamer is...).

Misschien elke thread iets meer werk laten doen voordat je weer gaat synchroniseren/scores vergelijken, of de load beter verdelen over de threads (misschien staan er 3 uit hun neus te vreten, terwijl er 1 hard bezig is.

[RobIII]

Gerco schreef op woensdag 24 januari 2007 @ 21:28:
Hoe kom ik er nu achter waar de vertraging zit en waarom is de veel snellere CPU langzamer met 1 thread dan de langzame met 1 thread?

Laat ik die open deur dan maar intrappen: Profilen

[NMe]

The Fox NL schreef op woensdag 24 januari 2007 @ 21:47:
Ik zit maar te dollen he! Eigenlijk zou je met Java zelfs sneller kunnen zijn als de VM platform/cpu specifieke optimalisaties inbouwt die je in een gecompileerd C programma niet zou hebben.

Platformspecifiek kan nog wel inderdaad, maar CPU-specifiek kun je het programma voor deze contest maar beter niet maken, denk ik.

[zwippie]

-NMe- schreef op donderdag 25 januari 2007 @ 13:07:
[...]

Platformspecifiek kan nog wel inderdaad, maar CPU-specifiek kun je het programma voor deze contest maar beter niet maken, denk ik.

Stik, jullie hebben niet eens een Intel 4004 liggen? Kan ik weer overnieuw beginnen!

Serieus: Ik heb gemerkt dat Java 6.0 best wel wat sneller is dan 1.4 of 5.0, is dat een probleem om te installeren?

[Marcj]

zwippie schreef op donderdag 25 januari 2007 @ 15:06:
[...]
Serieus: Ik heb gemerkt dat Java 6.0 best wel wat sneller is dan 1.4 of 5.0, is dat een probleem om te installeren?

Ik hoop het niet. Mijn programma run ik ook onder Java 6 en dan ook nog met de -server parameter. Dit scheelt toch behoorlijk in performance. Ook hoop ik dat ik kan rekenen op minimaal een dual core, ander red ik het denk ik niet in 2 uur...

ps. Ik heb net even een profiler gerunned en mijn algoritme heeft van de multithreading ongeveer 20% overhead, wat allemaal zit in de main-thread die wacht op de rekenthreads daar onder. Dit valt mij eigenlijk nog best mee.

ps. Wie heeft de 4 miljoen punten grens bij de 2e testset al doorbroken?

[Verwijderd]

Gerco schreef op woensdag 24 januari 2007 @ 21:28:
[...]
Config Threads Drops/sec
1.5GHz Celeron mobile 1 49339
Dual 2.4GHz Xeon HT 1 47878
Dual 2.4GHz Xeon HT 2 67356
Dual 2.4GHz Xeon HT 4 65735

Hoe kom ik er nu achter waar de vertraging zit en waarom is de veel snellere CPU langzamer met 1 thread dan de langzame met 1 thread?

Celeron Mobile heeft volgens mij geen P4 maar een PIII als basis.

Een P4 heeft een langere instruction pipeline (heet anders volgens mij, maar ben de term vergeten) en kan daarom slechter omgaan met veel jumps in je code, omdat die vrijwel alle instructies in de pipeline weg kan gooien en alles opnieuw moet gaan laden.

Daarom is de Core Duo ook op de PIII architectuur gebaseerd, en niet op die van de P4. De P4 was eigenlijk een slecht ontwerp, puur gericht om hoge snelheid in GHz te halen. Toen de fysieke problemen van een hoge klok (hoog enegiegebruik) duidelijk werden, werd het ontwerp van de P4 ook direct bij het afval gezet.

[roy-t]

Mooie getallen allemaal hier, zelf moest ik een databaseproject afleveren dus heb ik ook niet genoeg tijd gehad in Januari om echt wat werkends te maken (plus dat ik eigenlijk C# ook nog aan het leren ben en dat de VWO eindexamens er aan komen.. )

Maar ik hoop eigenlijk dat we hierna meteen weer zo'n brilliante programming contest krijgen, met weer een deadline van 2maanden! Zijn jullie al weer aan het nadenken, want volgens mij is dit toch wel een redelijk succes!

[Gerco]

Ik heb mijn inzending opgestuurd. Niet op het allerlaatste moment, maar ik krijg van de week toch geen tijd meer om eraan te werken. Beter te vroeg dan te laat dan maar.

Ik kijk al reikhalzend uit naar de volgende contest, puik werk mods!

[edit]
.tar.bz2 geld toch ook wel als "zip of rar" ?

[ Voor 10% gewijzigd door Gerco op 28-01-2007 23:06 ]

[RobIII]

Gerco schreef op zondag 28 januari 2007 @ 22:35:
Ik kijk al reikhalzend uit naar de volgende contest, puik werk mods!

therat10430 schreef op zondag 28 januari 2007 @ 21:41:
Maar ik hoop eigenlijk dat we hierna meteen weer zo'n brilliante programming contest krijgen, met weer een deadline van 2maanden! Zijn jullie al weer aan het nadenken, want volgens mij is dit toch wel een redelijk succes!

Er zit al weer een leuk idee in de pijplijn (bij mij althans ). Dat zal na deze contest even intern besproken worden waarna we (waarschijnlijk) weer een nieuwe contest lanceren

[Marcj]

Mijn programma is ook zojuist ingeleverd. Ik vond hem wel goed genoeg en ik heb zelfs tijd gehad om javadoc overal toe te voegen

ps. Ik kwam er achter dat het verschil qua performance van mijn programma nogal verschil uitmaakte als je de Server VM gebruikt (met de -server optie van java.exe).

Hier is het aantal zetten dat ik nu in 2 uur ongeveer kan uitrekenen (geschat, met een look-ahead van 9).

Zetten per 2 uur	Java 5	Java 6
Client VM	160.000	180.000
Server VM	300.000	320.000

Ik hoop dat de mods hier ook rekening mee houden, want zo kan natuurlijk veel meer in 2 uur uitgerekend worden.

edit:

Klikken voor alle resultaten Iemand die het wil valideren?

[ Voor 9% gewijzigd door Marcj op 29-01-2007 01:20 ]

[NMe]

RobIII schreef op zondag 28 januari 2007 @ 23:02:
Er zit al weer een leuk idee in de pijplijn (bij mij althans ). Dat zal na deze contest even intern besproken worden waarna we (waarschijnlijk) weer een nieuwe contest lanceren

offtopic:
Even geen zin om dit in het crewtopic te gaan quoten (teveel werk ), maar je hóéft niet te wachten tot na deze contest hoor. Hoe sneller we dat rond hebben, hoe eerder contest 2 op poten is.

[EdwinG]

/me heeft zijn progsel ook ingestuurd
Ook ik zie geen kans meer op verbeteringen. Ik weet nog wel een stukje code die ik weg kan laten, wat het geheel een stuk sneller maakt, maar dan gaan de resultaten enorm achteruit.

Wel raar, iets wat eigenlijk een bug was, zorgde voor een betere score. Dus heb ik die maar laten zitten

[Gerco]

Ach EdwinG, ik had nog een heleboel kunnen doen om de resultaten te verbeteren. Als ik dat hier zo zie met 9 blokjes vooruit kijken vraag ik me af: Waar ben ik de fout in gegaan? Ik wacht met smart de resultaten af, dat wordt een leermomentje.

Het leuke van mijn code is wel dat hij elke keer dat je hem draait andere resultaten geeft (alleen op een multicore/cpu systeem, dat is overigens geen bug). Misschien heb ik wel mazzel tijdens de testrun, maar ik verwacht niet meer dan een paar honderd moves te kunnen doen in de standaardconfig.

De jury zal wel blij met me zijn, ze hoeven iig geen twee uur naar mijn prog te zitten kijken, eerder 20 seconden

[Marcj]

Gerco schreef op maandag 29 januari 2007 @ 09:55:
Ach EdwinG, ik had nog een heleboel kunnen doen om de resultaten te verbeteren. Als ik dat hier zo zie met 9 blokjes vooruit kijken vraag ik me af: Waar ben ik de fout in gegaan? Ik wacht met smart de resultaten af, dat wordt een leermomentje.

Het leuke van mijn code is wel dat hij elke keer dat je hem draait andere resultaten geeft (alleen op een multicore/cpu systeem, dat is overigens geen bug). Misschien heb ik wel mazzel tijdens de testrun, maar ik verwacht niet meer dan een paar honderd moves te kunnen doen in de standaardconfig.

De jury zal wel blij met me zijn, ze hoeven iig geen twee uur naar mijn prog te zitten kijken, eerder 20 seconden

Als hij alleen op een multi-core systeem elke keer andere resultaten geeft, dan heb je duidelijk niet goed gesynchronizeerd. Een computer zal met dezelfde input altijd dezelfde output geven, tenzij timing en meerdere processen elkaar gaan dwars zitten. Dan kun je semi-random resultaten krijgen.

[Gerco]

Marcj schreef op maandag 29 januari 2007 @ 13:12:
Een computer zal met dezelfde input altijd dezelfde output geven, tenzij timing en meerdere processen elkaar gaan dwars zitten.

Het is timing en dat heb ik expres zo gelaten. Wanneer twee of meer threads met een best move komen die beiden dezelfde score hebben, pakt 'ie at random 1 van die resultaten om mee verder te rekenen. Niet de optimale strategie natuurlijk, maar ik had geen zin om het anders op te lossen

Mijn oplossing is ook meer een tetris game met een AI speler implementatie. Niet een hardcore dedicated rekenprog. Je kan er met weinig tot geen moeite een interactieve game van maken. Die architectuur zal me in de resultaten wel opbreken aangezien hij voor dit probleem niet 100% geschikt is, maar het was de bedoeling om te leren van het programmeren en dat heb ik wel bereikt denk ik zo.

[ Voor 27% gewijzigd door Gerco op 29-01-2007 13:17 ]

[Marcj]

Gerco schreef op maandag 29 januari 2007 @ 13:15:
[...]

Het is timing en dat heb ik expres zo gelaten. Wanneer twee of meer threads met een best move komen die beiden dezelfde score hebben, pakt 'ie at random 1 van die resultaten om mee verder te rekenen. Niet de optimale strategie natuurlijk, maar ik had geen zin om het anders op te lossen
[..]

Zolang je maar weet waarom hij dat doet en zeker weet dat er geen problemen kunnen optreden, hoeft het natuurlijk niet fout te zijn. Zoals jij het beschrijft kan ik het me wel voorstellen dat het goed zal gaan En veel optimaler zal het niet zijn als hij altijd dezelfde pakt, omdat hij toch niet kan weten welke van de beste scores ook echt de beste is. Echter is die van mij wel volledig gesynchronizeerd, waardoor hij altijd de eerste met de hoogste score pakt.

[Gerco]

Marcj schreef op maandag 29 januari 2007 @ 13:22:
Echter is die van mij wel volledig gesynchroniseerd, waardoor hij altijd de eerste met de hoogste score pakt.

Ik vond het wel leuk om het "mazzel" element erin te houden, eerlijk gezegd Overigens pakt de mijne ook altijd dezelfde, namelijk de laatste die klaar is. Dat is echter niet altijd dezelfde thread en dus geeft hij soms een ander resultaat.

Op een single core systeem zal hij altijd hetzelfde resultaat geven, want dan spawnt 'ie geen meerdere rekenthreads en is het resultaat deterministisch.. Het heeft me wel even gekost om uit te vinden waarom 'ie dat deed overigens. Ik dacht dat ik een threadingbugje had waarbij ik een per ongeluk gedeelde variabele zat te clobberen oid.

[ Voor 12% gewijzigd door Gerco op 29-01-2007 13:40 ]

[Vaan Banaan]

Ik zal proberen woensdag nog een werkende wip in te leveren. Meer zit er voor mij helaas niet in.
Eind december / heel januari eigenlijk niet kunnen programmeren door drukte op het werk en sociale verplichtingen doordeweeks en in het weekend.
Maar goed, die 4 miljoen van Marcj: Dat ga ik never nooit niet voor elkaar krijgen.
• To do: debuggen, outputfile, vooruitkijken (wishfull thinking).
• Will never be done: tijdbewust maken, optimalisatie, documentatie, code begrijpelijk maken / herschrijven.
Ja ik ben echt al heel ver gevorderd. Wel een paar honderd blokjes met testset1
Maar goed, ik heb dit project ook gebruikt om C (weer) te leren. Na ruim een maand eindelijk een gratis compiler met IDE gevonden voor mijn Windows98 bakeliet, waarmee ik de debugger kon gebruiken. Eerst MinGW met Visual MinGW geprobeerd, wat een drama (alpha 0.56, lekker stabiel, debuggen gaat zo goed als niet) nog een tijdje met Cygwin lopen kloten, maar dat was bij mij niet vooruit te branden. Eclipse met CDT kreeg ik niet aan de praat. Nu ben ik met Code::Blocks bezig, dat bevalt me een stuk beter.
Aan het volgende project ga ik ook zeker meedoen en ik hoop dat dat minder stroef begint dan nu.
Gerco: ik ga denk ik nog van je winnen met binnen 1 seconde game over
-edit-
WOEHOE, debuggen en outputfile is al gelukt, ik haal met testset 2 wel 86 blokjes!
En de outputfile valideert ook nog eens (tenmiste volgens de online validator van Creepy)
Ja mensen, ik heb nog hoop.

offtopic:
dat ik 100 blokjes haal

[ Voor 10% gewijzigd door Vaan Banaan op 29-01-2007 22:51 ]

[The Fox NL]

Ik ga mijn werk ook inleveren. Geen tijd meer gehad om een lookahead in te bouwen, dus gewoon een AI die het blokje zo 'slim' mogelijk probeert te plaatsen.

Met het huidige progsel haal ik een max score van 10250 uit testset 2, waar ik 3000 seconden over doe (AMD64 3500+). Testset 1 haalt iets van 2,8 miljoen, maar kan misschien hoger op een snellere computer.

[pietje63]

EdwinG schreef op maandag 29 januari 2007 @ 09:42:
/me heeft zijn progsel ook ingestuurd
Ook ik zie geen kans meer op verbeteringen. Ik weet nog wel een stukje code die ik weg kan laten, wat het geheel een stuk sneller maakt, maar dan gaan de resultaten enorm achteruit.

Wel raar, iets wat eigenlijk een bug was, zorgde voor een betere score. Dus heb ik die maar laten zitten

That's nog a bg, that's a feature!

* pietje63 hoopt dat de volgende contest iets is waar ik ook iets inhoudelijks van snap, want dat wilt niet erg lukken. Misschien is het btw wel leuk om de winnaar een review te laten schrijven op de fp, dat is meteen een mooie aankondiging voor een eventuele volgende contest.

[NMe]

pietje63 schreef op dinsdag 30 januari 2007 @ 10:45:
* pietje63 hoopt dat de volgende contest iets is waar ik ook iets inhoudelijks van snap, want dat wilt niet erg lukken.

Je snapt deze contest inhoudelijk niet? Waarom heb je het je dan niet laten uitleggen?

Misschien is het btw wel leuk om de winnaar een review te laten schrijven op de fp, dat is meteen een mooie aankondiging voor een eventuele volgende contest.

Ik denk niet dat het redactieteam daar echt op zit te wachten; sowieso is het niet bepaald wereldnieuws. Ik denk dat we dit beter gewoon binnen de hoofdgroep kunnen houden, maar het staat jullie natuurlijk vrij om zelf reclame te maken op andere sites (binnen de daar geldende regels!) om zo een hogere opkomst te krijgen. Al ben ik momenteel blij verrast door het aantal inzendingen; er zijn er nu bijna een handvol binnen, en dat terwijl ik de eerste inzending niet verwacht had vóór morgenmiddag, 12 uur voor de deadline.

[EdwinG]

-NMe- schreef op dinsdag 30 januari 2007 @ 12:51:
"..."
Al ben ik momenteel blij verrast door het aantal inzendingen; er zijn er nu bijna een handvol binnen, en dat terwijl ik de eerste inzending niet verwacht had vóór morgenmiddag, 12 uur voor de deadline.

Als het bij dit aantal blijft, eindig ik in ieder geval in de top 10

[pietje63]

-NMe- schreef op dinsdag 30 januari 2007 @ 12:51:
[...]

Je snapt deze contest inhoudelijk niet? Waarom heb je het je dan niet laten uitleggen?

Ik bedoelde meer dat ik nog nooit iets AI achtig gedaan heb.. Van de andere kant snap ik wel dat als je een contest doet je snel die kant op gaat (want dat is vaak redelijk objectief te meten).

[...]

Ik denk niet dat het redactieteam daar echt op zit te wachten; sowieso is het niet bepaald wereldnieuws. Ik denk dat we dit beter gewoon binnen de hoofdgroep kunnen houden, maar het staat jullie natuurlijk vrij om zelf reclame te maken op andere sites (binnen de daar geldende regels!) om zo een hogere opkomst te krijgen. Al ben ik momenteel blij verrast door het aantal inzendingen; er zijn er nu bijna een handvol binnen, en dat terwijl ik de eerste inzending niet verwacht had vóór morgenmiddag, 12 uur voor de deadline.

Ja, zit wat in, ik zit inderdaad ook niet te wachten over een review over de mooiste case-mod o.i.d., maar ben wel geinteresseerd in hoe iemand zijn programma straks gemaakt heeft. Waar hij (zij?) mee begint, wat daarna verbeterd werd etc.

[EdwinG]

* EdwinG herinnert iedereen er nog eens aan:
Tijd tot de deadline: 5:19

Wie hebben er allemaal al iets ingestuurd, en wie doen dat vanavond nog?

[Soultaker]

Hmm, ik heb er al tijden niets meer aan gedaan, en er nu ook niet meer zoveel tijd voor. Ik zal voor m'n huidige versie nog wel opsturen, maar veel kans maak ik niet, want ik kan set 2 nog niet eens oplossen. (Maar is natuurlijk niet leuk voor de andere deelnemers om niets in te zenden...)

[.oisyn]

Oh ja, die contest

[zwippie]

Oef, ik wil het zeker nog opsturen vanavond, maar weet wel zeker dat het een flop gaat worden... Het resultaat zal echt in grote mate door de blokkenset bepaald worden. Iets als testset 1 doet ie prima al is het geen topscore, testset 2 is een drama.

[Marcj]

.oisyn schreef op woensdag 31 januari 2007 @ 20:33:
Oh ja, die contest

Tja, je hebt nog iets meer dan 2 uur om het in te leveren. Je had toch al wel iets wat goed werkte?

[zwippie]

Ja inderdaad .oisyn, jij was een van de eersten die iets behoorlijks gemaakt had. Ik ben zeker benieuwd naar de resultaten van jou en van marcj. Tis maar een contestje he.

[.oisyn]

Marcj schreef op woensdag 31 januari 2007 @ 21:53:
[...]

Tja, je hebt nog iets meer dan 2 uur om het in te leveren. Je had toch al wel iets wat goed werkte?

Ja klopt, ik was met sommige punten echter nog niet tevreden. En m'n code is momenteel nogal een zooitje. En ik heb inmiddels een verse windows xp install en nog geen visual studio geinstalleerd . Eens kijken of ik de boel weer kan aanslingeren voor 0:00.

[Soultaker]

En als je geen inzending doet nadat je ons eerst allemaal lekker hebt zitten maken met allerlei geweldige scores, dan draag ik je voor voor een ban, want dat kan natuurlijk echt niet.

[.oisyn]

VS is al geïnstalleerd (handig als je de dvd iso gewoon op je hdd hebt staan )

[Marcj]

.oisyn schreef op woensdag 31 januari 2007 @ 22:43:
VS is al geïnstalleerd (handig als je de dvd iso gewoon op je hdd hebt staan )

1 uurtje code opschonen en dan hopen dat alles nog werkt? Hopelijk kun je wel iets inleveren

[zwippie]

Argh, snel even ergens anders laten testen brengt alweer een probleem naar voren: ik heb de code uit laten poepen als Java 6.0 class files. Ik weet dat ik het ook wel snel even als 5.0 kan uitspugen, maar met nog 20 minuten te gaan en de goeie snelheid van java 6, hoop ik maar dat de heren scheidsrechters de moeite willen nemen om de laatse JRE te installeren. Alles is nu iig de deur uit.

[.oisyn]

Zo, gemailed, net op de valreep . Ook nog even een bug gefixed

[RobIII]

1 minuut

[RobIII]

TIJD! TUUT
Alle inzendingen na deze post hebben vette pech

[ Voor 7% gewijzigd door RobIII op 01-02-2007 00:01 ]

[.oisyn]

* .oisyn doet een dansje

[Marcj]

En nu wachten op de resultaten. RobIII: enig idee hoe lang de tests gaan duren? En hoeveel inzendingen heb je eigenlijk ontvangen?

[RobIII]

Marcj schreef op donderdag 01 februari 2007 @ 00:07:
En nu wachten op de resultaten. RobIII: enig idee hoe lang de tests gaan duren? En hoeveel inzendingen heb je eigenlijk ontvangen?

To be honest: Ik zit nog op mijn werk en heb dus geen idee hoeveel inzendingen we (in totaal) binnen hebben. Zo uit mijn hoofd zijn het er toch wel 5 tot 7.

Hoe lang het gaat duren? Tja, ook wij zijn devvers en doorgaans nemen wij het niet zo nauw met deadlines als jullie "users"

[.oisyn]

De vorige contest kwam niet van de grond. Deze contest had zowaar een deadline met entries, maar zal geen uitslag hebben. De volgende contest zal het daadwerkelijk helemaal tot het eind halen

[Verwijderd]

Ook al had ik geen tijd voor een entry deze keer, volgende keer zal ik zeker wel mee proberen te doen. ook ben ik wel schieuwnierig naar de oplossingen in deze contest, hoewel ik vermoed dat ik na mijn vakantie pas wat uitslagen zal kunnen zien.

[Marcj]

RobIII schreef op donderdag 01 februari 2007 @ 00:11:
[...]

To be honest: Ik zit nog op mijn werk en heb dus geen idee hoeveel inzendingen we (in totaal) binnen hebben. Zo uit mijn hoofd zijn het er toch wel 5 tot 7.

Hoe lang het gaat duren? Tja, ook wij zijn devvers en doorgaans nemen wij het niet zo nauw met deadlines als jullie "users"

Bij deze zetten we een deadline voor jullie: 7 februari 0:00 moeten de uitslagen hier staan

[cobratbq]

Bij deze zetten we een deadline voor jullie: 7 februari 0:00 moeten de uitslagen hier staan

2009?
In dat geval kan ik ook nog wel een poging wagen .

Iig kijk ik uit naar de volgende wedstrijd en 'k ben van plan om dan ook mee te doen.

[eamelink]

Ik heb een redelijk werkende Tetris; maar ik genereerde nog geen output en had geen tijd om het af te maken . Ik heb hem dan ook niet ingestuurd

Maar ik heb wel enorme lol gehad tijdens het maken en ik wil de organisatoren dan ook hartelijk danken

Voor een eventuele volgende contest zou ik toch willen suggereren om de tijd iets korter te maken, bijvoorbeeld een week of 3. In 3 weken zullen de meeste mensen best genoeg tijd moeten hebben om iets in elkaar te zetten, en anders niet; het is ook niet erg om een contest te missen natuurlijk. Het voordeel lijkt me wel dat er wat meer actie in de brouwerij is en dat het niet zo dood valt zoals het hier wel nogal doodviel na de eerste twee weken

[EdwinG]

Mij lijkt de tijd die voor deze contest gegeven was een prima tijd. Zelf heb ik over de gehele periode verspreid aan mijn AI geknutseld, en verschillende dingen geleerd.

Ik denk dat met slechts 3 weken als de duur van een contest, het aantal deelnemers gehalveerd zou zijn.