Programming Contest Nieuwe Stijl: Contest 1 *uitslagen!*

[DaCoTa]

.oisyn schreef op woensdag 15 november 2006 @ 15:39:
[...]
Idd, want dan ga je 15*4*9 subblokjes controleren ipv 14*4*5.

Nee, ik controlleer 5 integers

[Verwijderd]

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

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

Het eindresultaat is natuurlijk (als het goed is) altijd hetzelfde. Maar je compenseert de shift dus bij het roteren. Het maakt niet uit of je het bij het roteren doet of voor het moven das natuurlijk hetzelfde.

Ik denk dat het ook allemaal niet zoveel uitmaakt, de AI is toch het belangrijkste, de rest is administratie

DaCoTa schreef op woensdag 15 november 2006 @ 15:46:
[...]

Nee, ik controlleer 5 integers

Inderdaad, ik ook

---

Ik vind het wel grappig hoe er nu al discussies zijn over allerlei nutteloze dingen. Dat gaat nog wat worden als we straks bij de AI komen.

Maar aan de andere kant: Daar is de contest toch voor of niet dan?

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

[.oisyn]

DaCoTa schreef op woensdag 15 november 2006 @ 15:46:
[...]

Nee, ik controlleer 5 integers

Dus om te kijken wat de beste plek is voor een blokje doe jij in totaal maar 5 integer checks? Dat vind ik best knap

[Gerco]

Verwijderd schreef op woensdag 15 november 2006 @ 15:47:
Ik vind het wel grappig hoe er nu al discussies zijn over allerlei nutteloze dingen. Dat gaat nog wat worden als we straks bij de AI komen.

Waarschijnlijk is dat omdat de meesten van ons nu met die issues zitten. Weinig zullen er al aan de Ai begonnen zijn en velen (waaronder ikzelf) hebben nog geen regel code geschreven

[DaCoTa]

De discussie over wat en hoe je moet moven is trouwens helemaal niet zo interessant, inderdaad zoals TRRoads zegt, dat is administratie. Volgens mij ligt de interessante discussie op AI gebied bij de bepaling wat een GOEDE zet is, welke zet heeft het beste potentieel om punten te scoren. Daarmee moet je bepalen wat je moet doen en dat is uit de vooraf aangelegde administratie te halen.

.oisyn schreef op woensdag 15 november 2006 @ 15:49:
[...]
Dus om te kijken wat de beste plek is voor een blokje doe jij in totaal maar 5 integer checks? Dat vind ik best knap

Nee, maar ik gok dat je precies weet wat ik bedoel Ik ken jou nivo wel een beetje

[ Voor 30% gewijzigd door DaCoTa op 15-11-2006 15:52 ]

[.oisyn]

DaCoTa: dat zijn ook precies de interessante dingen om voor je te houden, en niet te bediscussieren met de anderen. Dat doe je pas na afloop, als je gewonnen hebt

Nee, maar ik gok dat je precies weet wat ik bedoel Ik ken jou nivo wel een beetje

Maar als je er dan toch maar 5 controleert, waarom dan dat 9x9 grid?

[ Voor 34% gewijzigd door .oisyn op 15-11-2006 15:55 ]

[NMe]

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


Ik denk dat het ook allemaal niet zoveel uitmaakt, de AI is toch het belangrijkste, de rest is administratie

Dan vraag ik me af waarom je je nu zo druk maakt om minimale optimalisatietjes en intussen wel een fundamenteel groter aantal checks wil doen om te kijken waar een blok het beste past.

[Verwijderd]

Inderdaad, administratie is niet zo boeiend. Je gaat er vanuit dat iedereen een administratie kan opzetten waar de nodige gegevens uit te halen zijn.

Ik heb mijn administratie rond, dat werkt goed (ook al gooi ik het misschien straks nog eens helemaal om). Ik vind het nu belangrijker dat het goed werkt ipv dat het perfect werkt.

Maar de AI is echt nog een lastig iets. Ik moet maar eens flink gaan lezen over wat voor strategieen er zijn. Ik zat te denken om kansberekening te gebruiken (dan is het later ook gemakkelijker om vooruit kijken erbij te betrekken?) maar weet niet of dat nou de beste aanpak is.

@NME:
En ik maak me nergens druk om hoor, vind het alleen leuk om erover de discussieren.

.oisyn schreef op woensdag 15 november 2006 @ 15:52:
Maar als je er dan toch maar 5 controleert, waarom dan dat 9x9 grid?

Psst, de blokjes zijn maar 5x5
Dat de grid groter wordt betekent niet dat er ineens meer data in zit.

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

[DaCoTa]

.oisyn schreef op woensdag 15 november 2006 @ 15:52:
DaCoTa: dat zijn ook precies de interessante dingen om voor je te houden, en niet de bediscussieren met de anderen. Dat doe je pas na afloop, als je gewonnen hebt
[...]
Maar als je er dan toch maar 5 controleert, waarom dan dat 9x9 grid?

Eigenlijk zeg ik het verkeerd, het grid is 15 bij de hoogte van het blokje. Ook in het begin werk ik eerlijk gezegd niet met een 9x9 grid, maar met 15x15. Maar dit is alleen bij de initiele administratie, daarna moet de werkversie gemaakt worden, maar zover ben ik nog niet. Maar met 15x15 is het makkelijk visualiseren, kijken of de rotate goed gaat en of de rotatie goed werkt en makkelijk blokjes droppen op het grid.

[.oisyn]

Verwijderd schreef op woensdag 15 november 2006 @ 15:54:
Psst, de blokjes zijn maar 5x5

Exact, dus de geroteerde blokjes passen óók in een 5x5 grid. Waarom je daar dan ineens een 9x9 grid van maakt omdat dat handiger zou zijn wil er bij mij niet in. Hoe is dat handiger, en waarom?

[NMe]

Verwijderd schreef op woensdag 15 november 2006 @ 15:54:
Psst, de blokjes zijn maar 5x5
Dat de grid groter wordt betekent niet dat er ineens meer data in zit.

Maar het betekent wel dat je een groter vlak moet controleren om te kijken óf er data zit.

[Janoz]

seamus21 schreef op woensdag 15 november 2006 @ 14:52:
[...]
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.

Mwah, de regels zijn helder. Jij was degene die nieuwe commandos erbij wilde. Bedenk trouwens dat je het met het draaien erbij extreem veel lastiger maakt. Met enkel droppen moet je maximaal 15x4 mogelijkheden per blokje controleren. ZOu je ook halverwege nog mogen verplaatsen dan moet je max 15x40x4 mogelijke posities controleren en vervolgens ook nog eens kijken of je een pad kunt vinden naar die positie. En dan heb ik het nog maar over 1 blok.

Ik raad je aan om gewoon eerst maar eens te beginnen met de specs die er zijn en pas meer vragen erover te stellen wanneer je daadwerkelijk tegen een probleem aan loopt.

Uitbreidingen doen we, voor deze contest, iig niks aan.

[Verwijderd]

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

Exact, dus de geroteerde blokjes passen óók in een 5x5 grid. Waarom je daar dan ineens een 9x9 grid van maakt omdat dat handiger zou zijn wil er bij mij niet in. Hoe is dat handiger, en waarom?

Ja ik weet ook niet of het handiger is, maar ik weet wel dat ik het handiger vind.

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

Maar het betekent wel dat je een groter vlak moet controleren om te kijken óf er data zit.

Nee, want de gegevens in dat 9x9 vak zijn statisch, je hoeft daar dus helemaal niets meer te controleren. Ook zitten er altijd maar maximaal 25 gevulde blokjes in. Gezien integers in de meeste omgevingen 32 bits breed zijn kun je dus het hele blokje in 1 integer plakken mocht je daar behoefte aan hebben.

Zo bestaat ook het veld maar uit 15 kolommen en hoeft dus in principe nooit meer als 90 bits in beslag te nemen voor de AI.

[ Voor 5% gewijzigd door Verwijderd op 15-11-2006 16:04 ]

[.oisyn]

DaCoTa schreef op woensdag 15 november 2006 @ 15:57:
[...]

Eigenlijk zeg ik het verkeerd, het grid is 15 bij de hoogte van het blokje. Ook in het begin werk ik eerlijk gezegd niet met een 9x9 grid, maar met 15x15. Maar dit is alleen bij de initiele administratie, daarna moet de werkversie gemaakt worden, maar zover ben ik nog niet. Maar met 15x15 is het makkelijk visualiseren, kijken of de rotate goed gaat en of de rotatie goed werkt en makkelijk blokjes droppen op het grid.

Oh ik ging sowieso maar in 1 dimensie kijken, niet in 2 . Mbv heightfields van je veld én je blokjes hoef je op die manier maar [16 - blokje_breedte] plekken te verschuiven (en dus doe je in totaal blokje_breedte * [16 - blokje_breedte] integer checks per orientatie)

[.oisyn]

Verwijderd schreef op woensdag 15 november 2006 @ 16:01:

Ja ik weet ook niet of het handiger is, maar ik weet wel dat ik het handiger vind.

Aha. Ik was confuus omdat je het presenteerde als algemene tips.

[DaCoTa]

.oisyn schreef op woensdag 15 november 2006 @ 16:01:
[...]
Oh ik ging sowieso maar in 1 dimensie kijken, niet in 2 . Mbv heightfields van je veld én je blokjes hoef je op die manier maar [16 - blokje_breedte] plekken te verschuiven (en dus doe je in totaal blokje_breedte * [16 - blokje_breedte] integer checks per orientatie)

Dan kijk jij in de andere dimensie denk ik

[Verwijderd]

.oisyn schreef op woensdag 15 november 2006 @ 16:03:
[...]

Aha. Ik was confuus omdat je het presenteerde als algemene tips.

Is een tip niet per definitie een mening?

[seamus21]

Janoz schreef op woensdag 15 november 2006 @ 15:59:
[...]

Mwah, de regels zijn helder. Jij was degene die nieuwe commandos erbij wilde. Bedenk trouwens dat je het met het draaien erbij extreem veel lastiger maakt. Met enkel droppen moet je maximaal 15x4 mogelijkheden per blokje controleren. ZOu je ook halverwege nog mogen verplaatsen dan moet je max 15x40x4 mogelijke posities controleren en vervolgens ook nog eens kijken of je een pad kunt vinden naar die positie. En dan heb ik het nog maar over 1 blok.

Ik raad je aan om gewoon eerst maar eens te beginnen met de specs die er zijn en pas meer vragen erover te stellen wanneer je daadwerkelijk tegen een probleem aan loopt.

Uitbreidingen doen we, voor deze contest, iig niks aan.

Wat is dit nou weer voor reactie? Als de regels voor mij helder waren dan had ik heus niet die vragen gesteld. Nu zijn voor mij de regels helder. Die nieuwe commando's voorstellen zijn alleen maar om een stapel effect te voorkomen. Nu er hard gezegd is dat het zo bedoeld is dat je alleen maar een DROP hebt vind ik het allemaal best. Ik ben me heust wel bewust van implementatie gevolgen als het een wel of niet mag maar dat was helemaal niet van belang.

[ Voor 8% gewijzigd door seamus21 op 15-11-2006 16:09 ]

[NMe]

Verwijderd schreef op woensdag 15 november 2006 @ 16:01:
Nee, want de gegevens in dat 9x9 vak zijn statisch, je hoeft daar dus helemaal niets meer te controleren. Ook zitten er altijd maar maximaal 25 gevulde blokjes in. Gezien integers in de meeste omgevingen 32 bits breed zijn kun je dus het hele blokje in 1 integer plakken mocht je daar behoefte aan hebben.

Goed, dus je hebt staks een grid van 9x9 waarin "ergens" een blokje van hooguit 5x5 staat. Je wil dan gaan kijken waar dat blokje het beste past; dan moet je toch zeker alle 81 de vakjes checken op data, en dat voor elke rotatie?

[Verwijderd]

-NMe- schreef op woensdag 15 november 2006 @ 16:18:
[...]

Goed, dus je hebt staks een grid van 9x9 waarin "ergens" een blokje van hooguit 5x5 staat. Je wil dan gaan kijken waar dat blokje het beste past; dan moet je toch zeker alle 81 de vakjes checken op data, en dat voor elke rotatie?

Nope, dat hoeft echt niet.

De gegevens in dat 9x9 grid zijn statisch, dat wil dus zeggen dat je van te voren precies weet wat waar staat. Vooraf ga je een blokje inlezen, roteren en genereer je hier statistieken over.

Je AI hoeft dus enkel gebruik te maken van de statistieken van het blokje en hoeft verder helemaal nooit meer iets met het blokje zelf te doen.

Die 9x9 grid is dan later alleen om het blokje in het veld te kopieren, daarbij het is dus handig dat er geen shift hoeft plaatst te vinden tov de X en kun je 1:1 de 9x9 grid in het veld kopieren. Ook hoef je bij dat kopieren geen hits oid te checken, dat heb je van te voren al gedaan op basis van de statistieken van het betreffende blokje.

Het direct kopieren van een 9x9 grid is net iets simpeler te schrijven als een kopie van een 5x5 grid met een shift erin. (Hoewel het eigenlijk niets scheelt) Qua overhead van het kopieren is het minimaal, ik denk zelfs dat als je het in assembly zou doen dat de direct kopie sneller is als de kopie met shift.

Maar feitelijk maakt het dus niet zo gek veel uit. Je kan het in ieder geval gerust in een 9x9 grid zetten.

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

[Janoz]

seamus21 schreef op woensdag 15 november 2006 @ 16:07:
[...]

Wat is dit nou weer voor reactie? Als de regels voor mij helder waren dan had ik heus niet die vragen gesteld. Nu zijn voor mij de regels helder. Die nieuwe commando's voorstellen zijn alleen maar om een stapel effect te voorkomen. Nu er hard gezegd is dat het zo bedoeld is dat je alleen maar een DROP hebt vind ik het allemaal best. Ik ben me heust wel bewust van implementatie gevolgen als het een wel of niet mag maar dat was helemaal niet van belang.

Mijn reactie was vooral op dat er in de omschrijving gewoon staat dat je enkel een DROP hebt. Er is niet ineens nu hard gezegd dat er enkel een DROP commando is, maar dit is altijd al zo geweest.

[.oisyn]

Verwijderd schreef op woensdag 15 november 2006 @ 16:22:
ik denk zelfs dat als je het in assembly zou doen dat de direct kopie sneller is als de kopie met shift.

Kom op, die "shift" (zoiets heet een translatie) doe je maar 1 keer, voordat je gaat kopieren. Of ga jij individuele bits gebruiken (kan, maar is niet echt bepaald sneller, en zo ja, waarom dan 9x9 en niet 9x16)

Maar feitelijk maakt het dus niet zo gek veel uit. Je kan het in ieder geval gerust in een 9x9 grid zetten

Of in een 100x100 grid

[ Voor 14% gewijzigd door .oisyn op 15-11-2006 16:30 ]

[Gerco]

Verwijderd schreef op woensdag 15 november 2006 @ 16:22:
Het direct kopieren van een 9x9 grid is net iets simpeler te schrijven als een kopie van een 5x5 grid met een shift erin.

Waar zie jij een shift dan? je zult op een veldcoördinaat moeten beginnen met het kopiëren en hoeft binnen het grid nooit iets te verplaatsen of verschuiven, zowel bij het 9x9 als bij het 5x5 grid.

[ Voor 17% gewijzigd door Gerco op 15-11-2006 16:30 ]

[Verwijderd]

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

Kom op, die "shift" (zoiets heet een translatie) doe je maar 1 keer, voordat je gaat kopieren. Of ga jij individuele bits gebruiken (kan, maar is niet echt bepaald sneller, en zo ja, waarom dan 9x9 en niet 9x16)


[...]

Of in een 100x100 grid

Precies of in een 100x100 grid.

Waarom noem je het wel grid maar mag de shift geen shift heten?

Of je zegt shift en grid of je zegt translatie en matrix.

Met mijn 9x9 grid hoef ik geen shift te gebruiken en dat scheelt mij dus in ieder geval denkwerk.

Wat jij doet maakt mij niet zoveel uit, maar dat jij het anders doet wil niet zeggen dat wat ik doe minder goed zou zijn...

[RobIII]

Goed; kunnen we weer een beetje terug naar de bedoeling van dit topic? Zolang je app straks voldoet aan de specs moet iedereen lekker zelf weten hoe 'ie het doet

[Dido]

Verwijderd schreef op woensdag 15 november 2006 @ 16:22:
Het direct kopieren van een 9x9 grid is net iets simpeler te schrijven als een kopie van een 5x5 grid met een shift erin.

Vast, maar er is nergens zo'n shift voor nodig in die 5x5.
Als ik van te voren voor alle vier rotaties een 5x5 blokje definieer met een X erin, dan hoef ik nevernooitniemeer iets te shiften. En ik heb nevernooitgeen 9x9 grid nodig.
Het enige dat m'n AI zegt is dattie de X op positie a wil, en dattie versie 1, 2, 3 of 4 van het blok wil. Dat hoef ik alleen maar te vertalen naar een paar MOVES en ROTATES zonder rekening te houden met shifts als gevolg van rotatie.

Het staat je natuurlijk vrij om het wel te gebruiken, maar het idee dat het makkelijker of sneller is leeft vooral aan jouw kant van deze verbinding

[Verwijderd]

@Dido:
Je zal toch bij die vertaalslag die positie van de X moeten corrigeren (die duidelijk na rotatie op een andere plek staat binnen de 5x5 grid). Daar zit dus de shift ook al weet je het zo te praten dat je em niet noemt.

@RobIII:
Domme vraag: Wat is precies de bedoeling van dit topic?

Ik weet dat het niet de bedoeling is dat er code gepost wordt, maar er mag dus ook niet over de administratie gepraat worden?

Enkel vragen over de regels (maar die lijken me 100% duidelijk) en discussies over de AI?

[ Voor 30% gewijzigd door Verwijderd op 15-11-2006 16:37 ]

[M-ThijZ]

Ik moet zeggen dat ik het best wel lastig vind om een goed begin te maken wat betreft het speelveld. Ik denk dat ik eerst maar een parser maak, met een simpele GUI zodat ik goed kan controleren of die zijn werk goed doet en dit daarna uitbreiden zodat ik de parser zelf geen sequence met commando's hoef te voeren maar dit zelf uitgekiend kan worden.
Ik neem aan dat ik de blokken en het speelveld kan vertalen naar arrays welke ik kan vullen, alleen wil ik niet meteen te diep in de implementatie duiken voordat ik een duidelijk beeld heb van waar ik nu eigenlijk over praat.

[RobIII]

Verwijderd schreef op woensdag 15 november 2006 @ 16:36:

@RobIII:
Domme vraag: Wat is precies de bedoeling van dit topic?

Ik weet dat het niet de bedoeling is dat er code gepost wordt, maar er mag dus ook niet over de administratie gepraat worden?

Enkel vragen over de regels (maar die lijken me 100% duidelijk) en discussies over de AI?

Nee, er mag best gepraat worden over ditjes en datjes (tuurlijk, zo flauw zijn we ook weer niet ) maar er werd nu zo lang gezaagd over rotaties en translaties terwijl dat eig'k nog maar 't minste is van het werk en dat er zo te zien toch niet tot elkander werd gekomen

[Dido]

Verwijderd schreef op woensdag 15 november 2006 @ 16:36:
@Dido:
Je zal toch bij die vertaalslag die positie van de X moeten corrigeren (die duidelijk na rotatie op een andere plek staat binnen de 5x5 grid). Daar zit dus de shift ook al weet je het zo te praten dat je em niet noemt.

Eenmalig, helemaal aan het begin, ja. En zelfs dan niet, aangezien mijn X "gewoon" meeroteert. Daarna mag ik hem helemaal vergeten.

Maar goed, het blijft natuurlijk inderdaad een detail vergeleken met het echte werk: wat is de beste move?

[DaCoTa]

Dido schreef op woensdag 15 november 2006 @ 16:42:
[...]
Maar goed, het blijft natuurlijk inderdaad een detail vergeleken met het echte werk: wat is de beste move?

Hoewel representatie ook nog wel meetelt later. Als je dat goed (of slecht) kiest, kan het zijn dat je een veel grotere of veel kleinere zoekruimte krijgt, afhankelijk van slimmigheden en zuinigheid van je representaties. Vooral geheugengebruik lijkt me - met per iteratie 50 mogelijkheden - iets om zuinig mee te zijn. Vijf stappen vooruit rekenen is maximaal al ruim 300 miljoen mogelijkheden. Als je representatie dan teveel geheugen vreet, is het afgelopen.

Dit staat nog los van de cpu cycles om die 300 miljoen mogelijkheden te genereren trouwens

[ Voor 6% gewijzigd door DaCoTa op 15-11-2006 16:49 ]

[Verwijderd]

Ik zou eerst eens beginnen bij het bepalen van 1 plaatsing voordat je begint aan het vooruit kijken?

En geheugen gebruik is nou ook weer niet iets om je zo druk over te maken. Het zal een goede PC zijn toch?

[ Voor 35% gewijzigd door Verwijderd op 15-11-2006 16:50 ]

[NMe]

Ga maar uit van minimaal 1GB RAM.

[Gerco]

@-NMe-:
Mogen we de harddisk gebruiken (voor het opslaan van de zoekruimte)? 1GB is niet zoveel als je meer dan een paar zetten vooruit wilt rekenen. En als het in Java draait, mogen we dan parameters vaststellen om aan de JVM mee te geven (met name -Xmx, aangezien die default nogal laag staat)?

[.oisyn]

Verwijderd schreef op woensdag 15 november 2006 @ 16:32:
Of je zegt shift en grid of je zegt translatie en matrix.

Euh... whatever

Dido schreef op woensdag 15 november 2006 @ 16:35:
Het staat je natuurlijk vrij om het wel te gebruiken, maar het idee dat het makkelijker of sneller is leeft vooral aan jouw kant van deze verbinding

Juistem!

[ Voor 43% gewijzigd door .oisyn op 15-11-2006 17:13 ]

[Verwijderd]

Om het maar eens en voor altijd af te sluiten:

Iedereen doet wat ie zelf wil met de rotatie, er zijn zoveel oplossingen die allemaal goed of minder goed zijn afhankelijk van wat je zelf wil.

Als je maar in gedachte houdt dat de X altijd op kolom 8 staat voor de eerste beweging opdracht, het maakt dan niet uit wat de rotatie is, de X blijft op kolom 8.

Dan lijkt me dat we dat onderhand wel gehad hebben en dan houden we erover op.

Dat jullie denken dat mijn aanpak minder goed is niet mijn probleem.

(En het kan geen kwaad om het ook eens van een andere kant te bekijken ipv altijd maar ervan overtuigd zijn dat je het zelf bij het rechte eind hebt. En dan praat ik niet over iemand specifiek maar meer de algemene sfeer hier in het topic (en dus ook over mijzelf!). Dat is kritiek die hier wel eens vaker voorbij komt...)

[ Voor 24% gewijzigd door Verwijderd op 15-11-2006 17:20 ]

[frickY]

In hoeverre is het overignes de bedoeling AI te gebruiken om de beste positie te vinden?
Bruteforce proberen tot je een goede match hebt is ook gewoon toegestaan neem ik aan?

[DaCoTa]

frickY schreef op woensdag 15 november 2006 @ 17:19:
In hoeverre is het overignes de bedoeling AI te gebruiken om de beste positie te vinden?
Bruteforce proberen tot je een goede match hebt is ook gewoon toegestaan neem ik aan?

Dat mag je gewoon AI noemen, want dat is al AI. Geen echt slimme AI, maar het is er wel een

[MetroidPrime]

frickY schreef op woensdag 15 november 2006 @ 17:19:
In hoeverre is het overignes de bedoeling AI te gebruiken om de beste positie te vinden?
Bruteforce proberen tot je een goede match hebt is ook gewoon toegestaan neem ik aan?

Wat jij brute-forcen noemt is juist een vorm van AI. Je gaat gewoon de zoekboom langs en probeert alle mogelijkheden tot je de beste vind. Het enige probleem is dat je misschien niet genoeg tijd hebt om de volledige zoekboom te doorzoeken.

Als het testen op een dual-core machine gedaan zal worden, komen er dan aparte categorieën voor single- en multi-threaded oplossingen?

[Creepy]

Gerco schreef op woensdag 15 november 2006 @ 17:05:
@-NMe-:
Mogen we de harddisk gebruiken (voor het opslaan van de zoekruimte)? 1GB is niet zoveel als je meer dan een paar zetten vooruit wilt rekenen.

??

Zoveel hoef je nu ook weer niet bij te houden hoor. 1 array van 40 bij 15. Laten we het ruim nemen en per blokje 1 integer bij houden, en dat stellen we op 4 bytes. Dat is dus 40x15x4 = 2400 bytes. 1 GB = 1024 MB = 1048576 KB = 1073741824 Bytes
1073741824 / 2400 = 447.392 volledige situaties die je kan bijhouden. En als je 100K aan blokjes volledig gaat zitten bruteforcen, tuurlijk, dan kan je daar overheen komen. Maar dan ga waarschijnlijk ook wel over de twee uur heen en is je algoritme verre van optimaal

Staar met z'n allen nu eens niet blink op die twee uur en het geheugen gebruiken en ga gewoon eens aan de slag. Je merkt op je eigen systeem ook wel of het te lang duurt of dat het teveel geheugen vreet.

Je brengt me meteen wel op een idee: Het is dus niet toegestaan om files weg te schrijven anders dan output.txt

En als het in Java draait, mogen we dan parameters vaststellen om aan de JVM mee te geven (met name -Xmx, aangezien die default nogal laag staat)?

Tuurlijk.

Wat voor soort AI je implementeert moet je overigens zelf weten. Dat is nu juist de competitie

[ Voor 19% gewijzigd door Creepy op 15-11-2006 17:36 ]

[Gerco]

MetroidPrime schreef op woensdag 15 november 2006 @ 17:26:
Het enige probleem is dat je misschien niet genoeg tijd hebt om de volledige zoekboom te doorzoeken.

Worst case heb je 60^g (waarbij g het aantal entries in game.txt is) mogelijkheden om door te rekenen. Als g in de orde van 100000 ligt (wat het kan liggen), ben ik er zeker van dat je niet alle 60¹⁰⁰⁰⁰⁰ mogelijkheden gaat kunnen doorrekenen.

Het is natuurlijk anders, want niet elk blokje kan op 60 verschillende manieren in het speelveld en g is misschien wel kleiner (of groter), maar helemaal brute-force doorrekenen kun je iig wel vergeten.

De I in je AI komt van het elimineren van zoveel mogelijk van je zoekboom, zonder je eindscore kleiner te maken. Dit is bewezen onmogelijk, een optimale oplossing is niet te vinden zonder brute force (zoek maar op "Tetris NP hard"), dus het is zaak je AI zo slim mogelijk te laten elimineren, wetend dat het niet bewezen optimaal kan zijn.

Creepy schreef op woensdag 15 november 2006 @ 17:30:
1073741824 / 2400 = 447.392 volledige situaties die je kan bijhouden.

Dat valt nog aardig tegen... aangezien 60^3 (216.000) < 447.392 < 60^4 (12.960.000) is het dus maar mogelijk om 3 complete zetten vooruit te rekenen in 1GB (worst case). Het zal natuurlijk wel niet worst-case zijn, maar meer dan 3 zetten volledig doorrekenen gaat al niet lukken.

[ Voor 18% gewijzigd door Gerco op 15-11-2006 17:37 ]

[Genoil]

Nou ik ga ook een poging doen en totdat ik naar PHP-CLI (+ php_sdl) verhuis kun je lekker meekijken op http://www.meneer.net/gotcontest/index.php .

[eamelink]

Mjah, om een zettensequence vooruit te rekenen hoef je in principe natuurlijk niets meer te onthouden dan alleen die zettensequence en een 'score' die je aan het eindresultaat hangt. Je hoeft dus niet de hele veldconfiguratie per vooruitgerekend veld op te slaan.

[Creepy]

Dat is dus meteen duidelijk: niet dom gaan zitten bruteforcen. Je vreet dan teveel geheugen en je haalt dat niet qua tijd

[Verwijderd]

http://www.imagehost.nl/view.php?file=images/nhk09933.gif

(Werkt prolly niet... moet je ff linkje hierboven klikken, gratis hosting he?)

Wellicht een handig plaatje om aan te geven hoe het rotatiepunt werkt?

En daarbij dus ook te zetten dat voordat er bewogen is het rode vakje altijd kolom 8 is (bij iedere rotatie dus)

[ Voor 24% gewijzigd door Verwijderd op 15-11-2006 18:16 ]

[PiepPiep]

DaCoTa schreef op woensdag 15 november 2006 @ 16:48:
[...]Vooral geheugengebruik lijkt me - met per iteratie 50 mogelijkheden - iets om zuinig mee te zijn. Vijf stappen vooruit rekenen is maximaal al ruim 300 miljoen mogelijkheden. Als je representatie dan teveel geheugen vreet, is het afgelopen.

Dit staat nog los van de cpu cycles om die 300 miljoen mogelijkheden te genereren trouwens

Kleine tip, zoek eens op breath-first vs depth-first

[DaCoTa]

PiepPiep schreef op woensdag 15 november 2006 @ 18:06:
[...]

Kleine tip, zoek eens op breath-first vs depth-first

[bragmode] Ik heb - welliswaar een paar jaar geleden, maargoed - een studie AI achter de rug, dus dat zit wel goed [/bragmode]

Nu ik er langer over nadenk komt het weer terug. Juist bij breadth first is geheugen een issue, omdat je van alle iteraties alle states in memory moet houden. Bij depth first heb je in principe alleen het aantal iteraties in het geheugen, en de tot dan toe beste mogelijkheid.

[ Voor 29% gewijzigd door DaCoTa op 15-11-2006 18:38 ]

[Bint]

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

[bragmode] Ik heb - welliswaar een paar jaar geleden, maargoed - een studie AI achter de rug, dus dat zit wel goed [/bragmode]

giev AI studie!

offtopic:
-effe serieus-
Was dat een interessante studie? ik vind AI alsmaar interessanter worden, en ik wil kijken of het mogelijk is om ergens mijn master daarin te halen.

[Verwijderd]

Inderdaad, daar zit ik ook al een tijdje naar te kijken.

Ben nu al zo lang van school af dat ik eigenlijk heel graag weer terug wil

Ik weet dat ze in Utrecht een goede opleiding hebben van technische AI, maar om nou een paar avonden in de week helemaal naar Utrecht te gaan vind ik ook weer zoiets (alsof ik niet genoeg in de auto zit).

Dat cognitieve kunstmatige intelligentie spreekt me niet echt aan hoewel het me ook niet geheel duidelijk is wat ze ermee bedoelen, maar technische kunstmatige intelligentie trekt me toch iets meer.

[DaCoTa]

offtopic:
Ik heb van 1996 tot 2002 aan de UvA AI gedaan, specialisatie Autonome Robotica. In 1996 bestonden er alleen in Amsterdam en in Utrecht volledige studies AI, waarbij het in Utrecht de titel Cognitieve Kunstmatige Intelligentie had, Amsterdam was een meer technische studie, als onderdeel van de Wiskunde, Informatica, Natuurkunde en Scheikunde faculteit. De studie vond ik zeker heel erg interessante studie, vooral omdat het vakgebied heel erg breed is. Naast informatica, komt ook natuurkunde, psychologie, filosofie, nederlands (taalkunde) en logica aan bod.

[DroogKloot]

offtopic:
AI aan de UU (Utrecht) en UN (Nijmegen) is cognitief georienteerd (meer alpha en gamma, minder beta), en de opleidingen van de VU (Amsterdam) en UM (Maastricht) richten zich vnl. op kennistechnologie. Wil je meer met de technische kant van AI doen, zou ik voor de UvA (Amsterdam) of de RUG (Groningen) kiezen.

[ Voor 3% gewijzigd door DroogKloot op 15-11-2006 19:02 ]

[Verwijderd]

offtopic:
Overigens waardeloos dat de TU/e geen AI opleiding heeft, ik heb mijn studie daar afgerond en zou daar dus ook graag weer naar terug gaan

[Verwijderd]

offtopic:
Ik studeer zelf AI aan de RuG in Groningen en ik kan je verzekeren dat het erg goed georganiseerd is, en je niet alleen theorie krijgt maar ook practische dingen. Erg interessante studie inderdaad.

Je moet wel erg wiskundig zijn, maar als je een beetje beta bent dan maakt het niet meer uit. Het is in ieder geval heel goed voor je analytisch vermogen, en je kunt zeer goed beredeneren!

[frickY]

Creepy schreef op woensdag 15 november 2006 @ 17:30:
Je brengt me meteen wel op een idee: Het is dus niet toegestaan om files weg te schrijven anders dan output.txt

Hmm.. zonder soort van worker file wordt het erg lastig multithreaden vanuit PHP. Ik wou eigenlijk per blokje een x aantal zetten door een x aantal threads laten doorrekenen, welke een score in een bestandje zouden opslaan om deze vanuit de initiele thread weer uit te lezen. Andere manier van communiceren tussen je threads heb je, voor zover ik weet, niet.
Valt dit te herzien?

offtopic:
Studie AI lijkt mij ook nog wel wat. Met name zelf lerende applicaties. Ooit misschien nog eens aanbeginnen. Lijkt me dat he tin ieder geval toekomst heeft

[ Voor 22% gewijzigd door frickY op 15-11-2006 19:23 ]

[Gerco]

frickY schreef op woensdag 15 november 2006 @ 19:22:
Valt dit te herzien?

Gebruik je toch een database? Dan schrijf je (zelf) geen files iig

[Bint]

Ben begonnen, maar zit nu al te twijfelen hoe ik de shapes ga opslaan..

misschien moet ik toch maar eens beter gaan nadenken. Gewoon een stringcollection gebruiken, of toch een matrix. Ach ja, er is nog tijd zat

[Javache]

frickY schreef op woensdag 15 november 2006 @ 19:22:
[...]

Hmm.. zonder soort van worker file wordt het erg lastig multithreaden vanuit PHP. Ik wou eigenlijk per blokje een x aantal zetten door een x aantal threads laten doorrekenen, welke een score in een bestandje zouden opslaan om deze vanuit de initiele thread weer uit te lezen. Andere manier van communiceren tussen je threads heb je, voor zover ik weet, niet.
Valt dit te herzien?

offtopic:
Studie AI lijkt mij ook nog wel wat. Met name zelf lerende applicaties. Ooit misschien nog eens aanbeginnen. Lijkt me dat he tin ieder geval toekomst heeft

Misschien kan je hiervoor PHP Sessions gebruiken...

[Gerco]

Javache schreef op woensdag 15 november 2006 @ 19:44:
Misschien kan je hiervoor PHP Sessions gebruiken...

Het lijkt me dat een PHP inzending zou moeten werken vanaf de commandline. Daar heb je geen sessions (en ook geen mogelijkheden voor "multithreading").

[Creepy]

Voor alle ingeleverde programma's en scripts geld dat ze in principe standalone (al dan via een interpreter) moeten werken. Dus PHP draait niet onder apache maar via php-cli, maar dat leek me eigenlijk niet meer dan logisch.

[ Voor 25% gewijzigd door Creepy op 15-11-2006 20:11 ]

[Verwijderd]

Sowieso neem ik aan dat je PHP solution net zo goed uit meerdere files mag bestaan zoals iedere andere oplossing. (ook al suggesteert de TS iets anders)

Het is in principe wel mogelijk alles in 1 file te proppen, maar das niet zo overzichtelijk tijdens het proggen enzo.

En het hoeft toch ook niet per se vanaf de commandline te draaien? Dat zou een hoop andere solutions in bijvoorbeeld IIS ook onmogelijk maken.

Het is redelijk standaard om PHP niet commandline te draaien, dat iets kan betekent niet dat je het ook moet doen

Waarom zou het logisch zijn PHP te draaien via commandline terwijl het veel vaker via apache gedaan wordt? (is ook makkelijker te testen, gewoon even uploaden en aan de gang)

[ Voor 16% gewijzigd door Verwijderd op 15-11-2006 20:13 ]

[Creepy]

Verwijderd schreef op woensdag 15 november 2006 @ 20:10:
Sowieso neem ik aan dat je PHP solution net zo goed uit meerdere files mag bestaan zoals iedere andere oplossing. (ook al suggesteert de TS iets anders)

Geen probleem

Het is in principe wel mogelijk alles in 1 file te proppen, maar das niet zo overzichtelijk tijdens het proggen enzo.

En het hoeft toch ook niet per se vanaf de commandline te draaien? Dat zou een hoop andere solutions in bijvoorbeeld IIS ook onmogelijk maken.

Jawel. Ik heb bijv. geen IIS geinstalleerd. Alle entries moeten direct uit te voeren zijn. Interpreters e.d. zijn geen probleem. Complete webomgeving en andere zaken wel. We gaan echt niet voor elke entry controlen waar we dat moeten installeren en welke URL we moeten aanroepen.

Het is redelijk standaard om PHP niet commandline te draaien, dat iets kan betekent niet dat je het ook moet doen

PHP moet via de commandline interface van PHP. Perl moet via de perl interpreter etc.etc.

[ Voor 9% gewijzigd door Creepy op 15-11-2006 20:16 ]

[Verwijderd]

Aha, je mag dus iedere programmeertaal gebruiken, zo lang het maar niet webbased is dus als client uit te voeren.

Das handig om dat even in de TS te zetten dan, voor iedereen die al druk aan de gang was in een IIS omgeving.

Enne:

Verwijderd schreef op woensdag 15 november 2006 @ 18:00:
http://www.imagehost.nl/view.php?file=images/nhk09933.gif

[afbeelding] (Werkt prolly niet... moet je ff linkje hierboven klikken, gratis hosting he?)

Wellicht een handig plaatje om aan te geven hoe het rotatiepunt werkt?

En daarbij dus ook te zetten dat voordat er bewogen is het rode vakje altijd kolom 8 is (bij iedere rotatie dus)

Geen goed idee om die toe te voegen? Plaatjes helpen altijd toch?

[Creepy]

Even serieus: jij bent onder IIS begonnen? En de taal die je hebt gekozen heeft geen mogelijkheid tot compilatie of is niet uit te voeren via een interpreter?

Dit soort zaken lijken mij eerlijk gezegd niet meer dan logisch. Een installatie handleiding voor een entry in een contest zijn dan op deze manier ook niet nodig. Straks kan ik nog Java webservlets onder Tomcat gaan zitten installeren.....

[ Voor 101% gewijzigd door Creepy op 15-11-2006 20:21 ]

[Verwijderd]

Nee zeker niet, ik heb het gedaan onder PHP via Apache gewoon maar het moet geen punt zijn daar CLI van te maken (heb geen rare fratsen gebruikt).

En zit erover te denken het later nog om te schrijven naar een C variant.

Maar je weet niet, er zijn genoeg mensen die IIS omgevingen gebruiken dus wellicht dat iemand het gepakt heeft. Je pakt de omgeving die je gewend bent toch?

[Creepy]

Dan zijn ze vaak in VB via ASP bezig. VB of VBscript is ook prima standalone of via een interpreter uit te voeren dus dat lijkt me echt geen probleem.

[Verwijderd]

IIS is bruikbaar voor heel erg veel talen.

Beetje naief om te denken dat het altijd maar VB of VBScript is.

Maar wordt de startpost wel duidelijker gemaakt mbt wat voor soort talen je wel en niet mag gebruiken? En op wat voor manier dat het dan gebruikt moet worden.

De gebruikte PHP versie zou ook handig zijn, maar ik neem aan dat zowel versie 4 als 5 beschikbaar zijn. (Gebruikt er nog iemand PHP3? )

[Creepy]

Ow kom op zeg. Beetje common sense hoor. Het moet in principe direct uit te voeren zijn.

php4 en php5 zullen geen probleem zijn.

En noem mij eens 1 taal waarmee je onder IIS kan ontwikkelen waarvoor geen mogelijkheid tot compileren of niet uit te voeren via een interpreter is. Deze kop ik alvast voor je in: Javascript voer je clientside uit en niet onder IIS

[frickY]

Het was mij in ieder geval duidelijk dat je in het geval van PHP commandline werkt
Vandaar mijn vraag of het niet mogen wegschrijven van bestanden herzien kan worden, omdat je anders geen mogelijkheid hebt tussen 2 instanties te communiceren.

PHP zal al wel niet de snelste oplossing zijn, en het niet gebruik kunnen maken van meerdere threads zal daar ook niet echt bij helpen. Een ramdrive maken in het 1GB geheugen welke je wél tot je beschikking hebt is zeker niet de bedoeling?


@Hieronder.
Omdat we het hier niet over een webbased applicatie hebben, maar PHP als oplossing kan worden gebruikt om een clientside 'probleem' op te lossen, en het mijns inziens daarom logisch is deze ook lokaal te draaien? Ervaring met PHP command line draaien lijkt me ook niet helemaal nodig om PHP te kunnen downloaden, de binary in C:\ te zetten met het bijbehorende DDLetje en "C:\php.exe -f je_file.php" aan te roepen. Je moet alleen opletten dat je geen functonaliteiten gaat gebruiken waarvoor Apache de ondersteuning levert, want die heb je niet.

[ Voor 69% gewijzigd door frickY op 15-11-2006 20:34 ]

[Verwijderd]

@Creepy:

Wat is dat nou weer voor houding??

Common sense om PHP te draaien in CLI terwijl het duizenden keren vaker niet als CLI wordt gebruikt. Daarnaast heeft echt niet iedereen zomaar toegang tot een PHP CLI omgeving of daar ervaring mee.

En kom dan niet met zo'n domme javascript opmerking, dat is helemaal nergens voor nodig en heeft er ook helemaal niets mee te maken...

Voor een hoop mensen staat PHP gelijk aan webbased, je noemt PHP in de TS maar geeft niet aan dat het clientside moet zijn.

Je kunt ongeveer iedere taal in IIS douwen, het was maar een voorbeeld.

AFAIK is er geen (fatsoenlijke) client side versie van ColdFusion, ook een veel gebruikte omgeving...

@frickY:

Je hebt gelijk dat PHP waarschijnlijk niet de beste oplossing is.

Maar een beetje duidelijkheid in de regels mag wel.

Het gaat om het oplossen van een bepaald probleem via programmatuur, dit kan natuurlijk net zo goed webbased als lokaal gedaan worden.

Er wordt tegenwoordig steeds meer en meer webbased gedaan, als je dan zo'n belachelijke reactie krijgt dan wordt je daar niet zo lekker van.

Dat het client based moet zijn: Prima, dat hoeft ook geen probleem te zijn. Maar geef het dan gewoon netjes aan en niet als iemand erom vraagt diegene belachelijk proberen te maken door met common sense en javascript aan te komen.

[ Voor 46% gewijzigd door Verwijderd op 15-11-2006 20:37 ]

[Creepy]

Verwijderd schreef op woensdag 15 november 2006 @ 20:30:
Wat is dat nou weer voor houding??

Heel simpel. Als we PHP via Apache toe staan, dan mogen Java servlets ook, RoR apps ook geen probleem etc. Dan zijn we straks meer tijd kwijt aan installeren van de entries.

Common sense om PHP te draaien in CLI terwijl het duizenden keren vaker niet als CLI wordt gebruikt. Daarnaast heeft echt niet iedereen zomaar toegang tot een PHP CLI omgeving of daar ervaring mee.

Dan leer je daar maar mee omgaan. Het verschil voor PHP is in dit geval echt nihil en vrij simpel te installeren.

En kom dan niet met zo'n domme javascript opmerking, dat is helemaal nergens voor nodig en heeft er ook helemaal niets mee te maken...

Smiley.. humor.. but hey..m'n vraag over een taal en IIS is overigens wel serieus.

Voor een hoop mensen staat PHP gelijk aan webbased, je noemt PHP in de TS maar geeft niet aan dat het clientside moet zijn.

Nogmaals: dat leek me common sense, en daar ben ik blijkbaar niet de enige in.

[DaCoTa]

Voor een client applicatie is het gewoon niet zinnig om het webbased te maken. Als de enige taal die je kent alleen voor webbased development gebruikt kan worden zonder CLI mogelijkheid, tja, tijd zat om een nieuwe taal te leren toch?

[Verwijderd]

Ik zeg toch ook niet dat het een probleem is dat het niet webbased mag zijn.

En ik zeg toch ook helemaal niet dat er geen goede redenen voor zijn om het client side te houden?

Het enige waar ik om vraag is om duidelijkheid in de regels, dat mag dan ook gerust gegeven worden.

Dat in jullie belevingswereld het 'normaal' is dat alles client side is, de trend is om steeds meer webbased te doen. Voor veel mensen (ik heb al een voorbeeld in het topic voorbij zien komen, en zelf was ik ook onder Apache begonnen) is het eerder vanzelfsprekend het webbased te doen.

Mijn punt van eerder is wederom geldig:

Bekijk het ook eens van een andere kant ipv heilig overtuigd te zijn van je eigen standpunt.

[RobIII]

Verwijderd schreef op woensdag 15 november 2006 @ 20:30:
@Creepy:

Wat is dat nou weer voor houding??

Moet die smiley nou? Was dat nou echt nodig?

Ik heb het al eerder gezegd, maar laat ik het eens omdraaien: Nou stel dat jij straks al die entries moet gaan runnen. Zie jij het zitten om dan voor iedere entry een complete manual door te worstelen met allerlei vage zut waar je zelf nooit iets mee doet en om dat (goed) aan de praat te krijgen? Of wil je (bij wijze van) een .exe runnen en wachten tot 't ding klaar is?

Wij zijn ook maar gewone stervelingen en hebben naast onze baan, kinderen, sociale contacten, beunklussen en dan ook nog hier modderen al meer dan voldoende aan ons hoofd. Het idee achter de contest is duidelijk, waar het om draait ook: gezellig met z'n allen een leuke competitie houden.

Ik zit niet te wachten op lui die die stemming komen bederven of tussen alle regeltjes door toch telkens op zoek zijn naar mazen in het net of allerlei ge-"maar maar maar..."
In principe valt alles te bediscussieëren in dit topic en staat vragen vrij maar als we "jullie" steeds aan het handje moeten houden is er voor mij de lol snel van af. Als mijn werknemers zo zouden reageren en zoveel "aanzet" nodig zouden hebben om op gang te komen zou ik ze adviseren om eens ergens anders te gaan kijken. We verwachten (zoals altijd) wat zelfstandigheid en common sense in PRG en hebben (gelukkig nog steeds) het volste vertrouwen in jullie om deze contest tot een leuk en gezellig einde te brengen. Maar laten we ons dan eens wat meer gaan richten op de daadwerkelijke implementaties dan op allerlei exotische "what-ifs" die toch niet van toepassing zijn. Als ze aan de orde komen hebben we het er wel over, maar ik heb nog niemand gehoord over stand-alone-coldfusion op een sparc cluster met anderhalve cpu core.

[Verwijderd]

Het enige wat ik vraag is dat in de TS wordt opgenomen dat de aangeleverde programmatuur clientside moet zijn.

Ikzelf was in Apache begonnen en ik heb een ander gezien in dit topic die dat ook heeft gedaan. Zo zijn er vast nog wel meer mensen die webbased begonnen waren.

Maar in plaats van dat er gezegd wordt: "Tuurlijk ik pas even de TS aan, dan is het nog extra duidelijk. Wij dachten dat het niet nodig zou zijn, maar het kan geen kwaad het toe te voegen" krijgen we weer een hele lading posts vol met onzin.

Waarom? Alleen omdat ik (half al geintje, half serieus) als voorbeeld gaf dat iemand in IIS al was begonnen.

Is dat nou echt nodig?

En nergens heb ik er een probleem van gemaakt, sterker nog ik heb gezegd dat het voor mij helemaal geen enkel probleem is en ik waarschijnlijk toch nog de boel ging herschrijven in een C variant.

Ik begrijp het prima dat het gewoon makkelijk te draaien moet zijn, dat is ook al eens eerder gezegd in het topic. De regels maken mij ook echt helemaal niets uit, maar toch op z'n minst wel dat de regels duidelijk gemaakt worden, ipv dat het maar impliciet volgens 'common sense' (wat ik dus blijkbaar niet heb) gelezen moet worden.

[ Voor 29% gewijzigd door Verwijderd op 15-11-2006 20:53 ]

[Verwijderd]

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

wat is de reden hier van?

[learn_more]

RobIII schreef op woensdag 15 november 2006 @ 20:45:
stand-alone-coldfusion op een sparc cluster met anderhalve cpu core.

goed idee!


maar ff een serieuzere vraag:
sommige compilers/interpreters (borland c++, msvc++, vb, labview) gebruiken runtime dlls,
miss handig om aan te geven welke beschikbaar zijn?

of is het gewoon een verse windows install, met de standaard spullen erop

[Verwijderd]

@rvanleeuw. :

Om het wat moeilijker te maken lijkt me.

Als die wel naar beneden zouden vallen zouden er snel meer lijnen gevuld worden wat het geheel iets (maar niet veel) eenvoudiger maakt.

[ Voor 4% gewijzigd door Verwijderd op 15-11-2006 20:56 ]

[DaCoTa]

Verwijderd schreef op woensdag 15 november 2006 @ 20:40:
Dat in jullie belevingswereld het 'normaal' is dat alles client side is, de trend is om steeds meer webbased te doen.

Mijn werk bestaat uit webbased development. Maar dit is geen web-applicatie. Er is geen browser, geen user, niks, alleen file input en file output. De enige input van de gebruiker is de start van het programma. Dat is zo ongeveer de meest standaard console bewerking die er nodig is.* Ergo, dit is niet iets om in een webbased omgeving op te lossen. Net zomin je een webshop niet in commandline omgeving gaat maken.

*) Behalve als je een testversie maakt waarbij je als gebruiker het proces nog wilt sturen of monitoren. Maar ook dan zal de kern van de applicatie een console applicatie zijn.

[ Voor 12% gewijzigd door DaCoTa op 15-11-2006 21:00 ]

[Verwijderd]

Laten we er niet verder op discussieren, het is me duidelijk dat je hier amper een opmerking kunt maken zonder een lading zooi over je heen te krijgen.

[RobIII]

Verwijderd schreef op woensdag 15 november 2006 @ 21:04:
Laten we er niet verder op discussieren, het is me duidelijk dat je hier amper een opmerking kunt maken zonder een lading zooi over je heen te krijgen.

Onzin.

Maar goed; dan stel ik het zo: Mochten er een paar exotische entries tussen zitten dan zullen we ons best doen om die alsnog draaiend te krijgen. Dan doen wij wel wat meer moeite en kunnen jullie eindelijk eens overgaan op iets productiefs

We zijn helemaal de lulligste niet en zullen er zowieso alles aan doen om zoveel mogelijk entries te kunnen beoordelen. Mocht dat écht een onmogelijke opgave blijken om wat voor reden dan ook dan zullen we tegen die tijd beoordelen hoe we dat oplossen; We zouden je natuurlijk gewoon de "contest set" kunnen toesturen zodat je je app lekker zelf draait; maar dan wel binnen 2 uur mail terug met de output of iets van die strekking. Het enige dat we zeggen of wat we verzoeken (en welke richting we jullie een beetje in proberen te 'duwen') is dat het niet al te exotisch is als het niet hoeft; dat scheelt voor ons werk en voor iedereen een hoop frustratie als straks de contest gespeeld gaat worden. Niemand zit er op te wachten om 84 mailtjes op-en-neer te moeten gaan sturen om je app aan de praat te krijgen.

We zijn juist niet al te duidelijk in deze dingen omdat we je in principe niets of zo weinig mogelijk willen opleggen.

[ Voor 20% gewijzigd door RobIII op 15-11-2006 21:12 ]

[DaCoTa]

Op een wat vrolijker noot Mijn rotatie van een 15x15 matrix werkt

[RobIII]

DaCoTa schreef op woensdag 15 november 2006 @ 21:11:
Op een wat vrolijker noot Mijn rotatie van een 15x15 matrix werkt

Ik heb al een V2.0 van de validator met daarin (als piepklein onderdeeltje) o.a rotatie klaarliggen

[Verwijderd]

RobIII schreef op woensdag 15 november 2006 @ 21:09:
[...]
Maar goed; dan stel ik het zo: Mochten er een paar exotische entries tussen zitten dan zullen we ons best doen om die alsnog draaiend te krijgen. Dan doen wij wel wat meer moeite en kunnen jullie eindelijk eens overgaan op iets productiefs

Prima.

Bedankt dat er nog iemand is in het rood die wel weet hoe hij antwoord moet geven

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

Ik heb al een V2.0 van de validator met daarin (als piepklein onderdeeltje) o.a rotatie klaarliggen

Toch wel cache rotatie in een 9x9 matrix he? Geen translatie, translatie = evil

[ Voor 25% gewijzigd door Verwijderd op 15-11-2006 21:15 ]

[Bio]

DaCoTa schreef op woensdag 15 november 2006 @ 21:11:
Op een wat vrolijker noot Mijn rotatie van een 15x15 matrix werkt

Met als doel...? je hoeft toch all1 maar 5x5 matrixen te kunnen roteren?

[Verwijderd]

Jo-hannes schreef op woensdag 15 november 2006 @ 21:14:
[...]

Met als doel...? je hoeft toch all1 maar 5x5 matrixen te kunnen roteren?

Sommige mensen vinden het leuker/handiger/makkelijker om wat grotere matrixen te gebruiken.

Kijk bijvoorbeeld naar dit plaatje: http://www.imagehost.nl/view.php?file=images/nhk09933.gif

[Dido]

Jo-hannes schreef op woensdag 15 november 2006 @ 21:14:
Met als doel...? je hoeft toch all1 maar 5x5 matrixen te kunnen roteren?

Kijk eens een pagina of zo terug?

[RobIII]

Verwijderd schreef op woensdag 15 november 2006 @ 21:14:
Toch wel cache rotatie in een 9x9 matrix he? Geen translatie, translatie = evil

Een matrix?
Nee, het eerste wat ik doe bij het inlezen van de blockdefenities is het hele ding padden tot het 5x5 is, vervolgens weggooien van alle \r en \n's en vandaaruit voer ik in een string van 25 tekens lang alle rotaties uit (En nee, dat lieg ik niet )
Translaties?
Ik werk met offsets

[ Voor 4% gewijzigd door RobIII op 15-11-2006 21:33 ]

[Verwijderd]

Dus je voert een translatie uit op een offset van de shift?

Nee nu is me het helemaal duidelijk, dat ik daar niet eerder aan gedacht heb.


Zou je eigenlijk ook het hele blokje in een integer kunnen zetten en met behulp van AND, XOR, shift etc de rotatie uit kunnen voeren? Dat zou wel stoer zijn (en nutteloos).

[DaCoTa]

Even voor de zekerheid:

Van

code:

00000
01X10
00100
00100
00000

naar

code:

00000
01000
0X110
01000
00000

is toch CCW? Voor ik hele grote fouten bega...

[Bio]

Dido schreef op woensdag 15 november 2006 @ 21:16:
[...]

Kijk eens een pagina of zo terug?

volgens mij kijk ik scheel...of jij hebt heel erg veel berichten pp

[Verwijderd]

@DaCoTa:

Jups volgens mij wel

Alleen let bij je implementatie erop dat je de X op de 8e kolom neer zet, das ff iets om rekening mee te houden.

[ Voor 4% gewijzigd door Verwijderd op 15-11-2006 21:26 ]

[Dido]

DaCoTa schreef op woensdag 15 november 2006 @ 21:23:
Even voor de zekerheid:
[...]
is toch CCW? Voor ik hele grote fouten bega...

offtopic:
Vroegah, he, toen we nog klokkies met handjes hadden...

[PiepPiep]

Verwijderd schreef op woensdag 15 november 2006 @ 21:22:
Dus je voert een translatie uit op een offset van de shift?

Nee nu is me het helemaal duidelijk, dat ik daar niet eerder aan gedacht heb.


Zou je eigenlijk ook het hele blokje in een integer kunnen zetten en met behulp van AND, XOR, shift etc de rotatie uit kunnen voeren? Dat zou wel stoer zijn (en nutteloos).

Ik weet wel een grappige manier om de volgorde van de bits om te wisselen, stel a is een 16 bits integer.
a = ((a & 0xFF00)>>8) | ((a & 0x00FF)<<8)
a = ((a & 0xF0F0)>>4) | ((a & 0x0F0F)<<4)
a = ((a & 0xCCCC)>>2) | ((a & 0x3333)<<2)
a = ((a & 0xAAAA)>>1) | ((a & 0x5555)<<1)
Alleen om te roteren in een 5x5 grid/array is iets anders denk ik, stukje lastiger.

[RobIII]

Dido schreef op woensdag 15 november 2006 @ 21:27:
[...]

offtopic:
Vroegah, he, toen we nog klokkies met handjes hadden...

Vroegah, he, toen we nog verder keken dan onze neus lang was



Kom mensen! Is er al iemand die wat (min of meer zinnige) output heeft? Zijn er al projectjes goed op dreef? Of wordt het weer allemaal last-minute werk? Zijn we het roteren/transleren stadium al voorbij en kunnen we al gaan puzzelen?

[ Voor 34% gewijzigd door RobIII op 15-11-2006 22:11 ]

[.oisyn]

Verwijderd schreef op woensdag 15 november 2006 @ 21:04:
Laten we er niet verder op discussieren, het is me duidelijk dat je hier amper een opmerking kunt maken zonder een lading zooi over je heen te krijgen.

Grappig dat alleen jij dat ervaart. Wellicht dat daar dan ook de crux zit? Zomaar een suggestie

[Verwijderd]

- Weg dan maar -

Vergeten we het gewoon

[ Voor 81% gewijzigd door Verwijderd op 15-11-2006 22:21 ]

[.oisyn]

Je hebt gelijk, ik drukte op reply zodra ik je reactie zag. Had eerst verder door moeten lezen.

[DaCoTa]

Ok, het eerste tetris resultaat:

code:

|               |
|       X       |
|     XXX       |
|       X       |
|     XXX       |
+---------------+

RobIII, jij videopatser

[ Voor 11% gewijzigd door DaCoTa op 15-11-2006 22:47 ]

[RobIII]

DaCoTa schreef op woensdag 15 november 2006 @ 22:43:
Ok, het eerste tetris resultaat:

code:

|               |
|       X       |
|     XXX       |
|       X       |
|     XXX       |
+---------------+

Mijn "GUI" in actie (visuele test-app voor de achterliggende validator).

[Creepy]

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


Prima.

Bedankt dat er nog iemand is in het rood die wel weet hoe hij antwoord moet geven

* Creepy hapt. Toen je de kots smiley gebruikte hield ik me in.

Kappen met op de man spelen. Dank u.

[ Voor 40% gewijzigd door Creepy op 15-11-2006 22:51 ]