Feature extraction

[depthfirst]

Rather than train from features of the current board state, I think we said it would be features of the current board state plus the board state for a specific move (stone placed on location (x,y)). So the features should in some way capture what makes a move good or bad. The classifier should effectively decide the probability that a move is a good one (will keep alive or kill).

Thoughts: Capturing stones, connecting groups, cutting opponent's groups, making eye, increasing/decreasing liberties.

Other ideas?

[Zac1164]

Just a heads up: I'm going to try to write a framework for training/testing today.

[depthfirst]

Hey, I was just working on that. I was going to convert your tree parser into a series of moves, extracting features for each. What did you have in mind?

[Zac1164]

Pretty much the same thing. I was going to standardize and crop the board, organize the moves, extract features, and tie it into the various subsets of the dataset. If you're already working on that though, I'll move on to something else. Are you doing standardization (i.e. determining black-to-kill vs white-to-kill vs black-to-live vs white-to-live) yet? I'm noticing error in the way I was doing it last night (namely, a file can have multiple tags, i.e. both black-to-kill and white-to-live, so while in principle, they're the same type, in practice, we need to know which class of problem a board actually belongs to for training; otherwise, we'll end up training on losing moves instead of preferred ones), so I'm working on a more conservative method for determining this (i.e. only looking at text that appears before the gameplay tags), but this might further reduce the set.

[depthfirst]

I haven't done any standardization yet, so that would be good. I added the start state parsing from parseBoard to MoveTreeParser. I did look at some files... only suggestion is maybe "Black to play" implies "Black to play and live". I could commit MoveTreeParser and let you have at it. I can work on the MinMaxTree, the UI or implementing features.

[depthfirst]

Do you want to work on standardization, and I'll work on extracting features? Or vice-versa?

[Zac1164]

Sounds good.

Sent from my iPhone

On Nov 22, 2014, at 3:02 PM, John Blackmore notifications@github.com wrote:

Do you want to work on standardization, and I'll work on extracting features? Or vice-versa?

— Reply to this email directly or view it on GitHub.

[Zac1164]

I'll wirk on standardization.

Sent from my iPhone

On Nov 22, 2014, at 3:02 PM, John Blackmore notifications@github.com wrote:

Do you want to work on standardization, and I'll work on extracting features? Or vice-versa?

— Reply to this email directly or view it on GitHub.

[depthfirst]

Should feature values always be correlated with how the move affects black? So the lowest value should be chosen if it's white's move and the highest if it's black's move?

[Zac1164]

I assume we're going to train two classifiers: one for white's moves and one for black's moves, and use the probability of classifying as a good move for x color as the minimax eval function. If these assumptions are correct, I don't think it should really matter. Can you give an example of where we would pick lowest value for white vs highest for black? Every feature I'm thinking of seems to be invariant to which stone is played (e.g. change in number of stones, change in liberties, change in average distance from centroid, etc.); can you give an example where white should be lowest, black highest?

[depthfirst]

DiffLiberties, StoneCountFeature. Invariably, calculates black - white.

[Zac1164]

Ok. I agree it should be black higher, white lower in those cases.