Gotcha. Sounds good to me. --------- Matt Taylor OS Community Flag-Bearer Numenta
On Tue, Apr 14, 2015 at 1:07 PM, cogmission (David Ray) <[email protected]> wrote: > Yes, so was I. I assumed my comments above would be "tacked on" to the > technique outlined in my previous post where I designated the 64 squares of > the board as part of the encoding? Then you would simply have one encoding > for an "empty" piece, thus using 6 bits times 64 squares? The discussion > above was just comparing/contrasting the separate encoding of types of > pieces and colors of pieces against encoding each actual piece (thus using > less bits also). It seems the result would be the same without losing the > transition history of each piece? But hey, its just a thought... > > On Tue, Apr 14, 2015 at 2:59 PM, Matthew Taylor <[email protected]> wrote: >> >> 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 >> > > > > -- > With kind regards, > > David Ray > Java Solutions Architect > > cortical.io > Sponsor of: HTM.java > > [email protected] > http://cortical.io
