Yes, I think Matt is correct about this. I recall a chess master from the 1970s or 1980s being asked how many moves he thought ahead. His answer was, “One. But it is always the right one.”
Regards, Dave -- http://about.me/david_wood > On Apr 15, 2015, at 12:14, Matthew Taylor <[email protected]> wrote: > > To be very clear about this, I have no idea whether NuPIC will be > decent at this. This task of chessboard prediction is not really > well-suited for NuPIC, because it is not a temporal problem. It seems > like one, but think about it. A temporal problem requires that you > have a historical memory of the past in order to make good decisions. > For a chess game, you don't need to know the past to make a decision. > You only need to know the current state of the board. > > Basically, we'll just be training NuPIC on a sequence of past board > states and asking it to predict the next state. I doubt strongly that > it will come up with a state that represents a legal move. But, I'm > still really interested in pursuing this problem because I'm not > really sure what will happen. And because I've never built an encoder > before. > > I also think it would be cool to visualize the board states that are > being encoded and the vectors the encoder is producing. > > --------- > Matt Taylor > OS Community Flag-Bearer > Numenta > > > On Tue, Apr 14, 2015 at 1:13 PM, Matthew Taylor <[email protected]> wrote: >> 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 >
