NeuralChess - projektrapport 2 Innehåll 1 Mål 3 2 Projektbeskrivning 3 3 Tillvägagångssätt Representation

Transkript

1 NeuralChess - projektrapport 1 NeuralChess en projektbeskrivning av Nicklas Nilsson ( ) d95-nni@d.kth.se Micke Wibom ( ) d95-mwi@d.kth.se c

2 NeuralChess - projektrapport 2 Innehåll 1 Mål 3 2 Projektbeskrivning 3 3 Tillvägagångssätt Representation Brädesrepresentation Slump-indata Utdatarepresentation Stored values Promotion Indata-moveno Feedforward `Hopfield' Reinforcement Träning Implementation Schackspel Spelaruppbyggnad Datorspelare Människospelare Speltyper (m-d d-d) Datasändningar Upptäckt av matt- och remiposition Startbräden Problem Bara dumma tillåtna drag Statistik Konvergens Representation Pjäsen ej med i utdatat Ej avsiktliga drag kan göras Svag koppling mellan indata och utdata Komplex implementering Resultat Hur duktig neuralchess är Saker att förbättra Maximalt uppnåbar duktighet (begränsningar) Slutsatser 11

3 NeuralChess - projektrapport 3 1 Mål Vårt mål var att: få inblick och förståelse för tillämpningar medelst ANN. ge oss en yrkesförberedande insikt i projektlösning medelst ANN. 2 Projektbeskrivning Projektet gick ut på att lära datorn spela schack. Datorn skulle använda ett neuralt nätverk för att bestämma lämpliga drag. Vår målsättning var att vi skulle se en systematik i dragen, samt en förmåga till inlärning baserat på erfarenheter. Vi hade dessutom förhoppningen att datorn skulle ge ett motstånd motsvarande en nybörjare ischack. 3 Tillvägagångssätt Systemet går i huvudsak ut på att trasformera indata till utdata genom ett feedforward-nätverk. För att få systemet att lära sig används reinforcement-inlärning. 3.1 Representation Brädesrepresentation Schackbrädet 'visas upp' för feedforward-nätverket som ett bitmönster i indatalagret. Varje ruta på schackbrädet representeras som fyra bitar och schackrutorna på brädet ligger i en följd i indata-lagret. De fyra bitarna, som utgör varje ruta på brädet, representerar en pjäs (eller sorts pjäs). Se figur Slump-indata Vi ansåg att en av de fördelar man har som människa när man spelar schack är att man är oförutsägbar. Datorn, som får ett givet inbräde och gör en fix transformation till utdata, kommer att vara helt förutsägbar. Därför försåg vi datorn (via 8 bitar indata) med slump Utdatarepresentation Vi valde en enkel utdatarepresentation, som går ut på att man har två 64-bitarsbräden; ett som representerar vilken ruta som en pjäs skall flyttas ifrån och ett bräde som representerar vilken ruta som skall flyttas till. Se figur Stored values Vi lade 50 bitar i utdatalagret, som återkopplas till ingången för nästa drag. Detta är för att datorn skall ha någon form av minne, exempelvis för att komma ihåg om motspelaren är av offensiv eller av defensiv karraktär Promotion I utdatalagret finns det två bitar som kontrollerar till vilken pjäs en bonde som nått sista raden skall promotas till. Det kommer antagligen att ta mycket lång tid innan den lär sig detta, men vi ansåg att funktionen skall finnas inbyggd.

4 NeuralChess - projektrapport 4 Figur 1: Brädets representation. Figur 2: Utdatat representation.

5 NeuralChess - projektrapport 5 Figur 3: Hela feedforwardnätverket Indata-moveno I indata lade vi även 8 bitar, som representerar hur många drag som är gjorda. Detta för att datorn skall kunna inse om en defensiv strategi leder till för långa partier. 3.2 Feedforward Feedforward-nätverket är variabelt; det är uppbyggt av 321 bitar indata, W antal gömda lager med Wi antal neuroner per lager, samt 180 bitar utdata. Nätverket är fullt kopplat mellan lagren. Neuronerna summerar indata och transformerar det med en sigmoidfunktion. Detta garanterar utdata från neuronen i intervallet [-1 1]. Se figur `Hopfield' Vår intention var att utdraget skulle bestämmas från utbrädena (se 3.1.3) genom ett hopfieldnätverk. Vår slutgiltiga lösning blev nu något enklare, men vi har ändå valt att kalla den "hopfield". Det funkar så att det är som ett hopfieldnätverk, med full kopplig mellan de båda brädena, men utan kopplingar inom de båda brädena. Dessa vikter är antingen -1 eller 1, -1 om draget är omöjligt och 1 om draget är möjligt. Vi gör ingen särskiljning på huruvida ett drag är ett bra drag eller ett dåligt, utan vi avgör bara om det är tillåtet. Därefter letar vi upp det största värdet för en multiplikation av en neurons värde på det ena brädet, en neurons värde på det andra brädet, samt vikten däremellan. Eftersom alla neuronvärden är positiva såkommer ogiltiga drag att resultera i ett negativt värde och giltiga drag i ett positivt. Det största värdet kommer att vara ett av de drag som datorn helst vill göra. 3.4 Reinforcement När datorn antingen nått slutet av ett parti eller belönas/straffas under spelets gång körs en procedur som förstärker respektive försvagar vikterna i viktmatrisen. Varje vikt

6 NeuralChess - projektrapport 6 förändras i proportion med hur mycket den bidragit till det aktuella resultatet. När ett parti är slutspelat gås varje drag igenom och viktmatrisen uppdateras för varje drag beroende på hur partiet gått. Storleken på förändringen är, förutom typ av spelavslut (vinst, förlust eller remi), relaterad till antalet drag partiet pågick. 3.5 Träning För att kunna träna snabbt och mycket lät vi datorn träna mot sig själv. Till att börja med försökte vi använda normala speluppställningar. Datorn spelade en serie partier mot sig själv och sparade ner resultatet med jämna mellanrum. För att datorn skulle ha större möjlighet att spela schack matt lät vi den få enkla uppställningar att utgå från. En normalgod spelare skulle kunnat göra matt i ett eller ett par drag. För att datorn skulle få större statistisk variation i motståndet spelades partier mellan fyra olika spelare. Senare började vi även med att variera startuppsättning för dem. 3.6 Implementation Vi skrev hela programmet i C. Det är uppdelat i 10 olika filer/moduler som handhar olika delar av systemet. Det är 142 kb kod, som är skrivet under framförallt augusti '98 - oktober '98. Därefter har vi mest gjort små buggfixar och andra förbättringar. 4 Schackspel 4.1 Spelaruppbyggnad För att spela med programmet krävs att man i förhand har skapat spelarprofiler. Detta görs av programmet och görs för både människa- och datorspelare Datorspelare När man skapar en ny datorspelare sparas dels en hel del inställningar om datorspelaren, dels datorspelarens neurala viktmatris, d.v.s. datorspelarens kunskaper. De inställningar som sparas är bland annat datorspelarens 'Namn', hur snabbt den ska lära sig saker, hur många lager det är i datorspelarens neurala nätverk samthur många neuroner det är i varje lager. Därutöver finns det en hel del parametrar som vi i dagsläget inte använder, men programmet är förberett för mer avancerade inställningar. Viktmatrisen som skapas är bara en nedsparning av de värden som utgör vikterna i det neurala nätverket. Dessa vikter slumpas fram i ett litet intervall när spelaren skapas, och sparas i dagsläget bara som en lång rad okomprimerade flyttal. Detta gör att datafilerna kan bli ganska stora, i storleksordningen 5-10 Mb Människospelare När man skapar en människospelare skapas ju ingen viktmatris, men däremot skapas vissa av de inställningar som gällde för datorspelare. 4.2 Speltyper (m-d d-d) Man kan antingen spela människa mot dator eller låta två dataspelare spela mot varandra. Vi har inte implementerat programmet så att två människor kan spela mot varandra, eftersom man då inte utnyttjar ett neuralt nätverk, vilket ju detta projekt gick ut på. Tanken med att låta två datorspelare spela mot varandra är att de ska kunna lära sig genom att spela mot någon jämnbördig motståndare samt att kunna spela många partier mot en outtröttlig spelare.

7 NeuralChess - projektrapport Datasändningar Om man spelar själv mot datorn kommer datorn att presentera ett textbaserat bräde efter varje drag, för att underlätta för människospelaren. Om datorn spelar mot en annan datorspelare kommer den att skicka dragen som spelarna gör. När man spelar mot datorn förstår den drag som är givet på algebraisk notation samt att ge vilka rutor som draget går emellan (t.ex. a5-c7) Upptäckt av matt- och remiposition Datorn upptäcker att den själv är matt genom att den försöker göra ett 'tillåtet' drag. Om den efter att ha försökt draget upptäcker att den står i schack, så sätter den att den förflyttningen inte är tillåten, återställer brädet och försöker flytta igen. Detta itereras tills ett giltigt drag, som inte försätter datorn i schack, har gjorts. Om datorn inte kan göra något drag är det remi om datorn inte stod i schack innan den ville göra ett drag, och schack matt om den stod i schack innan draget. 4.3 Startbräden När man startar ett parti kan man ange en annan speluppställning än det traditionella. Man anger ett filnamn till en fil som innehåller uppställningen på formen: rnb.kbnr pp.ppppp.qp b.....p... PPP.PPPP RN.QKBNR 5 Problem Schack är ett komplext spel. Förutom de rent implementationstekniska problemen har vi haft lite mer designmässiga problem. Ett problem var hur datorn skulle representera de drag den ville göra. Vår lösning kräver en utdatamängd på 128 bitar, medan en representation med varje pjäs från varje ruta till varje möjlig annan skulle kräva ca bitar utdata. Vår representation ger dock problem med läge i figur 5. Ett annat problem var att vi inte visste hur stora matriser (antal gömda lager och deras storlek) som behövdes, och vi har egentligen bara testat vad som verkar vara rimligt. 5.1 Bara dumma tillåtna drag När programmet började spela hade vi problem med att den gjorde korrekta, men totalt meningslösa drag. Ofta flyttade den samma pjäs fram och tillbaka (mellan två rutor). Detta berodde på att den ansåg att dessa rutor var mycket viktiga att flytta från och till oavsett hur indatat såg ut. För att komma ifrån detta beteende gav vi datorn en liten belöning varje gång den slog en av motståndarens pjäser. Detta löste till viss del problemet, speciellt i början av partierna.

8 NeuralChess - projektrapport 8 Figur 4: Exempel på felsituation. 5.2 Statistik Vårt största problem var troligen den inbyggda statistiken i schack. Programmet insåg snabbt att om den flyttade sina pjäser till vissa rutor, där motståndarens pjäser ofta brukar stå, tycker datorn att den gör ett bra drag, oavsett om motståndaren har en pjäs där för tillfället. Problemet uppkom efter försök att lösa problem 5.1. Vi försökte lösa statistikproblemet genom att istället för att spela varje parti från den traditionella startpositionen så slumpade vi istället fram bräden, som den fick utgå från. Därmed har vi skapat problem 5.3. Problemet att den spelade efter statistiska positioner på brädet försvann. 5.3 Konvergens När programmet inte kunde se något tydligt förhållande mellan indata och utdata (efter lösning av problem 5.2), började den att producera utdata där den antingen påstod att den inte ville flytta från och till någon av rutorna eller att den ville flytta från och till alla rutorna. Därigenom försvann differentieringen av utdatat. Detta medför att den inte använder sin kunskap vid val av drag, utan att implementationen gör att första hittade möjliga drag utförs. Vår lösning bestod i att försöka justera vikterna vid inlärning, så att summan av utdatat inte divergerar mot noll eller oändligheten, utan konvergerar mot ett av oss fixt värde. Detta löste problemet, men försämrade inlärningshastigheten. Detta stör inlärningen med upp till 50%. Problemet är så komplicerat att vi efter denna försämring av inlärningshastigheten, inte har hunnit verifiera att datorn får en tydlig strategi i sitt spel. 5.4 Representation När vi började klura på hur man skulle representera utdata, insåg vi att det fanns triviala, men ej fullt så smarta lösningar, t.ex. att representera alla möjliga drag med

9 NeuralChess - projektrapport 9 en bit i utdatat skulle innebära ca bitars utdata. En annan möjlighet skulle vara att representera alla just nu möjliga drag (som skulle kräva ca 50 bitars utdata) men där det är svårt att få programmet att förstå hur vi mappar de tillånta dragen till de olika bitarna i utdatat Pjäsen ej med i utdatat Vår lösning (beskriven i pkt 3.1.3) saknade koppling till vilken pjäs som flyttades, det var feedforwardnätverket tvunget att ta hänsyn till direkt från indatat. Nu fick den välja hur (varifrån, och vart) den skulle flytta och inte vilken pjäs som var viktig att flytta. Detta kan ses som en brist, men vi ansåg att detta inte var något problem, förutom att inlärningshastigheten skulle kunna bli lidande Ej avsiktliga drag kan göras Ett annat problem var att den kan göra oönskade drag. Om det finns två lika bra drag kan den i värsta fall flytta från frånrutan i ett av dragen, till tillrutan i det andra draget, förutsatt att även detta drag är tillåtet, se figur 5. I figuren så finns två rutor för vit att flytta till och två rutor att flytta från. Kombineras dessa fel, uppstår en ödesdiger situation. Svart kan göra matt i ett drag f1=q (F2 F1). Det enda sättet för vår representation att komma ifrån detta är dels att feedforwardnätverket blir så duktigt att det bara föreslår korrekta drag, dels att den blir så säker att den bara föreslår ett drag i utdatat. Vi är osäkra på om programmet kan komma så långt, men det är ändå inte ett så stort problem eftersom det inte är så ofta som denna situation uppkommer. 5.5 Svag koppling mellan indata och utdata Eftersom detta feedforwardnätverk hade relativt många indata, indata som dessutom var ganska kryptiska (fyra bitar representerade en pjäs, bitarna sade inte något i sig om egenskaperna för den aktuella pjäsen), så var det svårt att få feedforwardnätverket att använda sig av indatat för att konstruera ett utdata. Vi upptäckte att feedforwardnätverket till stor del producerade ett fixt utdata oavsett vilket indata vi gav det. Vår lösning på detta var att ta bort de bitarna i indata som var slump (se pkt 3.1.2), och detta avhjälpte problemet till viss del, men är ändå ett allvarligt kvarstående problem. 5.6 Komplex implementering När vi började med detta projekt visste vi inte hur komplext det skulle bli. I dagsläget är det 142 kb kod och det är inte riktigt överblickbart. Vi saknade kunskaper i processkommunikation, vilket gjorde att programmet kommunicerar med andra processer med hjälp av pipes; om vi har tid kommer vi att göra om så att den använder sig av sockets. Detta har omöjliggjort att koppla på ett grafiskt gränssnitt, eftersom det skulle kräva radikala ändringar i programmet. Komplexiteten gör också att felsökning blir ett mycket tungt arbete.

10 NeuralChess - projektrapport 10 6 Resultat 6.1 Hur duktig neuralchess är Hur duktig är då vårt program? Jo, i dagsläget så spelar den schack dåligt. Den spelar dock helt korrekt schackoch programmet är stabilt. Den har spelat mycket bättre. När programmet lärde sig statistik över var motståndarens pjäser brukade stå, så hände vid ett flertal tillfällen att två program, som spelade mot varandra, lyckades komma till schack matt. Det ser vi som ett bevis för att idén och programmet fungerar, den kan lära sig saker, även om det kanske inte är de bästa kunskaperna. 6.2 Saker att förbättra Saker att förbättra finns det ju alltid i ett program, men vi skulle vilja påstå att hela den delen som handlar om att implementera ett feedforwardnätverk med reinforcementinlärning är klar. Det som finns kvar att göra är saker som mer har att göra med inställningar av programmet, med optimeringar av programmet och med gränssnittet till programmet. I dagsläget använder datorn pipes för att kommunicera mellan två datorspelare, och stdio/stdout för att kommunicera mellan människa och dator. Detta borde göras om så att datorn alltid använder sockets för kommunikation. Detta skulle ge helt andra möjligheter att koppla ett på ett grafiskt gränssnitt till programmet. Vi har implementerat ett grafiskt gränssnitt, men detta skulle behöva anpassas mer till schackprogrammet, likväl som att schackprogrammet skulle behöva modifieras för att passa gränssnittet. Dessutom skulle vissa ändringar behöva göras i schackprogrammet för att det skall klara av att användas på webben. I början när man försöker lära upp en ny datorspelare måste man ge den lite belöning för att få den att göra framsteg. Vi har exprimenterat med att ge belöning när den slår någon av motståndarens pjäser. Detta gav resultat så till vida att den blev klart bättre på att gå framåt med sina pjäser och att slå motståndarens pjäser. Dock är inte detta önskvärt i längden, eftersom det viktiga är att den vinner spelet och inte att den slår många av motståndarens pjäser. Programmet saknar i dagsläget ett enkelt sätt att ställa in om den ska belöna för delmål eller bara belöna för schack matt. I dagsläget finns det inställningsfiler för alla spelarna, men inte för programmet i sig. Det skulle behövas någon central inställningsfil som reglerar belöningar, vilka kataloger som allt ligger i och grad av loggning. Detta skulle vara mycket lättare än att behöva göra dessa ändringar i källkoden och kompilera om programmet varje gång man har gjort en ändring... Att bestämma lämplig storlek på belöningar och bestraffningar är ingen lätt uppgift. Vi har bestämt dessa storlekar genom att helt enkelt resonera oss fram till vad som skulle vara lämpligt. Detta skulle dock behöva verifieras eller optimeras för att minska på inlärningstiden. 6.3 Maximalt uppnåbar duktighet (begränsningar) Hur duktigt kan programmet bli? Ja, vad finns det för begränsningar? Det finns bara 8 bitar slump in för feedforwardnätverket att använda, det tar lång tid att öva upp nätet när det är stort och att bara lära datan mot en annan dataspelare kan ge lite konstiga effekter i strategin misstänker vi. Vissa problem kan uppstå genom att datorn gör ej avsiktliga drag, som beskrivs i punkt

11 NeuralChess - projektrapport 11 7 Slutsatser Oj, vad detta blev stort och var svårt... Det har varit kul och lärorikt, men det har tagit alldeles för mycket tid. Vi känner att det är lite för mycket hokus-pokus för att vi ska ha full kontroll på de problem som har uppkommit. Programmeringstekniskt har vi inte haft så stora problem att klara av det, men vi har haft för dåligt insikt i praktisk implementation, representation, och felsökning av neurala nätverk. Vi hade även lite för svaga kunskaper i uppbyggnad av stora programsystem. Men, det positiva med detta är att vi har lärt oss oerhört mycket, och vikänner båda att detta är ett område som vi skulle vilja jobba med, om bara möjlighet finns.