I'm not thinking of a piece-centric encoding scheme, more of a board cell-centric scheme. A cell might have a piece occupying it, and the representation the encoder creates will have sections for each cell, not each piece. --------- Matt Taylor OS Community Flag-Bearer Numenta
On Tue, Apr 14, 2015 at 11:50 AM, cogmission (David Ray) <[email protected]> wrote: > Interesting, so I wasn't that far off? > > If you assign bits to each piece (irrespective of color and type) then you > can get the "history" of movement of each piece no? > > In other words if each piece has its own encoding (the color and type become > implicit) and you know that from one state to another pieces moved but you > **keep** the information about how the pieces moved rather than simply that > there's a color and type of piece here, and now there is one (never mind > which one) that is here. The latter loses transition information, doesn't > it? > > > > On Tue, Apr 14, 2015 at 12:07 PM, Matthew Taylor <[email protected]> wrote: >> >> Also, this may be relevant when encoding a board state: >> http://erikbern.com/?p=841 >> >> I'd like our first try to be just encoding the board state, with no >> information about attacking, defending, moves till check, etc. It >> would be great if all these attributes of the board can be inferred, >> so let's start as simple as possible. >> >> We brainstormed at lunch a bit about this, and I think we could have >> 64*7 bits in the encoding. >> >> 64 cells, and each cell has 7 bits. >> 1. color of piece >> 2-7. one bit for each piece type (pawn, rook, knight, bishop, queen, king) >> >> I believe we'll need to mix up the cells so no false associations are >> made like we do in the Coordinate encoder. Otherwise there will be a >> local semantic association between H8 and A7 (for example) that >> doesn't actually exist. Using a random order might be a solution (I >> haven't asked Chetan about this yet, but he'd know better). >> >> --------- >> Matt Taylor >> OS Community Flag-Bearer >> Numenta >> >> >> On Tue, Apr 14, 2015 at 9:21 AM, Matthew Taylor <[email protected]> wrote: >> > Indeed, I don't want to teach it rules at all. All it should need is a >> > rich history of game board states. >> > >> > I've started a little project, and I'm up to the point of creating a >> > chess board encoder: >> > >> > https://github.com/nupic-community/nupic.chess >> > >> > Anyone want to try building an encoder based on chess FEN board states? >> > >> > --------- >> > Matt Taylor >> > OS Community Flag-Bearer >> > Numenta >> > >> > >> > On Tue, Apr 14, 2015 at 9:04 AM, David Wood <[email protected]> >> > wrote: >> >> Hi all, >> >> >> >> It seems to me that people learn chess by watching, studying or playing >> >> games. Sometimes they learn the rules experientially like that as well. >> >> So, >> >> perhaps a way to teach NuPIC to learn chess is by simply feeding it the >> >> patterns of real games so it can learn those patterns. It might not need >> >> to >> >> have the actual rules encoded at all… >> >> >> >> Regards, >> >> Dave >> >> -- >> >> http://about.me/david_wood >> >> >> >> >> >> >> >>> On Apr 14, 2015, at 09:56, Ralf Seliger <[email protected]> wrote: >> >>> >> >>> @Matt: >> >>> Well, that's what I call a coincidence! Nice piece of code, btw. You >> >>> (or your son) missed en passant and castling, however ;-) >> >>> >> >>> @Matt, @David: >> >>> SDR encoding of chess positions: I guess the real problem is capturing >> >>> the semantics. Imagine for instance all positions allowing "mate in one". >> >>> Those position will look wildly different from each other on the board, >> >>> but >> >>> would have to have a similar SDR, wouldn't they? >> >>> >> >>> >> >>> Am 13.04.2015 um 20:52 schrieb David Ray: >> >>>> I have an idea for the encoding! >> >>>> >> >>>> How about this: >> >>>> 1. There are 32 different pieces, so you need 5 bits for a piece. (W) >> >>>> 2. There are 64 squares on a chess board, so you need 64 * 5 bits to >> >>>> be able to place any piece on any square. >> >>>> 3. Amend the above (#1) to have 6 bits - you need to encode a "empty" >> >>>> piece - making #2 64 * 6 bits. >> >>>> >> >>>> So now you can express the entire chess board with all pieces having >> >>>> a square plus missing piece squares (empty squares). You should probably >> >>>> have topography using 64 * 6 bits so you might have to fudge to get an >> >>>> even >> >>>> root by upping the number of bits encoding a piece? >> >>>> >> >>>> Does that make sense? >> >>>> >> >>>> Another option is to use a MultiEncoder with a GeoSpatial and scalar >> >>>> encoder inside. Make a dimple coordinate system for the 64 squares of >> >>>> the >> >>>> chess board. >> >>>> >> >>>> David >> >>>> >> >>>> Sent from my iPhone >> >>>> >> >>>>> On Apr 13, 2015, at 1:14 PM, Matthew Taylor <[email protected]> >> >>>>> wrote: >> >>>>> >> >>>>>> On Mon, Apr 13, 2015 at 11:07 AM, Ralf Seliger <[email protected]> >> >>>>>> wrote: >> >>>>>> For an example have a look at https://web.chessclub.com which is a >> >>>>>> web >> >>>>>> interface to the Internet Chess Club servers written in >> >>>>>> JavaScript/jQuery >> >>>>>> (client) and node.js (server). >> >>>>> Wow, that looks familiar... I created this (client-only) chessboard >> >>>>> with my son while trying to teach him some programming concepts: >> >>>>> >> >>>>> http://rhyolight.github.io/chesster/ >> >>>>> https://github.com/rhyolight/chesster >> >>>>> >> >>>>> On another note, I'm interesting in figuring out how to encode the >> >>>>> state of a chessboard into an SDR so I can train a model on a >> >>>>> database >> >>>>> of history chess games. >> >>>>> >> >>>>> --------- >> >>>>> Matt Taylor >> >>>>> OS Community Flag-Bearer >> >>>>> Numenta >> >>>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > > > > -- > With kind regards, > > David Ray > Java Solutions Architect > > cortical.io > Sponsor of: HTM.java > > [email protected] > http://cortical.io
