Programming Contest Nieuwe Stijl: Contest 1 *uitslagen!*

[NMe]

Marcj schreef op donderdag 01 februari 2007 @ 07:44:
Bij deze zetten we een deadline voor jullie: 7 februari 0:00 moeten de uitslagen hier staan

Ik denk dat ik namens iedereen spreek als ik zeg dat we ernaar streven binnen een week een uitslag klaar te hebben. Uiterlijk 8 februari om 0:00 dus, maar aangezien we daar geen afspraken over gemaakt hebben beloof ik niets.

eamelink schreef op donderdag 01 februari 2007 @ 14:36:
Maar ik heb wel enorme lol gehad tijdens het maken en ik wil de organisatoren dan ook hartelijk danken

\o/

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.

Dat is waar, maar aan de andere kant zien we natuurlijk wel zoveel mogelijk entries. Ik heb hier zeker 3 à 5 mensen horen roepen dat ze niet genoeg tijd hadden, terwijl er stiekem eigenlijk best wel wat weekjes voor uitgetrokken waren. 3 weken is gewoon vrij kort voor mensen met een baan of een studie erbij, en ook die mensen willen we graag bij de contests betrekken.

[zwippie]

De contest was inderdaad erg leuk om te doen, dank organisators!
De duidelijke deadline was zeker een verbetering ten opzichte van de vorige contest.

Wat mij betreft hoeft het niet veel korter te duren dan nu. Je ziet duidelijk 2 pieken qua actie, eentje in het begin en eentje een week voor de sluitingsdatum.
3 Weken lijkt me net iets te kort, voor veel mensen zal dat 3 weekenden inhouden. Het was nu ongeveer 10 weken. Iets daar tussen in lijkt me goed te doen.

Op naar de volgende contest! Kun je al een kleine hint geven over wat je voor ons in gedachten had, Rob?

[Megamind]

Ik wilde ook graag mee doen aan deze wedstrijd, maar veel te hoog gegrepen voor me dus ik wacht rustig af voor de volgende wedstrijd. Een iets kortere tijd zou idd leuker zijn, die gasten die altijd die 3D plaatjes maken die wisselen ook elke week zowat van wedstrijd...

[Bolukan]

Zet de bestanden niet ergens publiek neer voordat de sluitingsdatum is bereikt, om het zo voor iedereen leuk te houden. Stuur bovendien geen code op waar je niet 100% achter staat.

De sluitingsdatum is bereikt. Dus kom maar op slimmeriken! Ik neem graag kennis van jullie aanpak, problemen en oplossingen.
Hoewel ... laten we de laatste regel van het citaat in ere houden.

[RobIII]

Bolukan schreef op donderdag 01 februari 2007 @ 15:28:
[...]
De sluitingsdatum is bereikt. Dus kom maar op slimmeriken! Ik neem graag kennis van jullie aanpak, problemen en oplossingen.
Hoewel ... laten we de laatste regel van het citaat in ere houden.

Wij (crew) zullen er voor zorgen dat de entries online worden gezet

[EdwinG]

Ik zal, zodra ik thuis ben, mijn broncode (uitgebreide versie) online zetten. De ingestuurde versie is namelijk ontdaan van alle echo/print gegevens en debug informatie.

[Soultaker]

eamelink schreef op donderdag 01 februari 2007 @ 14:36:
Maar ik heb wel enorme lol gehad tijdens het maken en ik wil de organisatoren dan ook hartelijk danken

Hierbij wil ik me aansluiten. Hardstikke leuk, en nog leerzaam ook (voor het eerst een GUI met Xlib geprogrammeerd, bijvoorbeeld).

Overigens vind ik twee maanden (het was nu iets meer) wel een mooie termijn; dan heb je ook gelegenheid om mee te doen als je tussendoor wat minder tijd hebt, en je kunt nog eens wat zaken in detail uitzoeken of opnieuw implementeren, zonder in grote tijdnood te komen.

[NMe]

RobIII schreef op donderdag 01 februari 2007 @ 15:33:
[...]

Wij (crew) zullen er voor zorgen dat de entries online worden gezet

Inderdaad. Ze staan nu in -NMe- in "Programming Contest Nieuwe Stijl: Contes...". Uiteraard zonder verdere uitslagen, die komen later. De txt-bestanden worden ook z.s.m. vrijgegeven.

[Gerco]

De tijd vond ik precies goed. Met een baan ernaast is het soms lastig tijd maken en het is heel goed mogelijk dat je 3-4 weken achter elkaar weinig tot geen tijd/zin/puf hebt om eraan te werken. 2 maanden vind ik een hele goede tijdsduur.

Nogmaals mijn complimenten voor de jury, ik heb me erg geamuseerd tijdens deze contest.

[edit]
Woei! We staan allemaal in de top 10

[ Voor 7% gewijzigd door Gerco op 01-02-2007 18:31 ]

[Verwijderd]

Gerco schreef op donderdag 01 februari 2007 @ 18:28:
De tijd vond ik precies goed. Met een baan ernaast is het soms lastig tijd maken en het is heel goed mogelijk dat je 3-4 weken achter elkaar weinig tot geen tijd/zin/puf hebt om eraan te werken. 2 maanden vind ik een hele goede tijdsduur.

Eensch is

Overigens kan ik me voorstellen dat enkele eenvoudiger opgaves voor beginners ook leuk kunnen zijn, maar dan krijg je dat de gevorderden er alsnog overheen denderen. Overigens zijn hier wel wat leuke programmeeropgaven te vinden: http://acm.uva.es/problemset/

[The Fox NL]

AI, zie ik daar tot mijn grote schrik een bug in mijn code zitten... Nu maar hopen dat de omstandigheden er niet naar zijn dat die optreed. Niet dat ik zonder die bug ga winnen trouwens..

[NMe]

Wie weet. Ik ben momenteel begonnen aan het runnen van ieder's code; de resultaten van de eerste persoon heb ik over een klein kwartier. Het ziet ernaar uit dat de door ons geselecteerde blokjes nog best lastig zijn, althans voor deze AI. Dat betekent helaas voor mij wel dat die 2 uur per inzending wel eens bij iedereen nodig zullen gaan zijn; 16 uur testsets draaien, woei.

[Soultaker]

Lijkt me dat als de test set lastig is, mensen juist sneller dood gaan, of niet? Dat is bij mij in ieder geval wel zo; ik ben in een paar minuten af in test set 2, maar test set 1 duurt nog behoorlijk lang.

Overigens geldt voor mijn code dat vooral de symmetrie van de blokjes bepalend is voor de spelduur. Ingewikkelde blokjes genereren meer mogelijke plaatsingen.

Verwijderd schreef op donderdag 01 februari 2007 @ 20:48:
Overigens kan ik me voorstellen dat enkele eenvoudiger opgaves voor beginners ook leuk kunnen zijn, maar dan krijg je dat de gevorderden er alsnog overheen denderen.

Misschien dan twee sets maken; een makkelijke en een moeilijke, en mensen laten kiezen aan welke ze willen meedoen? Dan moet het probleem zich er wel een beetje voor lenen natuurlijk.

[.oisyn]

Soultaker schreef op vrijdag 02 februari 2007 @ 00:24:
Lijkt me dat als de test set lastig is, mensen juist sneller dood gaan, of niet?

Niet met mijn AI, die springt 500 + rand() % 1000 blokjes terug in de tijd als een oplossing dood loopt. In het ergste geval zul je die dus na 2 uur moeten afbreken

[NMe]

.oisyn schreef op vrijdag 02 februari 2007 @ 00:29:
[...]

Niet met mijn AI, die springt 500 + rand() % 1000 blokjes terug in de tijd als een oplossing dood loopt. In het ergste geval zul je die dus na 2 uur moeten afbreken

Wat in jouw geval wel als nadeel heeft dat je niet de hoogste score opslaat en het dus mogelijk is dat je lager uitkomt dan de hoogste score die je voorbij hebt zien komen.

Overigens is de set toch niet zo lastig. De reden dat de app van eerste inzender er zo'n moeite mee had, was dat de set blokjes die ik gebruikte niet helemaal netjes was. Ik kan die app dus nog een tweede keer draaien.

[.oisyn]

-NMe- schreef op vrijdag 02 februari 2007 @ 00:33:
[...]

Wat in jouw geval wel als nadeel heeft dat je niet de hoogste score opslaat en het dus mogelijk is dat je lager uitkomt dan de hoogste score die je voorbij hebt zien komen.

Ja, en hij kon ook beter terugspringen naar een blokje waar goede alternatieven voor waren ipv zomaar een random blokje. Allemaal dingen die ik nog wilde implementeren maar waar ik helemaal niet meer aan toegekomen ben

[Norjee]

* Norjee mag nu vast wel zijn ideeën (helaas niet fatsoenlijk uitgewerkt) plaatsen

Wie heeft het probleem niet geïnterpreteerd als blokjes op volgorde droppen, maar zeg maar uit een solide blok "hapjes" halen, eventueel geinverteerd? Of wat ik deed een "vaatje" vullen, met als enige regel dat een blokjes met id 0 (het eerste blokje) niet boven een blokje met id 1 (tweede blokje) gedropt moest worden, dus stapelen en zo goed mogelijk passen zolang het nog mogelijk was het blokje met laagste id te plaatsten (en wilde dat niet uiteraard weer terug in je boom).

[ Voor 14% gewijzigd door Norjee op 02-02-2007 01:42 ]

[Marcj]

Norjee schreef op vrijdag 02 februari 2007 @ 01:25:
* Norjee mag nu vast wel zijn ideeën (helaas niet fatsoenlijk uitgewerkt) plaatsen

Wie heeft het probleem niet geïnterpreteerd als blokjes op volgorde droppen, maar zeg maar uit een solide blok "hapjes" halen, eventueel geinverteerd? Of wat ik deed een "vaatje" vullen, met als enige regel dat een blokjes met id 0 (het eerste blokje) niet boven een blokje met id 1 (tweede blokje) gedropt moest worden, dus stapelen en zo goed mogelijk passen zolang het nog mogelijk was het blokje met laagste id te plaatsten (en wilde dat niet uiteraard weer terug in je boom).

Ik had het nog veel simpeler. Mijn algoritme gaat gewoon de blokjes op alle mogelijke posities plaatsen en aan de hand van een score functie (dus niet de normale score, maar eentje die ook rekening houd met hoeveel gater er in zitten, hoe 'regelmatig' hij er uit ziet etc) beslissen waar hij het beste past.

Het voordeel is dat dit algoritme ook makkelijk uit te breiden is met een look-ahead, die een x aantal plekken vooruit alvast zet en dat pas de score gaat bekijken. Alleen als je dat direct met alles doet, dan krijg je veel te veel mogelijkheden. Stel gemiddeld kun je elk blokje op 30 verschillende manier plaatsen. Zonder in de boom te snijden zou je met een look-ahead van x maar liefst 30^x mogelijkheden krijgen. Die is veel te veel (voor 3 is die al 27.000, voor 4 al 810.000 etc...).

Daarom gebruik ik dezelfde score functie om de boom te 'snoeien'. Op het huidige niveau (dus het eerst volgende blokje dat geplaatst moet worden) gaat mijn algoritme de beste 4 opties uitzoeken (die aantal is aan te passen) en deze in 4 threads gooien om de rest van de boom te berekenen. Hierna wordt op elk volgend niveau de beste 2 uitgezocht, totdat we op de gewenste diepte zijn. Hierdoor wordt per stap veel minder opties bekeken en kan ik op een redelijke machine tot 10 stappen vooruit kijken.

Naast dit algoritme heb ik natuurlijk nog wat andere Java optimalisaties gedaan, zoals een pool aanmaken voor de velden. Een nieuw veld creeren in het geheugen in namelijk vrij zwaar en daarom recycle ik de velden in een pool. Een bijkomend voordeel is dan dat de garbage collector het ook niet zo moeilijk heeft. Plus dat ik als ik de blokken laad ik gelijk alle mogelijke rotaties + schuivingen in het geheugen opsla als een apart blok. Daarbij wordt ook rekening gehouden dat sommige rotaties gelijk zijn aan andere (bijvoorbeeld een vierkantje van 4 blokjes kun je zoveel roteren als je wilt, maar hij blijft het zelfde). Hierbij hoeven natuurlijk een hoop mogelijkheden nooit bekeken te worden.

In de code kun je wel aardig zien hoe ik dat heb uitgewerkt

_{pff.. wat een lang verhaal}

[.oisyn]

Onze algo's komen aardig overeen Marcj . Ik heb 'm alleen niet multithreaded gemaakt. En ik heb helaas niet genoeg tijd besteed om de score-berekenings-functie beter te tweaken.

[ Voor 35% gewijzigd door .oisyn op 02-02-2007 11:32 ]

[zwippie]

Jemig, zoiets heb ik ook, marcj. Maar dan zonder multithreading, zonder field-objectpool en ik snoei de boom nog iets anders. Ik heb gekozen voor een statische lookahead van 2 blokjes, op mijn machine speelt ie dan de 100.000 blokjes nog niet weg, maar op een snelle machine komt ie in de buurt denk ik.

[Gerco]

Hehe, algos komt aardig overeen ja. Het zal vooral in het snoeien en de scoringsfunctie liggen wie er gaat winnen.

Ik heb een lookahead van 2 blokjes, zonder snoeien, wel multithreading (op multicore machines) en zonder objectpool (ik bewaar namelijk niets, mijn AI speelt gewoon de game zoals een mens dat zou doen). 100.000 blokjes testset_tetris speelt 'ie binnen 2 uur weg op mijn 1.5GHz Celeron Mobile. Op Testset_GoT gaat 'ie over na ~300 moves.

Het idee is iig hetzelfde, de rest zijn details

[ Voor 7% gewijzigd door Gerco op 02-02-2007 11:48 ]

[Marcj]

Tja, dit leek mij ook een vrij standaard oplossing hiervoor, dus het verwonderd mij niet dat anderen ook dit idee hadden. Alleen dan gaat het om de details die het veschil maken

zwippie: hoe heb jij dan de boom gesnoeid?

[EdwinG]

zwippie schreef op vrijdag 02 februari 2007 @ 11:42:
Jemig, zoiets heb ik ook, marcj. Maar dan zonder multithreading, zonder field-objectpool en ik snoei de boom nog iets anders. Ik heb gekozen voor een statische lookahead van 2 blokjes, op mijn machine speelt ie dan de 100.000 blokjes nog niet weg, maar op een snelle machine komt ie in de buurt denk ik.

Statische lookahead heb ik ook gebruikt (en dan maar 1 blokje). Verder heb ik eigenlijk helemaal niet gesnoeid, wat er waarschijnlijk ook voor zorgt dat mijn 'ai' niet de snelste is. (om het voorzichtig uit te drukken)
Wel heb ik vooraf bepaald of balkjes symetrisch waren, na 90 of 180 graden draaien, zodat onder andere het vierkantje maar met 1 rotatie wordt geprobeerd. De andere rotaties zouden immers dezelfde resultaten geven.
[edit]
En hier mijn progsels:
tetris.rar

[ Voor 5% gewijzigd door EdwinG op 02-02-2007 12:07 ]

[zwippie]

marcj: Ik tel het aantal gaten in het veld, vanaf de hoogte waar nog iets gedropt kan worden, dus soms niet tot helemaal onderin het veld. De mogelijke velden met de minste gaten gaan door. Daar heb ik nog even mee lopen prutsen, en hij doet nu alle velden tot het minimaal aantal gaten + 2, dus hij neemt nog een paar extra mogelijke velden mee.

De score berekening hangt bij mij af van het aantal gaten, de verdeling (het veld moet een beetje gelijkmatig hoger worden) en het aantal weggespeelde rijen. Aan die drie factoren heb ik gewichtswaarden gehangen, maar dat was eigenlijk een beetje nattevinger werk.

[Marcj]

Hoe heeft iedereen trouwens de velden intern opgeslagen? Ik zag al ergens een matrix van bytes, zodat er kleurtjes aan gegeven zouden kunnen worden (denk ik?). Ik heb zelf gewoon een array van shorts, waarbij dus iedere bit een blokje in het veld representeerd. Hierdoor gaat het droppen en clearen heel erg snel m.b.v. de binaire & en | operatoren . Ook kijken of een lijn vol is is gewoon vergelijk met 0x7FFF.

zwippie schreef op vrijdag 02 februari 2007 @ 11:55:
marcj: Ik tel het aantal gaten in het veld, vanaf de hoogte waar nog iets gedropt kan worden, dus soms niet tot helemaal onderin het veld. De mogelijke velden met de minste gaten gaan door. Daar heb ik nog even mee lopen prutsen, en hij doet nu alle velden tot het minimaal aantal gaten + 2, dus hij neemt nog een paar extra mogelijke velden mee.

De score berekening hangt bij mij af van het aantal gaten, de verdeling (het veld moet een beetje gelijkmatig hoger worden) en het aantal weggespeelde rijen. Aan die drie factoren heb ik gewichtswaarden gehangen, maar dat was eigenlijk een beetje nattevinger werk.

Ik ben daarbij trouwens achter gekomen dat als je een look-ahead heb van meer dan 4, dat ik gerust een negatieve waarde aan een enkele of dubbele lijn kan hangen. Hiermee wordt de score veel hoger, doordat hij veel vaken 3, 4 of 5 lijnen tegelijk verwijderd Maar hierbij was het uiteraard ook trail & error

[ Voor 55% gewijzigd door Marcj op 02-02-2007 12:00 ]

[EdwinG]

Marcj schreef op vrijdag 02 februari 2007 @ 11:57:
Hoe heeft iedereen trouwens de velden intern opgeslagen? Ik zag al ergens een matrix van bytes, zodat er kleurtjes aan gegeven zouden kunnen worden (denk ik?). Ik heb zelf gewoon een array van shorts, waarbij dus iedere bit een blokje in het veld representeerd. Hierdoor gaat het droppen en clearen heel erg snel m.b.v. de binaire & en | operatoren . Ook kijken of een lijn vol is is gewoon vergelijk met 0x7FFF.

Voor de velden heb ik gebruik gemaakt van een array met 15x45 (675) items, die elk true (blokje) of false (geen blokje) waren.

[DaCoTa]

Ja inderdaad, de contest... Zijn er mensen nog geinteresseerd in een Java implementatie? Ik heb hem niet ingestuurd, te weinig tijd in de laatste weken. Of mag het alsnog ingestuurd worden buiten mededinging?

[Creepy]

Insturen kan niet meer want de termijn is voorbij, maar niemand houdt je tegen om hier de source vrij te geven natuurlijk.

[Piels]

Geen bijdragen van Rob zelf?

[zwippie]

EdwinG schreef op vrijdag 02 februari 2007 @ 12:14:
Voor de velden heb ik gebruik gemaakt van een array met 15x45 (675) items, die elk true (blokje) of false (geen blokje) waren.

Ik neem aan dat je 15x40 (600) bedoelt?

Ik heb het zelf (ook) als een 2-dimensionale array van booleans bijgehouden, zowel de blokjes als het veld, niet echt de snelste/compactste manier waarschijnlijk.

Heeft er iemand eigenlijk gebruik gemaakt van de mogelijk om een DISCARD te doen?

[RobIII]

Piels schreef op vrijdag 02 februari 2007 @ 13:45:
Geen bijdragen van Rob zelf?

Als je RobIII bedoelt: Nope. Ik heb niet eens één regel geprogrammeerd hoewel ik inderdaad wel een idee had (en dat kwam aardig overeen met dat van Marcj). Te weinig tijd, te druk. Wel is mijn validator 1 van de validators die we inzetten om resultaten en scores te checken. Ik probeer aan de volgende contest(s) mee te doen, maar gezien mijn nogal drukken leven weet ik niet of dat altijd gaat lukken naast het moderaten, flesjes geven, overwerken en andere zaken

zwippie schreef op vrijdag 02 februari 2007 @ 14:04:
Heeft er iemand eigenlijk gebruik gemaakt van de mogelijk om een DISCARD te doen?

Van alle inzendingen heeft niemand ook maar één DISCARD gebruikt. Het is natuurlijk nogal moeilijk te bepalen wanneer je die zou inzetten en dat heeft in sommige gevallen nogal drastische gevolgen voor je boom; in principe kun je die overal in je boom "toepassen" maar om dat nou bij iedere branch te gaan doen...

[ Voor 29% gewijzigd door RobIII op 02-02-2007 14:08 ]

[Marcj]

RobIII schreef op vrijdag 02 februari 2007 @ 14:06:
[...]

Van alle inzendingen heeft niemand ook maar één DISCARD gebruikt. Het is natuurlijk nogal moeilijk te bepalen wanneer je die zou inzetten en dat heeft in sommige gevallen nogal drastische gevolgen voor je boom; in principe kun je die overal in je boom "toepassen" maar om dat nou bij iedere branch te gaan doen...

Ik denk ook dat het te maken heeft dat je maar 5 discards hebt voor de hele serie. Als dat 100.000 blokken zijn, dan maken die echt nauwelijks iets uit (die 2000 punten doen er dan ook eigenlijk niet toe). Het zou logischer zijn geweest als je bijvoorbeeld per 1000 blokken die je gedropt hebt 1 DISCARD zou krijgen. Dan zou het nog een verschil kunnen gaan uitmaken.

[NMe]

DaCoTa schreef op vrijdag 02 februari 2007 @ 12:54:
Ja inderdaad, de contest... Zijn er mensen nog geinteresseerd in een Java implementatie? Ik heb hem niet ingestuurd, te weinig tijd in de laatste weken. Of mag het alsnog ingestuurd worden buiten mededinging?

Als je wil zien waar je staat vergeleken met de rest dan kun je je inzending alsnog insturen, zodat ik je score en executietijd kan berekenen/meten. Je komt dan wel in de scoretabel maar met de expliciete vermelding dat je te laat was en dus gediskwalificeerd bent.

[Gerco]

Ik heb nagedacht over de DISCARD (staat ook nog in commentaar in mijn code, denk ik). Wanneer ik zag dat ik geen move meer kon maken, discarde ik dat blokje. Helaas leid dat meestal tot 5x DISCARD en dan game over aan het einde van de game.

Dat kost alleen maar punten, dus heb ik het weer verwijderd.

[EdwinG]

zwippie schreef op vrijdag 02 februari 2007 @ 14:04:
Ik neem aan dat je 15x40 (600) bedoelt?

Ik heb het zelf (ook) als een 2-dimensionale array van booleans bijgehouden, zowel de blokjes als het

Nope, 15x45, als ik het precies op 15x40 zette, kreeg ik een hele hoop foutmeldingen (NOTICE) aan het einde, omdat het plaatsen van de blokjes buiten de array ging vallen. Dit had ik ook kunnen voorkomen door een controle op de regel waar het blokje zou komen, maar dat zou meer tijd vergen.

Mijn array had overigens 1 dimensie, waarbij de sleutel 15*y + x was. (links onder was 0, rechts onder 14, links boven 660, rechts boven 675.)

[NMe]

Wat je wel met discards had kunnen doen was, wanneer je game over gaat of dreigt te gaan, even terug kijken. Je kijkt dan naar de laatste x (100?) zetten, en kijkt daarin naar de zet die je het grootste afgesloten gat oplevert. Die zet is waarschijnlijk de slechtste zet die je algoritme heeft gemaakt en kan dus mogelijk weggegooid worden. Doe dat, en laat hem van daaruit verder runnen. Mogelijk komt ie dan wel verder, en heb je je discard dus zinnig weten te gebruiken.

[Marcj]

Hmm, dat was wel een goed idee. Ik heb eigenlijk helemaal niets bijzonders gedaan mocht ik wel game-over gaan Hopelijk gaat het allemaal wel lukken

[NMe]

Ik vind het voor mezelf wel jammer dat ik het verhaal in mijn hoofd helemaal uitgedacht heb, maar dat ik niet de tijd heb gevonden om (voor spek en bonen) mee te doen. Het was een leuke brain teaser, maar het was leuker geweest als ik ook resultaat had gehad.

[Marcj]

Trouwens -NMe-: hoeveel inzendingen heb je al getest? Of ben je nog gewoon aan het werk?

[RobIII]

Marcj schreef op vrijdag 02 februari 2007 @ 15:41:
Trouwens -NMe-: hoeveel inzendingen heb je al getest? Of ben je nog gewoon aan het werk?

De eerste uitslagen zijn al binnen, maar er wordt nog niets naar buiten gebracht tot we er helemaal zijn Overigens mijn hulde aan -NMe- die daar toch wel wat tijd in gestoken heeft

[ Voor 11% gewijzigd door RobIII op 02-02-2007 15:47 ]

[Soultaker]

RobIII schreef op vrijdag 02 februari 2007 @ 14:06:
Van alle inzendingen heeft niemand ook maar één DISCARD gebruikt. Het is natuurlijk nogal moeilijk te bepalen wanneer je die zou inzetten en dat heeft in sommige gevallen nogal drastische gevolgen voor je boom; in principe kun je die overal in je boom "toepassen" maar om dat nou bij iedere branch te gaan doen...

Sowieso is discarden een extraatje wat je vooral in een geavanceerd algoritme wil doen (het gewoon droppen van blockjes is meer de basis) en daar zijn veel mensen niet echt aan toegekomen. Verder had ik het idee dat het gebruiken van een DISCARD gewoon veel te kostbaar is; het kost een heleboel punten, en het is heel moeilijk om te bepalen of je die terug gaat verdienen. Het was misschien beter geweest om ze gratis te maken, dan moet je nog steeds bepalen wanneer je ze inzet, maar kun je dat wat vrijer doen.

Verder was een discard per N drops zoals Marcj suggereerde ook wel een goed idee; dan had je ook wat meer motivatie om ze te gebruiken, want als je nu een set van 10,000 blokjes hebt zijn DISCARDs zó zeldzaam, dat je beter je tijd kunt gebruiken om het droppen van die 10,000 blokjes te optimaliseren, dan te bepalen welke 5 je kunt discarden waarna je er alsnog 9,995 moet droppen.

[NMe]

Marcj schreef op vrijdag 02 februari 2007 @ 15:41:
Trouwens -NMe-: hoeveel inzendingen heb je al getest? Of ben je nog gewoon aan het werk?

Ik heb alle 8 de inzendingen laten draaien en de resultaten gegroepeerd. Ik heb daarvoor een blokkenset gebruikt met daarin één blokje met tenminste één lege kolom (waarbij ik alvast één bug tegengekomen ben bij een van de inzendingen ) en een game.txt van 110.000 blokjes. Om het vast extra spannend te maken: maar één ingezonden app wist het spel daadwerkelijk tot het einde uit te spelen, maar wie dat was hou ik nog even voor me.

RobIII schreef op vrijdag 02 februari 2007 @ 15:46:
Overigens mijn hulde aan -NMe- die daar toch wel wat tijd in gestoken heeft

...tot midden in de nacht omdat ik er anders geen tijd voor had. Als iemand nieuwsgierig is naar de hardware waarop de test heeft gedraaid, zie hier.

[ Voor 23% gewijzigd door NMe op 02-02-2007 16:45 ]

[EdwinG]

Hulde aan de organisatie

[Marcj]

-NMe- schreef op vrijdag 02 februari 2007 @ 16:42:
[...]

Ik heb alle 8 de inzendingen laten draaien en de resultaten gegroepeerd. Ik heb daarvoor een blokkenset gebruikt met daarin één blokje met tenminste één lege kolom (waarbij ik alvast één bug tegengekomen ben bij een van de inzendingen ) en een game.txt van 110.000 blokjes. Om het vast extra spannend te maken: maar één ingezonden app wist het spel daadwerkelijk tot het einde uit te spelen, maar wie dat was hou ik nog even voor me.

Gelukkig heb ik mijn code wel getest met eigengeschreven blokken (ook met een lege kolom). Hopelijk ben ik er deze keer ook uit gekomen... we wachten allemaal in spanning af

[...]

...tot midden in de nacht omdat ik er anders geen tijd voor had. Als iemand nieuwsgierig is naar de hardware waarop de test heeft gedraaid, zie hier.

Iig heel erg bedankt en natuurlijk ook de rest van de organisatie!

ps. Gelukkig wel een dual core, anders was ik wel bang dat hij het niet binnen 2 uur zou redden

[ Voor 4% gewijzigd door Marcj op 02-02-2007 17:11 ]

[Gerco]

Ik heb niet getest met lege kolommen. Ik heb eerlijk gezegd geen flauw idee hoe mijn inzending daarop zou reageren (en dat terwijl ik in het begin van de contest nog gevraagd heb of dat soort blokken mogelijk zijn ).

[edit]
Hij geeft warnings (stond nog een debug message in de code), maar lijkt het verder wel te doen. Hij crasht er iig niet van, of er nog een correct resultaat uitkomt heb ik niet gechecked... ik zie het wel.

[ Voor 33% gewijzigd door Gerco op 02-02-2007 19:06 ]

[The Fox NL]

-NMe- schreef op vrijdag 02 februari 2007 @ 16:42:
[...]

Ik heb alle 8 de inzendingen laten draaien en de resultaten gegroepeerd. Ik heb daarvoor een blokkenset gebruikt met daarin één blokje met tenminste één lege kolom (waarbij ik alvast één bug tegengekomen ben bij een van de inzendingen ) en een game.txt van 110.000 blokjes. Om het vast extra spannend te maken: maar één ingezonden app wist het spel daadwerkelijk tot het einde uit te spelen, maar wie dat was hou ik nog even voor me.

[...]

...tot midden in de nacht omdat ik er anders geen tijd voor had. Als iemand nieuwsgierig is naar de hardware waarop de test heeft gedraaid, zie hier.

Ik gok erop dat Marcj hem uitgespeeld zal hebben.

Gelukkig is de game.txt maar 110000 blokjes, want daar had ik een bug in. Ik was namelijk al begonnen met het implementeren van een look-ahead, en had wat veranderd in de AI::getNextBlock en toen een bug geïntroduceerd.

[.oisyn]

Die lege kolommen feature heb ik er in de laatste kwartier nog ingehacked. Die bug kan best van mij zijn

[Soultaker]

Oh, mijn programma is gegarandeerd kapot als er lege kolommen in blokjes zitten. Ik was geloof ik de eerste die dat opmerkte, en ik heb meermaals gezegd dat ik het flauw zou vinden om contestants op dit soort triviale foutjes af te straffen, juist omdat er geen mogelijkheid is om dit te testen/corrigeren. Het maakt niet uit hoeveel werk je in je oplossing steekt en hoe goed 'ie lokaal werkt; als je iets triviaals vergeten bent hang je. Leek (en lijkt me nog steeds) niet in de geest van de contest.

Beetje jammer dus. Had ik net zo goed niets kunnen inzenden. Eerlijk gezegd vind ik het behoorlijk lam. Het is overigens in een halve regel te patchen, dus kom maar snel met die testdata, dan kan ik voor mezelf een zinnige score berekenen.

[ Voor 9% gewijzigd door Soultaker op 02-02-2007 21:07 ]

[The Fox NL]

Soultaker schreef op vrijdag 02 februari 2007 @ 21:03:
Oh, mijn programma is gegarandeerd kapot als er lege kolommen in blokjes zitten. Ik was geloof ik de eerste die dat opmerkte, en ik heb meermaals gezegd dat ik het flauw zou vinden om contestants op dit soort triviale foutjes af te straffen, juist omdat er geen mogelijkheid is om dit te testen/corrigeren. Het maakt niet uit hoeveel werk je in je oplossing steekt en hoe goed 'ie lokaal werkt; als je iets triviaals vergeten bent hang je. Leek (en lijkt me nog steeds) niet in de geest van de contest.

Beetje jammer dus. Had ik net zo goed niets kunnen inzenden. Eerlijk gezegd vind ik het behoorlijk lam. Het is overigens in een halve regel te patchen, dus kom maar snel met die testdata, dan kan ik voor mezelf een zinnige score berekenen.

Ik heb jou programma even gedraaid en hij ging idd erop kapot. Hij draaide gewoon door, maar ik had hem hard afgesloten en door mijn validator gedraaid. 'Unplacable block' volgens mijn validator. Wel jammer.

[Soultaker]

Ik heb ook ondersteuning voor onderbroken blokjes ingebouwd in m'n GUI, en daarbij kwam ik nog een interessante case tegen. Zie het volgende voorbeeld: (Het speelveld heb ik wat kleiner gemaakt.)

Het is mij uit de specificatie in de TS niet duidelijk hoe dit bloekje moet vallen; ligt 'ie zo goed, of moet het linker (losse) deel nog een rij naar onder vallen? Ik denk dat de referentieprogramma's het zoals afgebeeld doen, omdat dit het makkelijkste te programmeren is, maar er valt best iets voor te zeggen dat tijdens een drop alle afzonderlijke blokjes doorvallen zo ver ze kunnen, zonder daarbij los te raken.

Dit onderschrijft m'n punt nogmaals, dat dit soort randgevallen uitgesloten hadden moeten worden, óf dat expliciet genoemd zou moeten worden hoe ze afgehandeld moeten worden.

-NMe- schreef op vrijdag 02 februari 2007 @ 00:33:
Overigens is de set toch niet zo lastig. De reden dat de app van eerste inzender er zo'n moeite mee had, was dat de set blokjes die ik gebruikte niet helemaal netjes was.

Wat was er mis mee dan?

[.oisyn]

Het lijkt me vrij duidelijk dat het hele blok zo ver kan vallen als het kan vallen, en niet dat de afzonderlijke delen nog verder kunnen valen. Ze maken immers 1 blokje, of daar nou gaten in zitten of niet

[EdwinG]

Soultaker schreef op vrijdag 02 februari 2007 @ 22:16:
Het is mij uit de specificatie in de TS niet duidelijk hoe dit bloekje moet vallen; ligt 'ie zo goed, of moet het linker (losse) deel nog een rij naar onder vallen?

quote: ts

eventuele "zwevende blokjes" vallen niet naar beneden maar blijven "zweven":

[ Voor 7% gewijzigd door EdwinG op 03-02-2007 01:13 ]

[RobIII]

The Fox NL schreef op vrijdag 02 februari 2007 @ 19:28:
Gelukkig is de game.txt maar 110000 blokjes, want daar had ik een bug in. Ik was namelijk al begonnen met het implementeren van een look-ahead, en had wat veranderd in de AI::getNextBlock en toen een bug geïntroduceerd.

Soultaker schreef op vrijdag 02 februari 2007 @ 21:03:
Beetje jammer dus. Had ik net zo goed niets kunnen inzenden. Eerlijk gezegd vind ik het behoorlijk lam. Het is overigens in een halve regel te patchen, dus kom maar snel met die testdata, dan kan ik voor mezelf een zinnige score berekenen.

Het is ook niet gezegd dat we met maar 1 set blokken (con)testen

[Marcj]

RobIII schreef op zaterdag 03 februari 2007 @ 02:05:
[...]


[...]

Het is ook niet gezegd dat we met maar 1 set blokken (con)testen

Zijn er dan meerdere rondes?? Ik kan niet wachten op de uitslag

[Creepy]

Soultaker schreef op vrijdag 02 februari 2007 @ 22:16:
Dit onderschrijft m'n punt nogmaals, dat dit soort randgevallen uitgesloten hadden moeten worden, óf dat expliciet genoemd zou moeten worden hoe ze afgehandeld moeten worden.

Een blok valt altijd als een geheel. Dus het valt zo ver mogelijk door, of een blok nu een gat heeft of niet. Zoals je het nu tekent klopt het dus.

[ Voor 20% gewijzigd door Creepy op 04-02-2007 11:29 ]

[NMe]

Soultaker schreef op vrijdag 02 februari 2007 @ 22:16:
Wat was er mis mee dan?

1
1
1X
1
1

...in plaats van...

10
10
1X
10
10

De meeste van de inzendingen hadden er niet echt moeite mee (netjes! ), maar sommigen liepen erop vast. En aangezien dit niet gespecificeerd was moest ik het wel fixen.

[ Voor 28% gewijzigd door NMe op 05-02-2007 03:24 ]

[Marcj]

-NMe- schreef op maandag 05 februari 2007 @ 03:23:
[...]

1
1
1X
1
1

...in plaats van...

10
10
1X
10
10

De meeste van de inzendingen hadden er niet echt moeite mee (netjes! ), maar sommigen liepen erop vast. En aangezien dit niet gespecificeerd was moest ik het wel fixen.

Hmm, als het goed is zou die van mij dan een foutmelding moeten geven, maar ik heb het nog nooit getest . Dit was niet gespecificeerd, dus ik ging er van uit dat alle regels even lang zouden moeten zijn.

Even getest, en mijn programma geeft inderdaad gewoon een error (loopt dus niet vast!)

ps. nog 64 uur tot de deadline

[EdwinG]

-NMe- schreef op maandag 05 februari 2007 @ 03:23:
[...]

1
1
1X
1
1

...in plaats van...

10
10
1X
10
10

Ik denk dat mijn programma daar wel op vastgelopen is. De breedte van het blok wordt namelijk bepaald aan de hand van de eerste regel.

[zwippie]

Waar ik nog wel van baal, is dat mijn progsel een eenvoudige blokkenset niet uitspeelt binnen 2 uur, aangezien ik de lookahead op 2 vast heb gezet. Hierdoor komt ie wat verder in een lastige set, maar zal ie geen 100.000 blokjes in 2 uur halen. Voor een goede score is dat natuurlijk funest.

[NMe]

Marcj schreef op maandag 05 februari 2007 @ 08:28:
Even getest, en mijn programma geeft inderdaad gewoon een error (loopt dus niet vast!)

Om precies te zijn ben ik er door jouw app achter gekomen dat mijn blokje niet netjes in elkaar zat.

ps. nog 64 uur tot de deadline

[roy-t]

Is het te vroeg om al over een volgende prog. contest nieuwe stijl te praten!? Ik heb deze keer meer tijd (ooeh en mijne nieuwe C# skills vragen er om om getest te worden, even als mijn ugly hack het in vb6 vaardigheden)

[ Voor 40% gewijzigd door roy-t op 05-02-2007 16:16 ]

[RobIII]

therat10430 schreef op maandag 05 februari 2007 @ 16:13:
Is het te vroeg om al over een volgende prog. contest nieuwe stijl te praten!? Ik heb deze keer meer tijd (ooeh en mijne nieuwe C# skills vragen er om om getest te worden, even als mijn ugly hack het in vb6 vaardigheden)

Een nieuwe contest is op til maar nog in bespreking bij ons; we willen uiteraard de volgende contest net zo goed, zo niet beter, organiseren. Eventjes geduld dus nog

[roy-t]

RobIII schreef op maandag 05 februari 2007 @ 16:20:
[...]

Een nieuwe contest is op til maar nog in bespreking bij ons; we willen uiteraard de volgende contest net zo goed, zo niet beter, organiseren. Eventjes geduld dus nog

Mja ik vond mezelf al redelijk vlug door te reageren voordat de uitslagen er zijn, maar ik ben benieuwd en houd het (als vergeleken met de zwaargewicht-programmers) als nouja mischien wel slechts groentje goed in de gaten!

[Aloys]

Ik weet niet of het gewenst is om ideeën voor een nieuwe contest te spammen . Maar is een Schaak-AI niets?

Mijn idee was dan dat de verschillende inzendingen tegen elkaar gaan schaken, en op die manier een winnaar uit de bus komt. En dan bijv. zetten via een tcp verbinding versturen naar elkaar (evt een servertje schrijven door een van de modjes).

Ben benieuwd of er ook nog andere mensen leuke ideetjes hebben.

[NMe]

Je kan zo 100 verschillende algoritmen downloaden die voor je schaken, zonder dat je zelf een letter code hoeft te schrijven. Als het dus zoiets wordt, dan moeten in elk geval de spelregels aangepast worden. Maar goed, laten we maar even afwachten, deze contest is nog niet eens voorbij.

[Marcj]

Aloys schreef op dinsdag 06 februari 2007 @ 14:17:
Ik weet niet of het gewenst is om ideeën voor een nieuwe contest te spammen . Maar is een Schaak-AI niets?

Mijn idee was dan dat de verschillende inzendingen tegen elkaar gaan schaken, en op die manier een winnaar uit de bus komt. En dan bijv. zetten via een tcp verbinding versturen naar elkaar (evt een servertje schrijven door een van de modjes).

Ben benieuwd of er ook nog andere mensen leuke ideetjes hebben.

Schaken is misschien wel iets te ingewikkeld, maar is een spel als Reversi of Go is wel leuk

[Gerco]

Marcj schreef op dinsdag 06 februari 2007 @ 14:23:
Schaken is misschien wel iets te ingewikkeld, maar is een spel als Reversi of Go is wel leuk

Reversi, ok. Go is ingewikkelder dan schaken (voor computers iig). Een tcp servertje lijkt me een vreselijk slecht idee. Werk dan met pipes oid, zodat je alle code op de machine(s) van de jury moet draaien.

[Dido]

Marcj schreef op dinsdag 06 februari 2007 @ 14:23:
Schaken is misschien wel iets te ingewikkeld, maar is een spel als Reversi of Go is wel leuk

En jij dacht dat Go minder gecompliceerd was dan schaken?

Dergelijke spellen lijken me juist uitermate ongeschikt voor een contest vanwege de enorm gespecialiseerde AI algoritmes die erbij komen kijken. Om een redelijke schaak-AI te shcrijven moet je al meer dan redelijk kunnen schaken. Niet echt toegankelijk dus.

[Marcj]

Dido schreef op dinsdag 06 februari 2007 @ 14:30:
[...]

En jij dacht dat Go minder gecompliceerd was dan schaken?

Dergelijke spellen lijken me juist uitermate ongeschikt voor een contest vanwege de enorm gespecialiseerde AI algoritmes die erbij komen kijken. Om een redelijke schaak-AI te shcrijven moet je al meer dan redelijk kunnen schaken. Niet echt toegankelijk dus.

Ok, slecht voorbeeld. Ik bedoelde dat er andere leuke strategie spellen zijn waarvoor wel redelijke AI's te schrijven zijn zonder al te veel moeite. Een Go bord van 19x19 heeft wel extreem veel mogelijkheden om te berekenen, maar de spelregels zijn (volgens mij) wel een stuk eenvoudiger dan bij schaken.

Het probleem hierbij is wel dat je twee spelers hebt, waar deze uitdaging maar een speler vereist. Voor een speler kun je makkelijker controleren zonder een client-server systeem.

[Dido]

De regels zijn het probleem niet, een strategie wel. Waar je bij tetris nog wel als leek een AI kunt verzinnen is dat bij Go (of schaken) onbegonnen werk.
Je krijgt dan geen programming contest, maar een Go-contest.

[zwippie]

Ook zo maar even een ideetje:
ATC: Air Traffic Control
Op je radar verschijnen vliegtuigjes die allemaal willen landen. Het is jouw taak om de vliegtuigen zo veilig mogelijk te laten landen. Je radar is verdeeld in hoogteniveau's. Ieder binnenkomend vliegtuig heeft een hoogte, een gewenste tijd van aankomst, een hoeveelheid brandstof en nog zo wat. Je kunt een vliegtuig opdracht geven om een niveau lager te gaan vliegen, hoger te gaan vliegen of om te landen. Elke opdracht kost een vliegtuig tijd en brandstof. Als er meer dan x vliegtuigen op een bepaalde hoogte zitten, botsen ze op elkaar. Elke kloktik kun je opdrachten geven. Elke kloktik kan er een vliegtuig op je radar bij komen (dit staat in de inputfile).
Voor elk veilig geland vliegtuig krijg je punten, extra punten als het vliegtuig op tijd is geland. Voor elke botsing of zeecrash (brandstof op) krijg je strafpunten/leven eraf.

De input bestaat uit een beschrijving van de binnenkomende vliegtuigen. (welke kloktik/hoogte/brandstof)
De output bestaat uit opdrachten aan elk vliegtuig. (up, down, wait, land)

ofzo.

Geen idee of dit een leuk probleem is. Het is ook nog niet echt uitgewerkt maar misschien ziet iemand er iets in.
Als ik het zo nog eens over lees, lijkt het ook best wel een beetje op tetris.

[Verwijderd]

Othello lijkt me opzich een redelijke om te programmeren, hoewel dit natuurlijk ook vrij ingewikkeld gaat worden...

Analysts have estimated the number of legal positions in Othello is at most 10²⁸, and it has a game-tree complexity of approximately 10⁵⁸.
Mathematically, Othello still remains unsolved. Experts have not yet figured out what the outcome of a game will be where both sides have perfect play

Leuk spelletje om even te programmeren ;p

[ Voor 3% gewijzigd door Verwijderd op 06-02-2007 15:15 ]

[Verwijderd]

Waarom moet het weer zo nodig AI zijn?

Is dat het enige wat er verzonnen kan worden voor een contest? (Niet dat ik iets anders weet hoor, daar niet van)

Ik weet van deze contest dat er toch meer tijd in gaat zitten als je denkt, eerst begin je goed, maar de echt lastige problemen oplossen kosten een hoop tijd en als het dan iets drukker is als je had verwacht dan is de deadline alweer geweest.

[Verwijderd]

Gooi een leuk balletje op, misschien dat de modjes het ook wel zien zitten

[.oisyn]

Verwijderd schreef op dinsdag 06 februari 2007 @ 15:30:
Waarom moet het weer zo nodig AI zijn?

Omdat een "AI" vrijwel het enige gebied van programmeren is dat verschillende edoch interessante oplossingen kan leveren. Ik heb AI tussen quotes gezet omdat AI een groot woord is - het komt er over het algemeen gewoon op neer dat je een algoritme verzint om een bepaald (NP) probleem op te lossen, maar dit soort problemen vergaren zich al snel onder de noemer "AI" wegens het doorzoeken van grote zoekbomen.

[Verwijderd]

.oisyn schreef op dinsdag 06 februari 2007 @ 16:01:
[...]

Omdat een "AI" vrijwel het enige gebied van programmeren is dat verschillende edoch interessante oplossingen kan leveren. Ik heb AI tussen quotes gezet omdat AI een groot woord is - het komt er over het algemeen gewoon op neer dat je een algoritme verzint om een bepaald (NP) probleem op te lossen, maar dit soort problemen vergaren zich al snel onder de noemer "AI" wegens het doorzoeken van grote zoekbomen.

Is dat echt het enige gebied?

Zijn er helemaal geen andere gebieden te verzinnen?

Lijkt me ook zo eentoning om iedere contest eigenlijk in de basis hetzelfde te hebben.

Zouden we nou met z'n allen niet iets orgineels kunnen verzinnen?

Wat misschien ook wel leuk is is als er een bepaalde opdracht wordt verzonnen welke moet worden opgelost dmv een programma (niet te ingewikkelde opdracht), maar dit programma moet gecompiled worden dmv een eigen te schrijven compiler in een voorbepaalde verzonnen taal.

Dat lijkt me best wel grappig op zich, maar misschien wel weer veel te ingewikkeld voor een contest. Die richting is in ieder geval een die niet echt in het AI vakje past, maar wel een goede uitdaging kan bieden (mits goed opgezet).


.... Verder als dit idee kwam ik helaas ook niet zonder toch weer bij AI terecht te komen.

[Zeror]

Misschien leuk om een contest te maken waarbij de meest spectulaire dingen moet kunnen laten zien met gebruik van een paar kilobyte'jes
Net zoiets als .theprodukkt zegmaar.

[MrSleeves]

Verwijderd schreef op dinsdag 06 februari 2007 @ 16:40:
[...]

Dat lijkt me best wel grappig op zich, maar misschien wel weer veel te ingewikkeld voor een contest.

Het is belangrijk dat vooral de drempel niet te hoog is en ik denk dat dat bij jouw idee wel het geval is. Bij deze opdracht konden best veel mensen meedoen; het verschil zit 'm vooral in de kwaliteit van het algoritme.

[.oisyn]

Verwijderd schreef op dinsdag 06 februari 2007 @ 16:40:
Wat misschien ook wel leuk is is als er een bepaalde opdracht wordt verzonnen welke moet worden opgelost dmv een programma (niet te ingewikkelde opdracht), maar dit programma moet gecompiled worden dmv een eigen te schrijven compiler in een voorbepaalde verzonnen taal.

En hoe waardeer je de entries dan? Er is immers maar 1 correcte uitvoer mogelijk. Dan komt het er in het algemeen op neer dat je naar efficientie moet kijken (dan zijn native talen automatisch in het voordeel dus niet eerlijk) of naar het ontwerp van de code (is subjectief dus niet eerlijk)

[Verwijderd]

Wat misschien ook wel leuk is is als er een bepaalde opdracht wordt verzonnen welke moet worden opgelost dmv een programma (niet te ingewikkelde opdracht), maar dit programma moet gecompiled worden dmv een eigen te schrijven compiler in een voorbepaalde verzonnen taal.

Hoe ver wil je dan gaan in die compiler hehe, een simpel ding wat wat opdrachten interpreteerd en omzet naar bv Java of C++ ofzo?

[.oisyn]

Rakkerzero schreef op dinsdag 06 februari 2007 @ 16:48:
Misschien leuk om een contest te maken waarbij de meest spectulaire dingen moet kunnen laten zien met gebruik van een paar kilobyte'jes
Net zoiets als .theprodukkt zegmaar.

te hoge drempel imho.

[Gerco]

Net zoiets als .theprodukkt zegmaar.

Dat is de beoordeling natuurlijk erg subjectief (al kunnen we dan wel met zn allen stemmen, dan blijft het eerlijk).

Op de TU Delft moesten we van eenvoudige specificaties een processor emulator schrijven en daar dan een programma op draaien. Iets in die geest lijkt me ook wel wat. De mods publiceren specificaties van een eenvoudige, maar hypothetische Virtual Machine en wat code, gecompileerd voor die VM.

Het doel is dan om een VM te schrijven die het geleverde programma zo goed mogelijk kan draaien. (goed kan dan geinterpreteerd worden als snel/correct). Verdere uitwerking uiteraard noodzakelijk, want een contest waarbij je een entry alleen kan beoordelen op "hij werkt (niet)" is zinloos.

Er zal uiteindelijk iets meetbaars uit moeten komen. Een score, een tijd, zoiets.

[Verwijderd]

OK misschien ander idee:

De opdracht is dan om een simulatie systeem te maken waarmee bijvoorbeeld electronische onderdelen gesimuleerd kunnen worden.

Dat mag helemaal analoog zijn (dat je dus voltages ed gaat simuleren) of dat je het op een logisch niveau bekijkt (dus and / or poortjes en dat soort dingen) of allebei.

Je mag dan helemaal zelf weten hoe ver je erin gaat, en de over de resultaten wordt dan gestemd om te bepalen wie de winnaar is etc.

Dat heeft op zich een laag niveau omdat het in principe heel basic kan zijn.
Nadeel is wel dat degene die er het meeste tijd in stopt eigenlijk al gaat winnen, maar dat is eigenlijk altijd wel zo bij dit soort dingen (hoewel talent ook altijd een vaste factor is).

[zwippie]

Zo'n opdracht met een VM is inderdaad ook heel erg tof. Ik ben hier destijds mee aan de slag gegaan. Er werd een primitieve computer taal beschreven. Eerst moest je een VM schrijven zodat je de inputfile kon uitvoeren. Je kwam dan in een primitief operating system, was echt heel gaaf gedaan. In dit OS kon je inloggen en kwam je nieuwe deel-opdrachten tegen. Voor alle gevonden en opgeloste opdrachten kreeg je punten.

Heel erg leuk om te doen allemaal. Het maken van zo'n opdracht kost alleen wel veel tijd en kunde.
(hij was echt leuk, zie bv de vm specs)

[ Voor 7% gewijzigd door zwippie op 06-02-2007 17:36 ]

[RobIII]

Jongens, maak je niet te druk
Ik kan 1 ding met zekerheid zeggen: de komende contest wordt niet te hoogdrempelig (dus iedereen kan mee doen, of zeg maar van ongeveer het niveau van deze contest), en we zullen niet iedere contest op AI vlak houden. Wacht gewoon even rustig de resultaten van deze contest af en daarna start de nieuwe (op korte termijn).

Uiteraard zijn suggesties welkom en leuk, maar wij als crew bepalen uiteindelijk hoe/wat

[ Voor 6% gewijzigd door RobIII op 06-02-2007 17:34 ]

[Verwijderd]

Jongens, maak je niet te druk

Gewoon enthousiast Kon aan de vorige niet meedoen ivm. heel veel drukte, maar als de volgende weer zo'n tijdsbestek heeft zal ik zeker wat in elkaar proberen te frustelen:)

[Gerco]

RobIII schreef op dinsdag 06 februari 2007 @ 17:34:
Ik kan 1 ding met zekerheid zeggen: de komende contest wordt niet te hoogdrempelig

Zo'n VM is natuurlijk, hoewel leuk voor de gevorderden, alles behalve laagdrempelig Iets eenvoudigers is idd wel handig als we meer dan 2-3 deelnemers willen hebben.

[The Fox NL]

Je kan natuurlijk ook de opdracht geven om bijvoorbeeld een simpel spelletje te maken. Degene met de meeste stemmen wint dan bijvoorbeeld. Een beetje de opzet van de 3D contests uit het Graphics topic.

[Verwijderd]

@Rob:

Niemand maakt zich hier druk hoor, we willen gewoon ook graag meehelpen denken aangezien we het ons voor kunnen stellen dat het verzinnen van zo'n contest echt geen makkelijke opgave is.

Dus we zetten gewoon wat ideeen neer zodat jullie misschien wat inspiratie op doen.

[NMe]

Dat Rob denkt dat men zich druk maakt komt waarschijnlijk voornamelijk door zinnen als "Waarom moet het weer zo nodig AI zijn?". We hebben dat ten eerste nergens gezegd en ten tweede komt dat bijna gefrustreerd over.

Contest 2 wordt weer door ons opgezet en zal inderdaad laagdrempelig zijn, maar toch op hoog niveau uit te bouwen zijn, net zoals deze contest.

[Verwijderd]

-NMe- schreef op woensdag 07 februari 2007 @ 13:10:
Dat Rob denkt dat men zich druk maakt komt waarschijnlijk voornamelijk door zinnen als "Waarom moet het weer zo nodig AI zijn?". We hebben dat ten eerste nergens gezegd en ten tweede komt dat bijna gefrustreerd over.

Contest 2 wordt weer door ons opgezet en zal inderdaad laagdrempelig zijn, maar toch op hoog niveau uit te bouwen zijn, net zoals deze contest.

Ohwjah als je het op die manier leest dan kan het zo overkomen.

Het was meer zo dat iedereen het had over AI contest, dan is het gewoon een normale vraag: "Waarom eigenlijk zo nodig AI?"

Tis maar hoe je het leest.

(Overigens viel het laagdrempelige van deze contest nog redelijk tegen, maar das mijn mening)

[ Voor 6% gewijzigd door Verwijderd op 07-02-2007 13:14 ]

[NMe]

Hoezo viel dat tegen dan? Ik heb mensen gezien die verschillende AI-objecten hebben ingeleverd, en daar zat zelfs een random-AI bij (die uiteraard niet standaard meegecompileerd werd ). Je kan de AI zo ingewikkeld maken als je zelf wil; uiteraard betekent dat natuurlijk dat je minder kans maakt op het behalen van de eerste plaats, maar als ik aan zo'n contest meedoe, dan is dat wat mij betreft in de eerste plaats om er wat van op te steken, en dat kan op elk niveau.

[RobIII]

Het gaat in deze contests meer om het spel dan om de knikkers inderdaad. Dat er uitslagen aan verbonden zijn (en "ranglijsten") is puur voor de fun. De insteek is uiteraard dat iedereen er uiteindelijk op wat voor manier dan ook wijzer van wordt; en dat is IMHO meer waard dan een "eerste/tweede/derde/etc. plek" in een nietszeggende ranglijst.

[DaCoTa]

Ik ben toch nog even verder gegaan met mijn contest 1 oplossing, ook al niet ingestuurd. Wil hem hier wel posten maar wat ik merkte is dat mijn fitness functie allesbehalve optimaal is. Het is bij mij een afweging van de gebruikte veldhoogte, het aantal gaten in het veld en de bezettingsgraad van het veld. Maar ik krijg met deze 3 fitness waarden geen goede combinatie om zelfs de 1e blokkenset uit te spelen. Ik vraag me af wat voor fitness functies anderen gebruikt hebben.

Overigens, ik zit aan 350k evaluaties per seconde op een AMD X2 4600+ en maak gebruik van multithreading, draaiend op Java 1.6.0 server VM.

[Creepy]

Verwijderd schreef op woensdag 07 februari 2007 @ 13:14:
(Overigens viel het laagdrempelige van deze contest nog redelijk tegen, maar das mijn mening)

Vind je? Opzich is meedoen met een entry die kan spelen redelijk eenvoudig. Goed spelen is inderdaad een ander verhaal

Ook met die gedachte zullen we nieuwe contest gaan organiseren. Meedoen moet eenvoudig blijven zodat nagenoeg iedereen hier meedoen. Zaken als een 64K intro zijn leuk om te doen maar veel te hoogdrempelig en stiekum enorm specialistisch. Daarbij moet de beoordeling ook redelijk eenduidig zijn. Denk daar dan ook aan als je idee voor een contest wilt aandragen (graag zelfs, dan kunnen we nog wel even door met het organiseren van verschillende contests zonder dat we zelf echt creatief hoeven te zijn;) ).

[zwippie]

-NMe- schreef op donderdag 01 februari 2007 @ 14:52:
Ik denk dat ik namens iedereen spreek als ik zeg dat we ernaar streven binnen een week een uitslag klaar te hebben. Uiterlijk 8 februari om 0:00 dus, maar aangezien we daar geen afspraken over gemaakt hebben beloof ik niets.

Bijna!

[RobIII]

-NMe- schreef op donderdag 01 februari 2007 @ 14:52:
Ik denk dat ik namens iedereen spreek als ik zeg dat we ernaar streven binnen een week een uitslag klaar te hebben. Uiterlijk 8 februari om 0:00 dus, maar aangezien we daar geen afspraken over gemaakt hebben beloof ik niets.

zwippie schreef op woensdag 07 februari 2007 @ 20:18:
[...]

Bijna!

Optimist

Even het volgende: We wachten nog heel even op een laatste run van 1 deelnemer, verwerken die uitslagen nog samen met de andere uitslagen en dan zijn we er. Ik wil benadrukken dat die laatste run op dit moment nog niet loopt, en ik moet heel even afwachten tot dat gebeurt; daarna moet alles snel rond (kunnen) zijn (na een evt. korte bespreking van de resultaten achter de schermen als daar nog nood voor zou zijn).

Ik heb sowieso een feestje vanavond, dus als er al resultaten zijn is dat pas in de nacht ergens als ik ze moet posten.

[ Voor 36% gewijzigd door RobIII op 07-02-2007 21:12 ]

[NMe]

Ik ben nu met die laatste run bezig, en ik ben bang dat die niet voor half 5 af gaat zijn. Ik denk in elk geval wel dat we alles morgen kunnen afronden.

[RobIII]

-NMe- schreef op donderdag 08 februari 2007 @ 02:42:
Ik ben nu met die laatste run bezig, en ik ben bang dat die niet voor half 5 af gaat zijn. Ik denk in elk geval wel dat we alles morgen kunnen afronden.

Wat mij betreft wel; de rest van de resultaten zijn allemaal al verwerkt.
Alle resultaten zijn binnen en verwerkt...


And the winner is.... *tromroffel*.....

* RobIII gaat even een slaapje doen; het is 4 uur fokkin' 57

[ Voor 17% gewijzigd door RobIII op 08-02-2007 04:57 ]

[NMe]

*tromroffel stopt* De uitslagen zijn er! Komt allen, komt allen!

Alle gekheid op een stokje, ik heb net de uitslagen die Rob netjes gegroepeerd had even mooi verwoord en in de post onder de topicstart gefrot: Programming Contest Nieuwe Stijl: Contest 1 *uitslagen!* #uitslagen.

We willen graag iedereen bedanken die deze contest tot zo'n succes gemaakt heeft, en we hopen jullie allemaal weer terug te zien in contest 2. En natuurlijk hopen we dat er dan nog meer mensen meedoen.