Programming Contest Nieuwe Stijl: Contest 1 *uitslagen!*

[NMe]

M-ThijZ schreef op woensdag 15 november 2006 @ 00:00:
Heb er alvast een object-georienteerd tintje aan gegeven:

code:

...

Ik wil hierbij even oproepen om zo min mogelijk kant en klare code hier te posten. Overleggen met anderen over mogelijke oplossingen is prima, maar we zien liever niet dat mensen gemakkelijk één op één dingen van elkaar kunnen overnemen; dat is voor jezelf ook niet leuk. Trivialere dingetjes kunnen misschien niet echt kwaad, maar zaken die echt met de AI te maken hebben liever niet posten.

Verder ben ik blij om te zien dat deze contest zo in de smaak valt; ik hoop dat het enthousiasme over een paar weken nog steeds zo hoog is.

[RobIII]

Verwijderd schreef op woensdag 15 november 2006 @ 02:47:
Dat roteren is inderdaad lastig, maar gewoon even op papier doen en je ziet meteen hoe de translatie moet zijn.

Tipje: X & Y coords swappen = roteren



^^ Kijk eens goed Wat gebeurt er als ik de X, Y swap ( Y, X )?

Verwijderd schreef op woensdag 15 november 2006 @ 02:47:
...je hebt maar 2 uur voor de output...

We gaan toch niet allemaal op die 2 uur mikken he?
Ik zou het toch wel leuk vinden als er wat minder heftige "brute-force" deelnemers tussen zaten

Then again: doe wat je niet laten kunt Je bent vrij om die 2 uur optimaal te benutten

[ Voor 10% gewijzigd door RobIII op 15-11-2006 03:06 ]

[NMe]

Verwijderd schreef op woensdag 15 november 2006 @ 02:47:
Overigens een tipje: Niet on the fly gaan roteren, das alleen maar overhead en je hebt maar 2 uur voor de output. Je hebt 10 vaste blokken (hoewel je dus niet weet hoe die eruit zien) en kunt ze dus gerust van te voren roteren en opslaan.

En dan gaat onze parser over zijn nek omdat die gewoon de oorspronkelijke, ongeroteerde blokkenset gebruikt. Je zal dus echt on the fly moeten gaan roteren.

Ook hoef je maar 1 rotatiealgoritme te gebruiken, namelijk 90 graden met de klok mee. Je kunt dan het resulaat van de vorige rotatie gebruiken om de volgende te berekenen.

En denk eraan: 3x met de klok mee roteren is hetzelfde als 1 tegen de klok in te roteren. Ik denk dus (maar weet het niet zeker) dat je het tegen de klok in roteren maar beter geheel kunt weglaten en enkel met de klok mee kunt gebruiken. Dat maakt qua score niets uit en scheelt je waarschijnlijk overhead (en denkwerk?)

Je bent al de hele tijd bang dat 2 uur te kort is, maar intussen ben je wel bereid 3 commando's te geven waar er maar één nodig is? Aan dit soort micro-optimalisaties heb je zelden wat en je zou je daar helemaal (nog?) niet mee bezig moeten houden. 2 uur zou meer dan genoeg moeten zijn, en mocht het echt voor een te groot percentage van de inzendingen een probleem zijn, dan verkleinen we de blokkenset wel of verlengen de maximale run-tijd.

[RobIII]

-NMe- schreef op woensdag 15 november 2006 @ 02:51:
[...]

En dan gaat onze parser over zijn nek omdat die gewoon de oorspronkelijke, ongeroteerde blokkenset gebruikt. Je zal dus echt on the fly moeten gaan roteren.

Ik neem aan dat hij bedoelt dat je 10 blokken inleest, ze allemaal 3 stappen roteert en dus 10 x 4 blokken in het geheugen houdt. Dan voer je de rotatie maar 1 keer uit en kun je daarna telkens de "ge-cache-te" versies gebruiken. Daar was ik dan weer niet opgekomen voor mijn validator *schaam* Die roteert elke keer netjes Ik zal het aanpassen als ik er weer aan werk

Nog een andere tip (ik ben in een weggeef-bui ):

-NMe- schreef op dinsdag 14 november 2006 @ 15:59:
Het is wat ruimer geworden: op een meer dan gemiddelde pc mag je programma 2 uur staan stampen, daarna wordt het afgekapt en de tot dan toe uitgevoerde output wordt gebruikt om je score te berekenen.

Denk er dus aan dat je regelmatig je buffers flushed naar je file want 2 uur = 2 uur en dan is het gewoon "end task" (of zoals mijn (lang geleden) leraar 'programmeren' zei: "stok tussen de spaken" )

[ Voor 38% gewijzigd door RobIII op 15-11-2006 03:12 ]

[Verwijderd]

RobIII schreef op woensdag 15 november 2006 @ 03:00:
[...]

Ik neem aan dat hij bedoelt dat je 10 blokken inleest, ze allemaal 3 stappen roteert en dus 10 x 4 blokken in het geheugen houdt. Dan voer je de rotatie maar 1 keer uit en kun je daarna telkens de "ge-cache-te" versies gebruiken. Daar was ik dan weer niet opgekomen voor mijn validator *schaam* Die roteert elke keer netjes Ik zal het aanpassen als ik er weer aan werk

Inderdaad dat bedoel ik.

Dus on-the-fly is tijdens het rekenwerk, ik zeg dus dat je dat ervoor moet doen.

Ik zeg nog expliciet dat je 10 vaste blokken hebt ook al weet je niet hoe die blokken eruit gaan zien.

Maar het is al laat he?

@NME:
En zo'n suboptimalisatie vind ik het niet. Ik denk dat als je de computer moet laten nadenken over of het nu linksom of rechtsom is redelijk lastig is.

Het probleem wordt voor mij alvast simpeler in m'n hoofd als ik stel dat je alleen met de klok mee kunt draaien. Vandaar dat ik zeg dat het je denkwerk scheelt en waarschijnlijk overhead. (ook al weet de computer dat ie 3x met de klok mee moet draaien dan hoef je dat niet te vertalen naar 1x tegen de klok in wat je overhead scheelt)

Ook maakt het voor het eindresultaat als RobIII de parser aanpast niets uit (terwijl daar ook geen tijdslimiet aan zit) en het is ook niet zo dat je 3 commando's geeft waar er 1 nodig is. Je gebruikt altijd diezelfde ge-cachede versie van de tegel en schrijft enkel 3 regels weg ipv 1 (wat echt geen overhead geeft gezien de grootte van de regels).

Het scheelt mij dus (en meer mensen tenzij ik een freak brain heb) denkwerk en in de programmatuur wellicht wat overhead. Het is dus geen suboptimalisatie maar gewoon een goede tip.
Of de tip voor iedereen even handig is weet ik niet, maar dat is altijd zo met tips.

Ik ben er overigens wel aan toe, ik heb het test en aanstuur gedeelte af en moet nu eens hard gaan denken over hoe de AI moet gaan werken. Ik ben niet zo bang voor de 2 uur hoor, mijn oplossing zal vast wel vlotjes gaan draaien. Alleen als je iedere keer 3x een rotatie gaat uitvoeren bij iedere stap dan gaat het wel krap worden in die 2 uur ja.

@RobIII:

Ik weet wel hoe het roteren werkt hoor, zoals ik zeg: Ik heb al een test progje af en daar zit die rotatie dus ook in. Ik wil alleen niet alles weggeven zoals jij dat doet

En waarom zou je die 2 uur niet optimaal gebruiken? Zoals ik al eerder genoemd heb: Je AI moet beslissingen gaan maken. Als je meer tijd hebt kun je dus nog eens terug komen op een beslissing en bekijken 'What if' als we nou eens een andere beslissing nemen.

Je zou met een multithreaded applicatie zelfs een hele boom kunnen bouwen van beslissingen waarbij je bijvoorbeeld 5 beslissingen opsplitst in 10 threads, dan na een bepaald aantal beslissingen bekijken hoe het verlopen is en een kansberekening maakt welke thread(s) het meeste kans van overleven hebben. Dan kill je de kansloze en splits je weer nieuwe threads af, gaat er eentje af dan splits je ook weer nieuwe af.

Op die manier kun je de 2 uur erg nuttig volmaken en zo naar een optimaal resultaat komen. Omdat er op bijna ieder moment een resultaat beschikbaar is kun je ook regelmatig de beste flushen zodat je in ieder geval altijd je beste resultaat in een file hebt staan.

Alles behalve brute force dus, in mijn ogen de beste en meest complexe oplossing. Helaas voor vele (waaronder mijzelf) onhaalbaar, voornamelijk wegens tijdgebrek

[ Voor 49% gewijzigd door Verwijderd op 15-11-2006 05:02 ]

[NMe]

Op mijn werk zit ik momenteel te knutselen met een 20Mhz microchip op een vrij eenvoudige microcontroller. Het zal je verbazen hoeveel dat ding kan doen in een fractie van een seconde, en dan hebben we het over een eenvoudig ding, in tegenstelling tot bijvoorbeeld mijn dual core AMD processor hier, waar het programma mogelijk op gaat draaien. 2 uur is zeer waarschijnlijk wel voldoende, in elk geval voor gecompileerde programma's; scripts zijn mogelijk wat trager.

[Verwijderd]

-NMe- schreef op woensdag 15 november 2006 @ 04:56:
Op mijn werk zit ik momenteel te knutselen met een 20Mhz microchip op een vrij eenvoudige microcontroller. Het zal je verbazen hoeveel dat ding kan doen in een fractie van een seconde, en dan hebben we het over een eenvoudig ding, in tegenstelling tot bijvoorbeeld mijn dual core AMD processor hier, waar het programma mogelijk op gaat draaien. 2 uur is zeer waarschijnlijk wel voldoende, in elk geval voor gecompileerde programma's; scripts zijn mogelijk wat trager.

Jups, kan me nog goed herinneren zo'n 10 jaar geleden op de hogeschool.

Kijk jongens, nu schrijven we een progje op deze 3mhz microcontroller die deze rij leds laat knipperen.

Prof zet em aan, student zegt: "Meneer u heeft het verkeerd gedaan, de leds knipperen niet maar staan gewoon aan".

Prof zegt: "Klopt, het knippert zo snel dat je het niet kunt zien, das nu de snelheid van deze microcontroller".

Zelfs toendertijd al waren de thuis PC's vele malen sneller als zo'n microcontrollertje, tegenwoordig is het helemaal lomp.

Maar toch, iedere sec is er een

Ik had overigens nog wel een klein vraagje:

Wanneer je een blok laat vallen, maar deze komt met z'n bovenste topje boven de 40 regels uit, krijg je dan nog wel 10 punten wegens een geplaatst blokje? En analoog daaraan: Wanneer deze zorgt voor een lege rij (of meerdere) telt deze rij dan nog mee?

Ik heb aangenomen van niet, maar ik denk ik check het even?

En wanneer er rijen leeg komen en daarmee het blokje verder omlaag kan vallen, wordt dit dan nog gedaan? Of is een drop die niet meer past gewoon game over en geen verdere actie zoals puntentelling en zwaartekracht?

Ik ben bij mijn checker uitgegaan dat vallen buiten muren en boven buiten het veld gelijk is en dus direct zorgt voor game over en dus verder niets meer doet.

[ Voor 23% gewijzigd door Verwijderd op 15-11-2006 05:48 ]

[RobIII]

Verwijderd schreef op woensdag 15 november 2006 @ 03:12:
[...]
Ook maakt het voor het eindresultaat als RobIII de parser aanpas niets uit (terwijl daar ook geen tijdslimiet aan zit)

Ho, ho! Daar hoef ik de parser niet voor aan te passen; ik doelde er op dat ik ook wel die "rotatie-results" kon "cachen" i.p.v. iedere keer braaf die rotatie uit te voeren (en dus duizenden keren hetzelfde doen).

Dus zowel ROTATE CW als ROTATE CCW blijven gewoon behouden. Ook als is 3x links hetzelfde als 1x rechts

Verwijderd schreef op woensdag 15 november 2006 @ 03:12:
Ik weet wel hoe het roteren werkt hoor, zoals ik zeg: Ik heb al een test progje af en daar zit die rotatie dus ook in. Ik wil alleen niet alles weggeven zoals jij dat doet

Ik heb er even over getwijfeld om het uberhaupt te posten; maar "the meat" van je app zit 'm natuurlijk in het uitpuzzelen waar je blokjes moeten komen etc. Ik denk dat ik met het "tipje" voor roteren niets wezenlijks weggeef; doe ik dat wel dan denk ik dat je niet al te hoog zult eindigen (en dan praat ik dus in het algemeen, niet specifiek op jou bedoeld).

Verwijderd schreef op woensdag 15 november 2006 @ 03:12:
En waarom zou je die 2 uur niet optimaal gebruiken? Zoals ik al eerder genoemd heb: Je AI moet beslissingen gaan maken. Als je meer tijd hebt kun je dus nog eens terug komen op een beslissing en bekijken 'What if' als we nou eens een andere beslissing nemen.

Dat zeg ik; doe wat je niet laten kunt Anderzijds is de 3e "geheime" categorie misschien wel juist de beste score/tijd verhouding, weet jij veel...

Verwijderd schreef op woensdag 15 november 2006 @ 04:59:
Wanneer je een blok laat vallen, maar deze komt met z'n bovenste topje boven de 40 regels uit, krijg je dan nog wel 10 punten wegens een geplaatst blokje?

Tuurlijk niet. Blokje valt buiten het veld = ongeldig = game-over.

Verwijderd schreef op woensdag 15 november 2006 @ 04:59:
En analoog daaraan: Wanneer deze zorgt voor een lege rij (of meerdere) telt deze rij dan nog mee?

Nope. Game-over

[ Voor 13% gewijzigd door RobIII op 15-11-2006 05:55 ]

[Verwijderd]

RobIII schreef op woensdag 15 november 2006 @ 05:53:
[...]

Ho, ho! Daar hoef ik de parser niet voor aan te passen; ik doelde er op dat ik ook wel die "rotatie-results" kon "cachen" i.p.v. iedere keer braaf die rotatie uit te voeren (en dus duizenden keren hetzelfde doen).

Dus zowel ROTATE CW als ROTATE CCW blijven gewoon behouden. Ook als is 3x links hetzelfde als 1x rechts


[...]

Ik heb er even over getwijfeld om het uberhaupt te posten; maar "the meat" van je app zit 'm natuurlijk in het uitpuzzelen waar je blokjes moeten komen etc. Ik denk dat ik met het "tipje" voor roteren niets wezenlijks weggeef; doe ik dat wel dan denk ik dat je niet al te hoog zult eindigen (en dan praat ik dus in het algemeen, niet specifiek op jou bedoeld).


[...]

Dat zeg ik; doe wat je niet laten kunt Anderzijds is de 3e "geheime" categorie misschien wel juist de beste score/tijd verhouding, weet jij veel...

[...]

Tuurlijk niet. Blokje valt buiten het veld = ongeldig = game-over.


[...]

Nope. Game-over

Nee ik bedoelde dus dat er geen tijdslimiet zit aan het controleren van de resultaten (de resultaten hoeven enkel binnen 2 uur gemaakt te worden). Dus als jij de parser hebt aangepast zit er geen overhead meer in het controleren van de resultaten wanneer je 3x ROTATE CW doet ipv 1x ROTATE CCW. De parser heeft daar ongewijzigd nog wel overhead van gezien er 3x een operatie zou worden uitgevoerd waar er maar 1 nodig is.

Ik bedoelde dus echt niet dat CCW weggelaten moet worden, ik gaf alleen als tip dat je het voor jezelf weg kunt laten mocht je dat willen. Er zitten geen nadelen aan, dus denk je er voordeel mee te doen dan laat je het weg. Ook kun je CW weglaten en CCW overlaten, tis maar waar je zelf zin in hebt.

Wat betreft het game over verhaal had ik het dus goed aangenomen, ongeldig = game over is niets geen punten zwaartekracht etc meer.

Wat betreft het rotatie verhaal heb ik ook zitten twijfelen om de formule te posten, zeker gezien er eerst een spoiler ergens was weg ge-edit. Maar inderdaad, als je al moeite hebt met het roteren zal er van de AI ook niet veel terecht komen. Aan de andere kant, misschien kun je wel geweldig out-of-the-box denken en heb je met dat soort praktische zaken meer problemen.

Wie zal het zeggen?

[ Voor 9% gewijzigd door Verwijderd op 15-11-2006 06:16 ]

[Verwijderd]

RobIII schreef op woensdag 15 november 2006 @ 05:53:
Een boel...

Verwijderd schreef op woensdag 15 november 2006 @ 06:14:
Nog meer...

Vroeg me af of jullie ook nog ooit slapen . De sluitingsdatum is pas volgend jaar... niet morgen

[MrSleeves]

RobIII schreef op woensdag 15 november 2006 @ 02:50:
[...]

Tipje: X & Y coords swappen = roteren

[afbeelding]

^^ Kijk eens goed Wat gebeurt er als ik de X, Y swap ( Y, X )?

Volgens mij alleen op voorwaarde dat de X op cöordinaat (m,m) ligt.

code:

00000
00000
01000
0X100
00000

wordt (resp. CW, CCW en gespiegeld):

code:

00000    00000    00000
00000    00000    001X0
00000    01000    00010
0X100    1X000    00000
01000    00000    00000

[Evilbee]

Verwijderd schreef op woensdag 15 november 2006 @ 02:47:

En denk eraan: 3x met de klok mee roteren is hetzelfde als 1 tegen de klok in te roteren. Ik denk dus (maar weet het niet zeker) dat je het tegen de klok in roteren maar beter geheel kunt weglaten en enkel met de klok mee kunt gebruiken. Dat maakt qua score niets uit en scheelt je waarschijnlijk overhead (en denkwerk?)

Dit klopt al niet. Er is al aangegeven dat als er meerdere mensen met de zelfde score zijn, de score met de minste zetten wint.

Dus in je code kan je wel drie keer met de klok mee draaien, als je dan maar in je output.txt CCW zet

offtopic:
Hmm, blijkbaar had FF de pagina niet goed geladen

[ Voor 5% gewijzigd door Evilbee op 15-11-2006 09:05 ]

[Janoz]

Grappig, iedereen heeft het over de tijdslimiet en over of ze alle 100000 blokjes wel kunnen plaatsen. Probeer eerst uberhaupt maar eens 2 uur lang zetten te genereren zonder dat je een game over krijgt .

[MrSleeves]

Janoz schreef op woensdag 15 november 2006 @ 09:25:
Grappig, iedereen heeft het over de tijdslimiet en over of ze alle 100000 blokjes wel kunnen plaatsen. Probeer eerst uberhaupt maar eens 2 uur lang zetten te genereren zonder dat je een game over krijgt .

Standaard nerd-gedrag.

Afgelopen vrijdag kreeg ik de gelegenheid om tegen de top van de wereld squash te spelen. Kosten waren in eerste instantie 1 euro per verliespunt. Wat doe je dan: uitrekenen wat het gaat kosten. Dat terwijl je eigenlijk eerst moet bedenken of je het überhaupt wel uithoudt die paar minuten op de baan.

[ Voor 8% gewijzigd door MrSleeves op 15-11-2006 09:29 ]

[Dido]

RobIII schreef op woensdag 15 november 2006 @ 02:50:
Tipje: X & Y coords swappen = roteren

Ik hoop serieus dat je parser niet zo werkt, want dan voldoet ie niet aan de specs
Swappen is spiegelen tov de X=Y diagonaal, en spiegelen mag expliciet niet!

Leuk voorbeeldje van inconsequent gedrag bij swappen = roteren:

code:

1 keer swappen = 

twee rotaties, een rotatie CCW of geen rotatie!

 111 -> 100       111 -> 100       111 -> 111 
 001 -> 100       010 -> 111       100 -> 100
 001 -> 111       010 -> 100       100 -> 100

En dat even los van het feit dat je totaal geen rekening houdt met rotatiepunten waarvoor niet geldt X=Y, maar je roteert al niet echt als je swapt.

Een simpel gegeven trouwens: SWAP(SWAP(X,Y))=(X,Y)
Als je roteert heb je vier mogelijkheden, als je swapt maar twee.

[RobIII]

MrSleeves schreef op woensdag 15 november 2006 @ 08:58:
[...]

Volgens mij alleen op voorwaarde dat de X op cöordinaat (m,m) ligt.

code:

00000
00000
01000
0X100
00000

wordt (resp. CW, CCW en gespiegeld):

code:

00000    00000    00000
00000    00000    001X0
00000    01000    00010
0X100    1X000    00000
01000    00000    00000

Goed zo Scherp
En toch maakt het geen fluit uit
Zo lang ik de X maar aanhoud bij het positioneren (droppen) van het blokje

RobIII schreef op woensdag 15 november 2006 @ 02:50:
Tipje: X & Y coords swappen = roteren

MrSleeves schreef op woensdag 15 november 2006 @ 08:58:
Ik hoop serieus dat je parser niet zo werkt, want dan voldoet ie niet aan de specs

Trust me, die voldoet aan de specs

RobIII schreef op woensdag 15 november 2006 @ 02:50:
Swappen is spiegelen tov de X=Y diagonaal, en spiegelen mag expliciet niet!

Leuk voorbeeldje van inconsequent gedrag bij swappen = roteren:

code:

1 keer swappen = 

twee rotaties, een rotatie CCW of geen rotatie!

 111 -> 100       111 -> 100       111 -> 111 
 001 -> 100       010 -> 111       100 -> 100
 001 -> 111       010 -> 100       100 -> 100

Eh?

RobIII schreef op woensdag 15 november 2006 @ 02:50:
En dat even los van het feit dat je totaal geen rekening houdt met rotatiepunten waarvoor niet geldt X=Y, maar je roteert al niet echt als je swapt.

Dat hang maar af van je "referentiekader" Het rotatiepunt is namelijk totaal niet interessant als je bij het droppen de "X" van je figuur maar op de juiste kolom hebt (zoals ik ook al zeg in het begin van mijn post).

[ Voor 55% gewijzigd door RobIII op 15-11-2006 09:41 ]

[frickY]

Vrees dat deze contest in eerste instantie vreselijk onderschat zal worden Heb er even over zitten nadenken hoe je dit zou kunnen aanpakken maar het is echt aardig complex.
Crisp gaat weer voor zijn favo taal hoop ik? Javascript

[MrSleeves]

RobIII schreef op woensdag 15 november 2006 @ 09:36:
[...]

Hee, jij haalt quotes door elkaar.

[PiepPiep]

Ik hoop maar dat dit niet een huiswerk opdracht is van de mods die samen in een projectgroep op school zitten

[Janoz]

Laatste keer dat ik op school zat is al weer 10 jaar geleden. Laatste keer dat ik een college had iets van 5 en de laatste onderwijs gerelateerde opdracht heb ik 4 jaar terug ingeleverd .

[DaCoTa]

Verwijderd schreef op woensdag 15 november 2006 @ 08:14:
[...]


[...]

Vroeg me af of jullie ook nog ooit slapen . De sluitingsdatum is pas volgend jaar... niet morgen

Klopt, maar dit framework geneuzel heeft nog weinig met een goede Tetris AI te maken, daar gaat de echte tijd in zitten (als het goed is). Zo ging het wel bij de GotBot contest, een paar dagen freubelen om een basic botje te bouwen, daarna weken lang zorgvuldig tunen om de botjes van zielig kanonnevoer watjes om te vormen tot moordadige vechtmachines.

[Verwijderd]

Ik begrijp heel goed dat er in het framework relatief maar weinig tijd gaat zitten en dat het schrijven van een goede AI oplossing de meeste tijd met zich mee neemt. Het ging me echter meer om de tijdstippen waarop beide heren nog druk bezig waren... het viel me op en ik dacht , zij zijn goed bezig.

[SysRq]

Leuke contest, het lijkt inderdaad op het eerst gezicht niet moeilijk, maar ik ben bang dat het nog wel tegen zal vallen (voor mij dan. )

Kan ik er trouwens op rekenen dat het programma op een Dual Core /dual processor uitgevoerd wordt? Dat kan namelijk aardig wat uitmaken.

[Dido]

RobIII schreef op woensdag 15 november 2006 @ 09:36:
Eh?

Ik geef drie mogelijke blokjes, bij alle drie swap ik de x en y coordinaten, en ik krijg de gegeven uitkomsten. Geen rotatie, 1 rotatie of zelfs twee rotaties.

Tenzij ik iets heel fundamenteels betreffende dat swappen over het hoofd zie, voer je een spiegeling uit, en roteer je niet.

Ik wil best geloven dat je parser aan de specs voldoet, maar als ie spiegelt als reactie op ROTATE dan voorspel ik rare resultaten.

Edit: Of je bent in de regel die ik oorspronkelijk quootte iets vergeten, zoals een ! voor de =?
In dat geval zit ik dus aan jou uit te leggen waarom je gelijk hebt, omdat je het tegengestelde beweerde

[ Voor 16% gewijzigd door Dido op 15-11-2006 11:42 ]

[Zyppora]

RobIII schreef op woensdag 15 november 2006 @ 02:50:
[...]

[afbeelding]

^^ Kijk eens goed Wat gebeurt er als ik de X, Y swap ( Y, X )?

[...]

Dit vind ik een prachtig voorbeeld van wat mijn Java/C++ leraar eens tegen mij zei: vertrouw NOOIT gegeven informatie! Kijk ALTIJD eerst of wat er geschreven staat, wel klopt.

Het diagram laat zien dat X, Y swappen gelijk staat aan spiegelen over de diagonaal, zoals eerder aangegeven, en dus NIET roteren

Overigens is het (voor iedereen wel, denk ik) goed om hier een keer tegenaan te lopen ('He? Waarom doetie het niet?'). Dus deze post niet lezen jongens

Verder: top idee. Ik zal kijken wat ik kan doen, ben bang dat ik een uurtje nog niet haal, dus over die tijdslimiet maak ik me geen zorgen. IMHO is de TS zeer duidelijk zoals die nu is (maar misschien komen bij het uitwerken van de details toch wat vragen naar boven).

[Bint]

Het valt me wel op hoe slecht de mensen lezen hier

DIngen die duidelijk in de Startpost staan, die gewoon nog een keer gevraagd worden? Zal leuk worden als je dadelijk in het bedrijfsleven een stuk software aflevert, waar de helft niet van klopt, omdat er "niet goed gelezen is".

[evaarties]

Wie maakt de GUI .

Leuke contest wel en ik blijf meelezen, heb geen tijd om er zelf aan mee te doen.

[Zyppora]

evaarties schreef op woensdag 15 november 2006 @ 11:58:
Wie maakt de GUI .

Leuke contest wel en ik blijf meelezen, heb geen tijd om er zelf aan mee te doen.

Ik denk dat het zeker voor testdoeleinden makkelijk is om een GUI te gebruiken. Veel mensen hebben niet de capaciteit om adhv een setje MOVE_UP, MOVE_DOWN, etc. commands te evalueren of de laatste zet wel optimaal was, of dat er ergens een bug optreedt in de AI Ik zou alleen wel de GUI 'optioneel' maken, want daar wil je een vertraging in het droppen van de blokken in hebben, en die wil je juist niet bij de final run.

[.oisyn]

Verwijderd schreef op woensdag 15 november 2006 @ 02:47:
Overigens een tipje: Niet on the fly gaan roteren, das alleen maar overhead en je hebt maar 2 uur voor de output. Je hebt 10 vaste blokken (hoewel je dus niet weet hoe die eruit zien) en kunt ze dus gerust van te voren roteren en opslaan.

Nog een tip: helemaal niet gaan roteren, nergens voor nodig als je ze sec gaat gebruiken (als je bepaalde preprocessing ermee gaat doen dan natuurlijk wel, maar dan is het vrij obvious omdat rotatie dan net zo goed bij je preprocessing hoort). Want of je ze nou van links naar rechts, van boven naar beneden scant of van rechts naar links, van onder naar boven, je zal ze toch moeten scannen.

En denk eraan: 3x met de klok mee roteren is hetzelfde als 1 tegen de klok in te roteren. Ik denk dus (maar weet het niet zeker) dat je het tegen de klok in roteren maar beter geheel kunt weglaten en enkel met de klok mee kunt gebruiken. Dat maakt qua score niets uit en scheelt je waarschijnlijk overhead (en denkwerk?)

Denk helemaal niet aan roteren maar gewoon aan de vier mogelijke orientaties die een blokje kan hebben.

[Gerco]

.oisyn schreef op woensdag 15 november 2006 @ 12:05:
Denk helemaal niet aan roteren maar gewoon aan de vier mogelijke orientaties die een blokje kan hebben.

Daar ben ik het toch niet helemaal mee eens. Je moet wel degelijk rekening houden met rotatie wanneer je de MOVE LEFT/RIGHT commands geeft. De X blijft namelijk op dezelfde plaats bij rotatie en als je gewoon de oriëntatie van het blokje verandert, zul je die X toch nog even op de goede plaats moeten zetten voor je ermee kan doorrekenen.

[.oisyn]

Je gaat dus eerst kijken waar je blokje moet komen, en daarna ga je pas kijken hoe hij daar moet komen. Voor elke orientatie is het dan handig om op te slaan hoeveel rotaties en extra translaties tov het ijkpunt het is.

In pseudocode:

code:

[orientatie, x] = selecteer_beste_plek(speelveld, blokje);

for (i = 0; i < orientatie; i++)
    output ("ROTATE CW");

x += orientatie_ijkpunt[orientatie];
if (x < 0)
    for (i = 0; i < -x; i++)
        output ("MOVE LEFT");
else if (x > 0)
    for (i = 0; i < x; i++)
        output ("MOVE RIGHT");

[ Voor 48% gewijzigd door .oisyn op 15-11-2006 12:36 . Reden: left/right omgedraaid :P ]

[RobIII]

Dido schreef op woensdag 15 november 2006 @ 11:35:
[...]

Ik geef drie mogelijke blokjes, bij alle drie swap ik de x en y coordinaten, en ik krijg de gegeven uitkomsten. Geen rotatie, 1 rotatie of zelfs twee rotaties.

Euh... érgens lullen we langs mekaar Ik zal vanavond eens kijken wat ik nou bedoelde

[Zyppora]

Gerco schreef op woensdag 15 november 2006 @ 12:11:
[...]

Daar ben ik het toch niet helemaal mee eens. Je moet wel degelijk rekening houden met rotatie wanneer je de MOVE LEFT/RIGHT commands geeft. De X blijft namelijk op dezelfde plaats bij rotatie en als je gewoon de oriëntatie van het blokje verandert, zul je die X toch nog even op de goede plaats moeten zetten voor je ermee kan doorrekenen.

Daarnaast is het handig om te weten of een blokje uitsteekt over de rand of niet. Hoever het blokje geroteerd is, kan dus belangrijk zijn bij de bepaling van een vroegtijdige game over.

[Bint]

RobIII schreef op woensdag 15 november 2006 @ 02:50:
Tipje: X & Y coords swappen = roteren



^^ Kijk eens goed Wat gebeurt er als ik de X, Y swap ( Y, X )?

dat is toch WEL spiegelen?

kijk maar:


(1,1) -> (1,1)
(2,2) -> (2,2)
(3,2) -> (2,3)
(4,3) -> (3,4)
(1,4) -> (4,1)
(2,4) -> (4,2)
(3,4) -> (4,3)
(4,4) -> (4,4)
(5,4) -> (5,4)
(2,5) -> (5,2)

dit is roteren:


(1,1) -> (5,1) -> (5,5) -> (1,5)
(2,2) -> (4,2) -> (4,4) -> (2,4)
(3,2) -> (4,3) -> (3,4) -> (2,3)
(4,3) -> (3,4) -> (2,3) -> (3,2)
(1,4) -> (2,1) -> (5,2) -> (4,5)
(2,4) -> (2,2) -> (4,2) -> (4,4)
(3,4) -> (2,3) -> (3,2) -> (4,3)
(4,4) -> (2,4) -> (2,2) -> (4,2)
(5,4) -> (2,5) -> (1,2) -> (4,1)
(2,5) -> (1,2) -> (4,1) -> (5,4)

Onder swappen van x,y (4,5) versta ik x,y(5,4). Dus het kan zijn dat ik de term swappen niet snap, of het kan zijn dat jij het voud hebt.

EDIT:
anders wordt het, als je de x-as swapt met de y-as

PS: Nou lijkt mij het sterk dat jij het fout hebt, omdat ik maar net ga afstuderen, en jij al heel lang ervaring hebt, dus waarom ik hier de moeite in heb gestoken, weet ik ook niet. haha

[.oisyn]

Rob III heeft het wél fout

Ervanuitgaande dat +x naar rechts is en +y naar onder, en rotaties CW, heb je deze situaties:
0 graden:
start: (0, 0)
right: (1, 0)
down (0, 1)

90 graden:
start: (0, 4)
right: (0, -1)
down: (1, 0)

180 graden:
start: (4, 4)
right: (-1, 0)
down: (0, -1)

270 graden:
start: (4, 0)
right: (0, 1)
down: (-1, 0)

C++:

void rotateBlock(bool dest[5][5], bool src[5][5], int orientation)
{
    int srcRowX = orientation_info[orientation].startX;
    int srcRowY = orientation_info[orientation].startY;

    for (int y = 0; y < 5; y++)
    {
        int srcX = srcRowX;
        int srcY = srcRowY;

        for (int x = 0; x < 5; x++)
        {
            dest[y][x] = src[srcY][srcX];

            srcX += orientation_info[orientation].rightX;
            srcY += orientation_info[orientation].rightY;
        }

        srcRijX += orientation_info[orientation].downX;
        srcRijY += orientation_info[orientation].downY;
    }
}

[ Voor 6% gewijzigd door .oisyn op 15-11-2006 12:47 ]

[Bint]

.oisyn schreef op woensdag 15 november 2006 @ 12:43:
Rob III heeft het wél fout

Ervanuitgaande dat +x naar rechts is en +y naar onder, en rotaties CW, heb je deze situaties:
0 graden:
start: (0, 0)
right: (1, 0)
down (0, 1)

90 graden:
start: (0, 4)
right: (0, -1)
down: (1, 0)

180 graden:
start: (4, 4)
right: (-1, 0)
down: (0, -1)

270 graden:
start: (4, 0)
right: (0, 1)
down: (-1, 0)

C++:

void rotateBlock(bool dest[5][5], bool src[5][5], int orientation)
{
    int srcRowX = orientation_info[orientation].startX;
    int srcRowY = orientation_info[orientation].startY;

    for (int y = 0; y < 5; y++)
    {
        int srcX = srcRowX;
        int srcY = srcRowY;

        for (int x = 0; x < 5; x++)
        {
            dest[y][x] = src[srcY][srcX];

            srcX += orientation_info[orientation].rightX;
            srcY += orientation_info[orientation].rightY;
        }

        srcRijX += orientation_info[orientation].downX;
        srcRijY += orientation_info[orientation].downY;
    }
}

oh, dan had ik het toch goed
Hopen dat ie het wel goed had gedaan in zijn parser

[MrSleeves]

Bintje809 schreef op woensdag 15 november 2006 @ 12:35:
dit is roteren:
[afbeelding]

(1,1) -> (5,1) -> (5,5) -> (1,5)
(2,2) -> (4,2) -> (4,4) -> (2,4)
(3,2) -> (4,3) -> (3,4) -> (2,3)
(4,3) -> (3,4) -> (2,3) -> (3,2)
(1,4) -> (2,1) -> (5,2) -> (4,5)
(2,4) -> (2,2) -> (4,2) -> (4,4)
(3,4) -> (2,3) -> (3,2) -> (4,3)
(4,4) -> (2,4) -> (2,2) -> (4,2)
(5,4) -> (2,5) -> (1,2) -> (4,1)
(2,5) -> (1,2) -> (4,1) -> (5,4)

Met X dus op (3,3). Oftewel: het blokje wat jij daar maakt, kan niet voorkomen, omdat (3,3) leeg is.
En een leeg blokje kan geen rotatiepunt zijn. Maargoed, dat is in jouw voorbeeld niet relevant.

[Rainmaker1987]

VOlgens mij maakt het hiermee niet echt uit waar de x staat. De volgende stap die je hierna gewoon moet doen is de x weer op de juiste plaats zetten. Het roteren doe je volgens mij ook voordat je naar links/rechts gaat schuiven. Op die manier ondervang je meteen het probleem van waar de x staat.

Ik ben overigens benieuwd wat ik hier van ga bakken. Bedrijfskunde is mijn studie en geen informatica ofzo, iets van AI heb ik dus nog nooit gehad.

(misschien dat ik win in de categorie minst overzichtelijke code?)

[.oisyn]

MrSleeves schreef op woensdag 15 november 2006 @ 12:58:
Met X dus op (3,3). Oftewel: het blokje wat jij daar maakt, kan niet voorkomen, omdat (3,3) leeg is.

Je moet roteren en transleren los van elkaar zien. Of was jij van plan een 5x5 blokje met het rotatiepunt in de linkerbovenhoek in een 9x9 grid te zetten?

.edit: Rainmaker1987 snapt het helemaal

[ Voor 5% gewijzigd door .oisyn op 15-11-2006 13:05 ]

[Dido]

.oisyn schreef op woensdag 15 november 2006 @ 13:04:
Je moet roteren en transleren los van elkaar zien. Of was jij van plan een 5x5 blokje met het rotatiepunt in de linkerbovenhoek in een 9x9 grid te zetten?

Eigenlijk wel, als je de benaming "rotatiepunt" letterlijk neemt. Dat heeft echter weinig zin: het zogenoemde rotatiepunt is helemaal niet relevant voor de rotatie, de rotatie vindt altijd plaats om (3,3).

Om verwarring te voorkomen is het misschien handiger om het ding te hernoemen naar iets wat de lading dekt. Anchorpoint of zo. Het enige van de X is immers een eenduidige coordinaat verschaffen (alleen horizontaal is relevant) voor je blok.

[NMe]

RobIII is een prtutser.

* NMe gaat intussen spek en bonen koken, voor wanneer ik mee ga doen.

[Gerco]

Dido schreef op woensdag 15 november 2006 @ 13:10:
Om verwarring te voorkomen is het misschien handiger om het ding te hernoemen naar iets wat de lading dekt. Anchorpoint of zo. Het enige van de X is immers een eenduidige coordinaat verschaffen (alleen horizontaal is relevant) voor je blok.

Rotatiepunt vind ik juist een hele duidelijke naam. Het maakt duidelijk dat wanneer je roteert, de X op zijn plaats blijft. Dat je dat doet door eerst te transformeren en dan pas te transleren is een implementatie detail.

Misschien zijn er wel mensen die een echte rotatie om punt X willen uitvoeren en daar fouten bij maken, die vang je op deze manier ook in de contest. Die mensen waren dus niet handig genoeg

[NMe]

Dido schreef op woensdag 15 november 2006 @ 13:10:
[...]

Eigenlijk wel, als je de benaming "rotatiepunt" letterlijk neemt. Dat heeft echter weinig zin: het zogenoemde rotatiepunt is helemaal niet relevant voor de rotatie, de rotatie vindt altijd plaats om (3,3).

Ehm, blokjes zijn maximaal 5x5 groot dus alleen bij de maximale grootte van een blokje is het rotatiepunt 3,3.

Om verwarring te voorkomen is het misschien handiger om het ding te hernoemen naar iets wat de lading dekt. Anchorpoint of zo. Het enige van de X is immers een eenduidige coordinaat verschaffen (alleen horizontaal is relevant) voor je blok.

Waarom zouden we het hernoemen? Het is aan de programmeur zelf om in te zien wat het handigst werkt.

[Zyppora]

Gerco schreef op woensdag 15 november 2006 @ 13:14:
[...]

Rotatiepunt vind ik juist een hele duidelijke naam. Het maakt duidelijk dat wanneer je roteert, de X op zijn plaats blijft. Dat je dat doet door eerst te transformeren en dan pas te transleren is een implementatie detail.

Je bedoelt waarschijnlijk roteren. Transformeren is volgens mij niet toegestaan (anders ga ik transformeren naar 10x een blok van 5 bij 5)

[Dido]

Gerco schreef op woensdag 15 november 2006 @ 13:14:
Rotatiepunt vind ik juist een hele duidelijke naam. Het maakt duidelijk dat wanneer je roteert, de X op zijn plaats blijft. Dat je dat doet door eerst te transformeren en dan pas te transleren is een implementatie detail.

Zit ook wel weer wat in, inderdaad.

Anyways, het lijkt me - het is al eerder aangehaald - niet zo'n heel gek idee als tzt de parser (of iig de functionaliteit ervan ) beschikbaar wordt gemaakt. Al is het maar om achteraf discussies als dit te voorkomen (en zeker als 99.9% van alle inzendingen binnen vijf blokken game-over is ).

[Gerco]

Zyppora schreef op woensdag 15 november 2006 @ 13:18:
Je bedoelt waarschijnlijk roteren. Transformeren is volgens mij niet toegestaan (anders ga ik transformeren naar 10x een blok van 5 bij 5)

Met transformeren bedoel ik hier het veranderen van de matrix op wat voor manier dan ook. Welke manieren volgens de spelregels zijn toegelaten laat ik me niet over uit

[DaCoTa]

Ik gebruik juist een matrix van 9x9 met het rotatiepunt exact in het midden. Dan past ieder blokje erin en blijven alle matrixen even groot, dat maakt de plaatsing van blokken later een stuk eenvoudiger.

[EdwinG]

Dido schreef op woensdag 15 november 2006 @ 13:19:
(en zeker als 99.9% van alle inzendingen binnen vijf blokken game-over is ).

Zou wel erg knap zijn trouwens, met een maximale hoogte van 5 blokjes per blok kun je met 5 blokken tot 25 van de 40 blokjes komen.

[MrSleeves]

.oisyn schreef op woensdag 15 november 2006 @ 13:04:
[...]

Je moet roteren en transleren los van elkaar zien. Of was jij van plan een 5x5 blokje met het rotatiepunt in de linkerbovenhoek in een 9x9 grid te zetten?

Uit de TS:

Een 1 geeft, uiteraard, aan dat op die plaats een deel van het blokje zit, en een 0 dat er op die plaats niets zit. De X geeft, naast het feit dat er op die plaats een deel van het blokje zit, ook het rotatiepunt aan waaromheen een blokje geroteerd kan worden.

Het is logisch dat bij een 5x5-blok het X-coördinaat op (3,3); anders is roteren niet echt mogelijk.
Maar dat wil natuurlijk niet zeggen dat dat X-coördinaat dan maar weggelaten kan worden.

Anders is het misschien beter om altijd 5x5-raster in het textbestand te zetten met een virtuele X in het midden (op (3,3) of bij als de linkerbovenhoek (0,0) is, (2,2).

[eamelink]

Ja ho eens even, zo ga ik natuurlijk nooit tentamens halen voor het komende blok

Ik denk dat ik heel die server gewoon vol ga pompen met een oneindige random left/right/rotate sequence voor 1 blokje

Bah, wat vervelend zo'n contest . Eerst maar eens een taal kiezen

[NMe]

MrSleeves schreef op woensdag 15 november 2006 @ 13:25:
Het is logisch dat bij een 5x5-blok het X-coördinaat op (3,3); anders is roteren niet echt mogelijk.

Waarom niet? Je kan toch gewoon de complete matrix roteren en daarna de X op de goede plaats (waar hij al stond) positioneren. Dat is toch geen punt, of de X nu op (3,3) zit of op (2,5)?

[Dido]

EdwinG schreef op woensdag 15 november 2006 @ 13:25:
Zou wel erg knap zijn trouwens, met een maximale hoogte van 5 blokjes per blok kun je met 5 blokken tot 25 van de 40 blokjes komen.

Is helemaal niet moeilijk, in 1 beurt GO:
ROTATE CW
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
DROP


Maar het zou dus kunnen dat je denkt dat het kan, omdat de positie van je kruisje bij de rotate naar links verplaatst

-NMe- schreef op woensdag 15 november 2006 @ 13:30:
Waarom niet? Je kan toch gewoon de complete matrix roteren en daarna de X op de goede plaats (waar hij al stond) positioneren. Dat is toch geen punt, of de X nu op (3,3) zit of op (2,5)?

Er is denk ik wat verwarring betreffende het positioneren van je X binnen je 5x5 matrix, en het positioneren van je X boven je speelveld (waar jij, hoop ik, op doelt).

[ Voor 30% gewijzigd door Dido op 15-11-2006 13:34 ]

[Gerco]

Zijn er nog mensen van plan om hun implementatie te publiceren (uiteraard zonder source) voor het einde van de contest?

Worden inzendingen in Progress 4GL geaccepteerd (aangezien ik daar goed bekend mee ben), die kunnen namelijk alleen met de $$$$$-kostende Progress runtime gedraaid worden. Misschien heeft 1 van de juryleden Progress bij de hand?

[.oisyn]

MrSleeves schreef op woensdag 15 november 2006 @ 13:25:
[...]


Uit de TS:

[...]

Het is logisch dat bij een 5x5-blok het X-coördinaat op (3,3); anders is roteren niet echt mogelijk.
Maar dat wil natuurlijk niet zeggen dat dat X-coördinaat dan maar weggelaten kan worden.

Ik snap totaal niet wat die passage en jouw uitleg met mijn opmerking te maken heeft. Je moet een paar dingen van elkaar onderscheiden: de data van het blokje (dus welk subblokje wel is gevuld en welke niet, dit zou je met een 5x5 grid kunnen implementeren), en de configuratie waarmee hij uiteindelijk in het veld terecht komt.

De X is belangrijk voor de configuratie, niet voor de data. Een 5x5 blokje met het rotatiepunt in de linkerbovenhoek kun je dus prima binnen een 5x5 grid roteren. De plek van de X bepaalt echter wel op welke plaats hij uiteindelijk in het veld terecht komt, gegeven z'n initiele positie en een aantal MOVE en ROTATE commando's.

Omgekeerd gaat jouw algoritme waarschijnlijk in eerste instantie niet uit van MOVE en ROTATE commando's, maar bepaalt hij de beste configuratie van dat blokje in het speelveld. Aan de hand van die configuratie bepaal je vervolgens welke commando's je moet uitvoeren, en daar komt de X pas bij kijken, zoals ik hier liet zien (daar heb ik de X dus omgezet in een relatief x-coordinaat tov de hoofd-orientatie).

[ Voor 21% gewijzigd door .oisyn op 15-11-2006 13:44 ]

[NMe]

Dido schreef op woensdag 15 november 2006 @ 13:31:
Er is denk ik wat verwarring betreffende het positioneren van je X binnen je 5x5 matrix, en het positioneren van je X boven je speelveld (waar jij, hoop ik, op doelt).

Het gaat er gewoon om dat tijdens het roteren de positie van de X totaal onbelangrijk is. Pas na het roteren moet je zorgen dat de X in het speelveld nog op dezelfde plaats staat als voor de rotatie, maar dat heeft niets te maken met het roteren om een punt (3,3). Sure, daar kán de X staan, maar dat hoeft zeker niet.

[MrSleeves]

.oisyn schreef op woensdag 15 november 2006 @ 13:37:
[...]

Ik snap totaal niet wat die passage en jouw uitleg met mijn opmerking te maken heeft. Je moet een paar dingen van elkaar onderscheiden: de data van het blokje (dus welk subblokje wel is gevuld en welke niet, dit zou je met een 5x5 grid kunnen implementeren), en de configuratie waarmee hij uiteindelijk in het veld terecht komt.

Ik snap de bedoeling. Ik ging er vanuit dat er binnen een 5x5-blok geroteerd werd. Maar dat hoeft natuurlijk niet.

[seamus21]

Bintje809 schreef op woensdag 15 november 2006 @ 11:51:
DIngen die duidelijk in de Startpost staan, die gewoon nog een keer gevraagd worden? Zal leuk worden als je dadelijk in het bedrijfsleven een stuk software aflevert, waar de helft niet van klopt, omdat er "niet goed gelezen is".

Hier wil ik toch nog even op inhaken. Je mag mazzel hebben als je gemiddeld in het bedrijfsleven tegen specs aanloopt waar zo goed lezen van toepassing is. Daarnaast kan je juist het beter nog een keer vragen dan het niet snappen en gaan programmeren en dan crap software afleveren. Je wil alles juist op een rij hebben voordat je begint aan de implementatie.

[ Voor 5% gewijzigd door seamus21 op 15-11-2006 13:50 ]

[Bint]

eamelink schreef op woensdag 15 november 2006 @ 13:28:
Ja ho eens even, zo ga ik natuurlijk mijn nooit tentamens halen voor het komende blok

Ik denk dat ik heel die server gewoon vol ga pompen met een oneindige random left/right/rotate sequence voor 1 blokje

Bah, wat vervelend zo'n contest . Eerst maar eens een taal kiezen

Nederlands misschien?

nee geintje en dat oneindig roteren: dan weet je in ieder geval zeker de minste punten hebt, haha!

[Zyppora]

eamelink schreef op woensdag 15 november 2006 @ 13:28:
Ja ho eens even, zo ga ik natuurlijk nooit tentamens halen voor het komende blok

Ik denk dat ik heel die server gewoon vol ga pompen met een oneindige random left/right/rotate sequence voor 1 blokje

Bah, wat vervelend zo'n contest . Eerst maar eens een taal kiezen

Maar wel eerste plaats voor 'meest nutteloos ontwerp'

[Bint]

seamus21 schreef op woensdag 15 november 2006 @ 13:49:
[...]
Hier wil ik toch nog even op inhaken. Je mag mazzel hebben als je gemiddeld in het bedrijfsleven tegen specs aanloopt waar zo goed lezen van toepassing is. Daarnaast kan je juist het beter nog een keer vragen dan het niet snappen en gaan programmeren en dan crap software afleveren. Je wil alles juist op een rij hebben voordat je begint aan de implementatie.

Daar heb je eigenlijk wel gelijk in, denk ik. Maar ik blijf erbij: goed lezen is altijd goed. voor de mensen die geen zin hebben om een hele lap tekst door te nemen:

code:

Spelregels Voor tetrislike- AI:

* Speelveld:
 - 15 vakjes breed
 - 40 vakjes hoog

* Besturing:
 - MOVE LEFT:   blokje een positie naar links
 - MOVE RIGHT:  blokje een positie naar rechts
 - ROTATE CW:   Draai blokje een kwartslag met de klok mee (naar rechts, voor de mensen die een digitale klok hebben thuis)
 - ROTATE CCW:  Draai een blokje een kwartslag tegen de klok in (naar links dus).
 - DROP:    Dropt het bloje naar beneden
 - NEW BLOCK:   pak nieuw blokje (kan alleen als eerste zet in het spel, en NA een drop of discard!)
 - DISCARD: gooi het huidige blokje weg. Dit kan 5x!

* De blokken worden pas na de contest vrijgegeven.
 - De blokken hebben een maximale afmeting van 5x5
 - Deze blokken worden gedefinieerd in files met een numerieke naam: 0.txt .. 9.txt
 - De inhoud per file is als volgt:
    010
    1X1
 - een 1 geeft aan dat er een blokje zit op die plek
 - een X geeft aan dat er een blokje zit, en het draaipunt.
 - een 0 geeft aan dat er niks is.
 - Door middel van enters worden er nieuwe rijen gemaakt in de files. Dit gebeurt volgens de windows manier: \r\n
 - Er wordt ook een game.txt geleverd. Deze bevat een onafgebroken rij getallen. elk getal representeert een blokje.
    voorbeeld: 4563234 betekent dat blokje 4 eerst komt, gevolgt door: 5, 6, 3, 2, 3, 4
 - Over het aantal blokjes in de game.txt is weinig bekend: minimum: 1 maximum: 2^31-1

* Tijdens het spel:
 - Als het commando 'NEW BLOCK'is aangeroepen, verschijnt er een blokje in het midden van het veld, in kolom 8 dus. De X in het blokje bepaald
    het 'midden' van het blokje!
 - Je kunt het blokje op dat moment draaien, en naar links of naar rechts verplaatsen
 - Op het moment van drop valt het naar beneden, en dan is er geen verplaatsing//draai meer mogelijk
 - Als een deel van het blokje zich BUITEN het speelveld bevind na een DROP, ben je af. Je blokje telt dan niet meer mee voor de puntentelling.
 - Dit is dus links, rechts, of boven het speelveld!
 - Als er lijnen worden weggespeeld, zakken de blokjes die zich eventueel boven de lijn bevonden evenveel lijnen naar beneden als er weggespeeld zijn, ook als er ruimte vrij is onder de weggespeelde lijnen. Er is dus geen "zwaartekracht"!

* Puntentelling:
 - plaatsen van een blokje:     10  punten
 - 1 lijn verwijderen:      50  punten
 - 2 lijnen verwijderen:    150 punten
 - 3 lijnen verwijderen:    300 punten
 - 4 lijnen verwijderen:    500 punten
 - 5 lijnen verwijderen:    750 punten
 - na game over:        400 punten PER DISCARD left.

* De leiding gelooft je eigen puntentelling niet! daarom moet je AL je moves vastleggen in een output.txt
* kan je output.txt niet gelezen worden, of snapt de parser hem niet: game over
* Je progsel wordt 2 uur gedraait door de leiding: daarna ben je game over. Heb je je uitvoer na 2 uur nog niet weggeschreven: 0 punten!
* het is verboden om brainfuck te gebruiken ;)
* Lever een executable.. de leiding heeft geen zin om alles zelf te moeten compileren
* er is maar 1 invoer mogelijk! dus heb je het vernaggeld om een of andere reden: je 2e invoer zal altijd naar /dev/null gaan!

[PiepPiep]

Dido schreef op woensdag 15 november 2006 @ 13:31:
[...]
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
MOVE RIGHT
[...]

Is het niet een idee om een
MOVE x RIGHT
toe te voegen voor de parser? waar x van 1 tot 9 mag zijn bijvoorbeeld.
De MOVE RIGHT zijn al 12 tekens (inc CR/LF)
Bij gemiddeld 4 keer verschuiven kost dat 48 bytes, dan nog DROP en nieuw blokje vragen zit je snel op 60 a 70 keer meer bytes in de uitvoer dan in de invoer.

[RobIII]

Bintje809 schreef op woensdag 15 november 2006 @ 12:49:
oh, dan had ik het toch goed
Hopen dat ie het wel goed had gedaan in zijn parser

Ja, ik zat er langs te lullen. Het was al laat
Je moet namelijk niet X=Y en Y=X doen maar X=Hoogte-Y, Y=X doen Dan corrigeer je het spiegelen ook meteen

Anyway, maak je niet druk, die parser klopt echt wel (zeker omdat ik het kan controleren omdat ik een grafische schil er om heen heb die het gewoon toont )

[seamus21]

-NMe- schreef op woensdag 15 november 2006 @ 13:43:
[...]

Het gaat er gewoon om dat tijdens het roteren de positie van de X totaal onbelangrijk is. Pas na het roteren moet je zorgen dat de X in het speelveld nog op dezelfde plaats staat als voor de rotatie, maar dat heeft niets te maken met het roteren om een punt (3,3). Sure, daar kán de X staan, maar dat hoeft zeker niet.

Oftewel doe eerst al je rotatie behoeftes buiten het speelveld zorg dat de x weer terug op het achtste hokje komt en ga dan moven.

Maar als je dan toch wilt roteren binnen het speelveld bv in de volgende situaties. Mag dat?

I stukje


T stukje


Dit zijn gewoon voorbeelden maar ik kan me meer situaties voorstellen waarbij je een stuk wel door de bovenste rij kan proppen en daarna weer draaien om ergens tussen te krijgen. Mag je bij rotaties gedeeltes van blokken door andere heen draaien om de rotatie mogelijk te maken?

[Zyppora]

seamus21 schreef op woensdag 15 november 2006 @ 14:06:
[...]

Oftewel doe eerst al je rotatie behoeftes buiten het speelveld zorg dat de x weer terug op het achtste hokje komt en ga dan moven.

Maar als je dan toch wilt roteren binnen het speelveld bv in de volgende situaties. Mag dat?

I stukje
[afbeelding]

T stukje
[afbeelding]

Dit zijn gewoon voorbeelden maar ik kan me meer situaties voorstellen waarbij je een stuk wel door de bovenste rij kan proppen en daarna weer draaien om ergens tussen te krijgen. Mag je bij rotaties gedeeltes van blokken door andere heen draaien om de rotatie mogelijk te maken?

Volgens mij is dit in de TS al beantwoord: draaien is alleen mogelijk VOOR je een DROP doet.

[Megamind]

Nee want er was al gezegd dat de blokjes niet naar beneden vallen. Draaien, moven en droppen.

[seamus21]

Megamind schreef op woensdag 15 november 2006 @ 14:09:
Nee want er was al gezegd dat de blokjes niet naar beneden vallen. Draaien, moven en droppen.

Als dat echt zo is en je werkt ook nog eens met exotische blokken dan wordt er namelijk niets aan. Je kan dan eigenlijk alleen maar blokken stapelen bovenop en hopen dat je boven wat lines kan maken. Als je dan met hele vage blokken komt te werken ben je zo af.

Stel je eens voor dat je hele vage blokken hebt en je krijgt ze toevallig ook nog eens in een klote volgorde en je kan ze eigenlijk alleen maar bovenop plaatsen omdat je er niet eerst tussendoor mag moven. Voorbeeldje:

[ Voor 24% gewijzigd door seamus21 op 15-11-2006 14:18 ]

[eamelink]

Overigens is dit een mooi moment voor alle actieve deelnemers om irc://irc.tweakers.net#devschuur weer een fijne impuls te geven

[Zyppora]

seamus21 schreef op woensdag 15 november 2006 @ 14:11:
[...]

Als dat echt zo is en je werkt ook nog eens met exotische blokken dan wordt er namelijk niets aan. Je kan dan eigenlijk alleen maar blokken stapelen bovenop en hopen dat je boven wat lines kan maken. Als je dan met hele vage blokken komt te werken ben je zo af.

Hoeft helemaal niet. Er zullen vast een paar smerige blokken tussen zitten, maar ik denk (hoop) dat de organisatoren ons daarin een beetje zullen ontzien en wat meer (Tetris-)classic blokken zullen gebruiken. Daarnaast: als het voor jou (als naar ik aanneem doorgewinterde software devver) te pittig is, zullen er meer zijn die er problemen mee hebben, en zullen de blokken (of de sequentie uit game.txt) toch aangepast moeten worden.

Maar zoals al eerder gezegd: het gaat niet om de blokken, maar hoe jouw AI daarmee omgaat.

[Verwijderd]

Soultaker schreef op dinsdag 14 november 2006 @ 17:29:
Cool idee!

Begrijp ik nu goed dat een blokje strict boven het speelveld verplaatst/geroteerd wordt voordat 'ie gedropt wordt? (Waarom zijn er dan aparte commando's voor het verplaatsen/roteren i.p.v. een "DROP <kolom> <rotatie>" commando?)

Ja, en waar is "NEW BLOCK" voor? Na iedere DROP danwel DISCARD is een NEW BLOCK toch verplicht? Waarom die dan niet impliciet laten?

[seamus21]

Zyppora schreef op woensdag 15 november 2006 @ 14:17:
[...]


Hoeft helemaal niet. Er zullen vast een paar smerige blokken tussen zitten, maar ik denk (hoop) dat de organisatoren ons daarin een beetje zullen ontzien en wat meer (Tetris-)classic blokken zullen gebruiken. Daarnaast: als het voor jou (als naar ik aanneem doorgewinterde software devver) te pittig is, zullen er meer zijn die er problemen mee hebben, en zullen de blokken (of de sequentie uit game.txt) toch aangepast moeten worden.

Maar zoals al eerder gezegd: het gaat niet om de blokken, maar hoe jouw AI daarmee omgaat.

Kijk nog even naar het plaatje wat ik er net bij heb gepost. Het is dus wel van belang want je AI kan zo slim zijn als je wilt maar als je alleen maar eerst kan rotaten en na een drop is het klaar dan blijft het feit gewoon dat je heel snel krijgt dat je alleen maar aan het stapelen bent.

Wat mij een idee lijkt is om een MOVE DOWN of SOFT DROP te introduceren en een afspraak te maken of je wel of niet door bestaande blokjes heen kan rotaten. Zelfs als je niet met exotische blokken set werkt dan kan dat stapelen een issue zijn.

[ Voor 11% gewijzigd door seamus21 op 15-11-2006 14:23 ]

[evaarties]

Bintje809 schreef op woensdag 15 november 2006 @ 13:53:
[...]


- Als er lijnen worden weggespeeld, blijven de blokjes die zich eventueel boven de lijn bevonden, zweven. Ze zakken dus niet naar beneden!

Da's dus niet helemaal waar. De blokjes vallen niet helemaal naar beneden, wel worden blokjes zoveel naar beneden verplaatst als er lijnen zijn verwijderd (zie plaatjes in TS).

[Zyppora]

seamus21 schreef op woensdag 15 november 2006 @ 14:20:
[...]

Kijk nog even naar het plaatje wat ik er net bij heb gepost. Het is dus wel van belang want je AI kan zo slim zijn als je wilt maar als je alleen maar eerst kan rotaten en na een drop is het klaar dan blijft het feit gewoon dat je heel snel krijgt dat je alleen maar aan het stapelen bent.

Wat mij een idee lijkt is om een MOVE DOWN of SOFT DROP te introduceren en een afspraak te maken of je wel of niet door bestaande blokjes heen kan moven. Zelfs als je niet met exotische blokken set werkt dan kan dat stapelen een issue zijn.

Heb het plaatje gezien. Als jouw AI dat doet met die blokken, zou ik toch nog eens naar de code kijken Vooral het L-vormige grijze blok linksonder verdient volgens mij niet de 'I' in AI. Daarnaast krijg je alle tijd om een blok dusdanig to roteren en verplaatsen tot het zo is zoals jouw AI het 'goed' vindt. De enige tijdslimiet die je hebt is de 2 uur die je krijgt om punten te sprokkelen.

[Gerco]

Zyppora schreef op woensdag 15 november 2006 @ 14:24:
De enige tijdslimiet die je hebt is de 2 uur die je krijgt om punten te sprokkelen.

Daarnaast is het natuurlijk ook mogelijk (zelfs vereist voor enigzins interessant resultaat, lijkt me) om vooruit te kijken welke blokken je allemaal krijgt. Je kan best een implementatie maken die 100 blokjes vooruit berekent om tot het beste resultaat te komen. Of je dan de 2 uur nog haalt is natuurlijk wel een probleempje..

[Zyppora]

Gerco schreef op woensdag 15 november 2006 @ 14:31:
[...]

Daarnaast is het natuurlijk ook mogelijk (zelfs vereist voor enigzins interessant resultaat, lijkt me) om vooruit te kijken welke blokken je allemaal krijgt. Je kan best een implementatie maken die 100 blokjes vooruit berekent om tot het beste resultaat te komen. Of je dan de 2 uur nog haalt is natuurlijk wel een probleempje..

Da's natuurlijk een afweging die je moet maken: hoever ga je vooruit rekenen vs. hoeveel tijd per blokje. Als er geen tijdslimiet was, lees je vrolijk het hele game.txt bestand uit en ga je adhv een of ander algoritme de blokken zo passen dat er geen gaten voorkomen. Duurt inderdaad veel te lang.

Wat je kunt doen is kijken bij hoeveel blokken vooruit kijken, het plannen nuttig/tijdsefficient is.

[ Voor 3% gewijzigd door Zyppora op 15-11-2006 14:34 ]

[Rainmaker1987]

Ik denk dat je dan meer een soort van schaakachtige oplossing moet creeëren waarbij je een stuk of 10 zetten continu vooruit denkt. De uitkomst daarvan moet je dan evalueren en waardes meegeven en dan de beste optie weergeven.

Per blokje heb je maximaal 60 mogelijkheden, onnodige mogelijkheden ook meegerekent (dit is namelijk een voorbeeld met een blokje van 1 bij 1 en dan 15 dropmogelijkheden × 4 rotaties)

(daarbij aan te geven dat ik nog maar bezig ben met het roteren hoor)

Zyppora en ik zijn het volgens mij met elkaar eens

[ Voor 5% gewijzigd door Rainmaker1987 op 15-11-2006 14:37 . Reden: Rainmaker moet sneller typen ]

[Creepy]

seamus21 schreef op woensdag 15 november 2006 @ 14:20:
[...]

Kijk nog even naar het plaatje wat ik er net bij heb gepost. Het is dus wel van belang want je AI kan zo slim zijn als je wilt maar als je alleen maar eerst kan rotaten en na een drop is het klaar dan blijft het feit gewoon dat je heel snel krijgt dat je alleen maar aan het stapelen bent.

Wat mij een idee lijkt is om een MOVE DOWN of SOFT DROP te introduceren en een afspraak te maken of je wel of niet door bestaande blokjes heen kan rotaten. Zelfs als je niet met exotische blokken set werkt dan kan dat stapelen een issue zijn.

Er is *bewust* voor gekozen om niet meer te roteren zodra een blok is gedropt. Een paar regels droppen, vervolgens een rotate en een move is dus NIET mogelijk. Een horizontaal gat opvullen via de zijkanten is dus NIET mogelijk. Je zult dus de regels erboven leeg moeten spelen om dat gat op te kunnen vullen. En nee, dat gaan we ook niet veranderen. Het staat duidelijk in de regels uitgelegd en daar pas je je AI dan ook maar op aan. Zo wordt het wat moeilijker om een kant en klare tetris AI van het net af te plukken.

Aangezien het draaien dus boven het speelveld gebeurd bestaan er dus ook geen situaties dat je bij een draai moet controleren of het blokje uberhaupt wel kan draaien. Een DROP betekent dus ook altijd dat het blokje direct zo ver mogelijk naar beneden valt bovenop een ander blok. Na een DROP volgt dus ook altijd een NEW BLOCK.

Het is een tetris LIKE competitie. Het is dus geen tetris

[ Voor 21% gewijzigd door Creepy op 15-11-2006 14:44 ]

[seamus21]

Zyppora schreef op woensdag 15 november 2006 @ 14:24:
[...]


Heb het plaatje gezien. Als jouw AI dat doet met die blokken, zou ik toch nog eens naar de code kijken Vooral het L-vormige grijze blok linksonder verdient volgens mij niet de 'I' in AI. Daarnaast krijg je alle tijd om een blok dusdanig to roteren en verplaatsen tot het zo is zoals jouw AI het 'goed' vindt. De enige tijdslimiet die je hebt is de 2 uur die je krijgt om punten te sprokkelen.

Het was ook maar een voorbeeld. Maar het is wel om aan te geven als je niet de mogelijkheid om je blok naar beneden te moven en daarna te roteren dat je dus zo een stapel effect krijgt. Hoe exotischer de blokken hoe eerder je af bent en hoe eerder je dus wel alle blokken moet vooruitdenken wil je uberhaupt nog een aardige score halen.

Wil niet wegnemen dat ik dat vervelend vind wilde het alleen duidelijk hebben voordat ik eraan begin

Lol ik bedoelde dus heel wat anders.. Ik vind het niet erg maar wil het wel duidelijk hebben voordat ik eraan begin

Creepy schreef op woensdag 15 november 2006 @ 14:40:
[...]
Na een DROP volgt dus ook altijd een NEW BLOCK.

Totdat het txt bestand leeg is.

[ Voor 28% gewijzigd door seamus21 op 15-11-2006 15:11 ]

[Zyppora]

seamus21 schreef op woensdag 15 november 2006 @ 14:44:
[...]

Het was ook maar een voorbeeld. Maar het is wel om aan te geven als je niet de mogelijkheid om je blok naar beneden te moven en daarna te roteren dat je dus zo een stapel effect krijgt. Hoe exotischer de blokken hoe eerder je af bent en hoe eerder je dus wel alle blokken moet vooruitdenken wil je uberhaupt nog een aardige score halen.

Ik denk overigens dat je het voor jezelf stukken moeilijker maakt als je met dat soort manouvreer-acties aan de haal gaat. Hoe berekent jouw AI dat het huidige blokje precies in dat gat past (inclusief de weg ernaartoe)? Tuulijk gaan we stapel-acties krijgen, maar ook 'past dit hier' en 'maak ik hier een volledige lijn mee'. En DAT is wat jouw AI dus moet gaan doen.

[seamus21]

Zyppora schreef op woensdag 15 november 2006 @ 14:48:
[...]


Ik denk overigens dat je het voor jezelf stukken moeilijker maakt als je met dat soort manouvreer-acties aan de haal gaat. Hoe berekent jouw AI dat het huidige blokje precies in dat gat past (inclusief de weg ernaartoe)? Tuulijk gaan we stapel-acties krijgen, maar ook 'past dit hier' en 'maak ik hier een volledige lijn mee'. En DAT is wat jouw AI dus moet gaan doen.

Het gaat er mij nu niet om hoe ik dingen moet oplossen maar wel welke regels ik moet hanteren. En nu zijn ze voor mij denk wel allemaal helder.

[NMe]

seamus21 schreef op woensdag 15 november 2006 @ 14:44:
Wil niet wegnemen dat ik dat vervelend vind wilde het alleen duidelijk hebben voordat ik eraan begin

Het is alleen vervelend wanneer jou AI niet slim genoeg is om handig te draaien, wat je ook mooi hebt geïllustreerd met die fout geroteerde L die je ergens als eerste hebt neergezet. We gaan echt geen lading supersmerige blokjes maken, maar er zouden wat "gemene" blokjes bij kunnen zijn. Hoe dan ook is het voor een goeie AI geen probleem dat alles alleen van bovenaf in place kan droppen.

Totdat het txt bestand leeg is.

D'oh.

Overigens pas ik even de beknopte versie van de TS hierboven aan zodat er geen leugens in staan.

[Bint]

nopg een vraagje.. heb het begintopic al een paar keer doorgelezen, maar de 0.txt .. 9.txt bestandjes, komen die in de root te staan, of in een speciale map? lijkt me wel dat je applicatie die dingen automagisch moet kunnen inlezen he

[Creepy]

Die komen in dezelfde directory te staan als je executable.

[Bio]

Ik heb hier waarschijnlijk absoluut niet de skills voor, maar als ik de tijd kan vinden ga ik het wel proberen

Maakt de taal nog veel uit, voor de snelheid bijvoorbeeld?

[Bint]

Jo-hannes schreef op woensdag 15 november 2006 @ 15:05:
Ik heb hier waarschijnlijk absoluut niet de skills voor, maar als ik de tijd kan vinden ga ik het wel proberen

Maakt de taal nog veel uit, voor de snelheid bijvoorbeeld?

ligt aan je skills
als je goed assembly kunt, zal het waarschijnlijk wel sneller zijn dan C#. Maar als je goed assembly kunt, zou je dit niet vragen waarschijnlijk. Voor de rest moet je eerst maar eens kijken of je die 2 uur wel vol krijgt, en dan maakt die snelheid opeens weinig meer uit

[seamus21]

-NMe- schreef op woensdag 15 november 2006 @ 14:55:
[...]

Het is alleen vervelend wanneer jou AI niet slim genoeg is om handig te draaien, wat je ook mooi hebt geïllustreerd met die fout geroteerde L die je ergens als eerste hebt neergezet. We gaan echt geen lading supersmerige blokjes maken, maar er zouden wat "gemene" blokjes bij kunnen zijn. Hoe dan ook is het voor een goeie AI geen probleem dat alles alleen van bovenaf in place kan droppen.

[...]

D'oh.

Overigens pas ik even de beknopte versie van de TS hierboven aan zodat er geen leugens in staan.

Lol ik had mn post aangepast ik bedoelde het dus niet zo met dat vervelend. Ik bedoelde dat ik het niet erg vond.

[EdwinG]

seamus21 schreef op woensdag 15 november 2006 @ 14:11:
Voorbeeldje:

[afbeelding]

edit:
Hmm, we waren al verder in het topic

quote: -NMe-

Overigens pas ik even de beknopte versie van de TS hierboven aan zodat er geen leugens in staan.

Pas dan ook regel 13 even aan, een NEW BLOCK mag ook na DISCARD

[ Voor 30% gewijzigd door EdwinG op 15-11-2006 15:22 ]

[.oisyn]

Bintje809 schreef op woensdag 15 november 2006 @ 15:09:
[...]


ligt aan je skills
als je goed assembly kunt, zal het waarschijnlijk wel sneller zijn dan C#.

Zoals gewoonlijk is ook hier het gebruikte algoritme hetgene wat je in eerste instantie moet optimaliseren. Een brute force algo in asm gaat echt niet sneller zijn dan een degelijk algo in C#, hoe goed je ook bent met assembly. Daarna kun je evt. nog instructieneuken, maar dat scheelt echt niet meer zoveel performance.

[.oisyn]

EdwinG schreef op woensdag 15 november 2006 @ 15:13:
[...]

Slechte parser, als die grote 'hoek' linksonder op die manier geplaatst wordt.

Nou heb ik het woord "parser" al in veel contexten verkeerd gebruikt zien worden, maar dit slaat toch wel alles

[NMe]

Bintje809 schreef op woensdag 15 november 2006 @ 15:01:
nopg een vraagje.. heb het begintopic al een paar keer doorgelezen, maar de 0.txt .. 9.txt bestandjes, komen die in de root te staan, of in een speciale map? lijkt me wel dat je applicatie die dingen automagisch moet kunnen inlezen he

Het staat er toch echt in.

-NMe- schreef op dinsdag 14 november 2006 @ 14:50:
8. Alle genoemde tekstbestanden bevinden zich in dezelfde directory als het uitvoerbare bestand van je programma.

[Verwijderd]

Om nog eens even op het roteren terug te komen.

Zoals al genoemd is het gemakkelijkste om een 9x9 matrix te pakken met de X op 4,4. Op die manier kun je draaien wat je wil, je blokje blijft kloppend en je hoeft nergens iets te corrigeren.

Translatie is inderdaad nieuwe x = breedte - oude y, nieuwe y = oude x

Das een perfecte rotatie met de klok mee zonder ergens over na te denken.

Dit is de manier waarop ik het doe en grafisch ziet dat er prima uit. Ook omdat de X op een vaste plek staat hoef je met het positioneren niets meer te corrigeren.

Ook een klein tipje: Genereer van te voren wat statistieken over de blokjes (in alle standen), dat scheelt je rekenwerk on-the-fly.

Of mag ik niet meer zeggen dat het sneller moet omdat we anders de 2 uur niet halen?

[PhysicsRules]

Leuk idee! PhysicsRules gaat eens wat tijd zoeken.

[.oisyn]

TRRoads: Als je tips wil geven hoe het sneller kan geef dan vooral niet die 9x9 grid als tip
Lees deze, deze en deze posts nog eens

[ Voor 89% gewijzigd door .oisyn op 15-11-2006 15:25 ]

[NMe]

Verwijderd schreef op woensdag 15 november 2006 @ 15:20:
Om nog eens even op het roteren terug te komen.

Zoals al genoemd is het gemakkelijkste om een 9x9 matrix te pakken met de X op 4,4. Op die manier kun je draaien wat je wil, je blokje blijft kloppend en je hoeft nergens iets te corrigeren.

Ik meen me te herinneren dat een hoop mensen juist gezegd hebben dat dat juist minder handig is omdat je dan die punten opnieuw moet berekenen, terwijl er geen rekenwerk nodig is als je het blokjesarray gewoon vanaf de andere kant begint uit te lezen.

Of mag ik niet meer zeggen dat het sneller moet omdat we anders de 2 uur niet halen?

Je wordt er in elk geval niet geloofwaardiger op daar daarop te blijven hameren.

[seamus21]

EdwinG schreef op woensdag 15 november 2006 @ 15:13:
[...]

edit:
Hmm, we waren al verder in het topic

[...]

Pas dan ook regel 13 even aan, een NEW BLOCK mag ook na DISCARD

Omg mensen dat is gewoon een voorbeeld in elkaar geknutseld om wat over rotatie te illustreren en exotische blokken. Dit is NIET mijn AI ofzo en al zeker niet mijn 'parser'.

En ik ben het wel met de mods eens over dat 2 uur geneuzel. Dat lijkt me nou niet echt een issue. Ik denk dat nu wel alles helder is.

[ Voor 13% gewijzigd door seamus21 op 15-11-2006 15:27 ]

[Verwijderd]

.oisyn schreef op woensdag 15 november 2006 @ 15:21:
TRRoads: Als je tips wil geven hoe het sneller kan geef dan vooral niet die 9x9 grid als tip
Lees deze, deze en deze posts nog eens

Ohwjah 9x9 scheelt tov 5x5

Waar praten we over?

Ik vind het persoonlijk wel handiger omdat het X punt (het punt wat de positie van het blokje bepaald) statisch is.

[ Voor 12% gewijzigd door Verwijderd op 15-11-2006 15:32 ]

[Gerco]

Verwijderd schreef op woensdag 15 november 2006 @ 15:29:
Ik vind het persoonlijk wel handiger omdat het X punt (het punt wat de positie van het blokje bepaald) statisch is.

Wat maakt dat nu uit? Je gaat toch zeker eerst je blokje op alle mogelijke manieren passen en als je besloten hebt waar het moet komen ga je eens kijken hoe je de X op de plaats krijgt waar je die hebben wilt?

[DaCoTa]

.oisyn schreef op woensdag 15 november 2006 @ 15:21:
TRRoads: Als je tips wil geven hoe het sneller kan geef dan vooral niet die 9x9 grid als tip
Lees deze, deze en deze posts nog eens

Als het goed is, hoef je ieder blokje maar 3x te roteren voordat je begint toch? En als je daarna nog een setje aanmaakt waarin je bepaald waar je ieder blokje mag plaatsen, heb je van te voren een setje van maximaal 10x4x15 mogelijkheden die je direct kunt droppen. Die 15 is te hoog, omdat de meeste blokken breder dan 1 zijn en dus niet 7 naar links en 7 naar rechts mogen. Daarnaast zullen er bij de symmetrische blokken wat dubbelen zijn.

[Verwijderd]

Gerco schreef op woensdag 15 november 2006 @ 15:34:
[...]

Wat maakt dat nu uit? Je gaat toch zeker eerst je blokje op alle mogelijke manieren passen en als je besloten hebt waar het moet komen ga je eens kijken hoe je de X op de plaats krijgt waar je die hebben wilt?

Wat maakt dat uit? Je weet dat de X begint op kolom 8.
De AI komt op een gegeven moment na passen en meten met het resultaat: Hij moet in kolom 3 komen. Dan weet je dus dat je 5x MOVE LEFT moet ingeven om em op de juiste plek te krijgen.

Natuurlijk kun je ook iets schrijven wat zegt van hij staat op 8 - de shift vanwege rotatie en dan vanuit daar gaan positioneren naar kolom 3. Maar dat geeft je dus weer wat meer te doen terwijl dat anders niet nodig is.

De simpelste oplossing was het makkelijkste toch?

[.oisyn]

Verwijderd schreef op woensdag 15 november 2006 @ 15:29:
[...]


Ohwjah 9x9 scheelt tov 5x5

Idd, want dan ga je 15*4*9 subblokjes controleren ipv 14*4*5.

Anyway, ik ga helemaal niet roteren, ik lees de subblokjes gewoon in een andere volgorde uit afhankelijk van de rotatie als ik ze ga plaatsen in het veld, mbv een startpunt en richtingsvectoren zoals ik hier al liet zien. En om te kijken wat de beste plek is gebruik ik gepreprocesste data

[ Voor 44% gewijzigd door .oisyn op 15-11-2006 15:42 ]

[Dido]

Verwijderd schreef op woensdag 15 november 2006 @ 15:38:
Natuurlijk kun je ook iets schrijven wat zegt van hij staat op 8 - de shift vanwege rotatie en dan vanuit daar gaan positioneren naar kolom 3. Maar dat geeft je dus weer wat meer te doen terwijl dat anders niet nodig is.

Maar hij staat niet op 8 - shift vanwege de rotatie! Hij staat altijd op 8, hoeveel je ook roteert
Of je X naar een ander subblokje verhuist maakt niets uit, voordat je MOVE'd staat die X altijd op pos 8.

Als mijn AI dus zegt dat ie dat ding 1 keer gedraaid op pos 3 wil hebben is het simpelweg ROTATE CW, MOVE LEFT (5x).