One way is the store the position as a list of moves.   That captures
EVERYTHING include KO state.

A hash key is another way,  but requires some context and brand new
positions cannot be represented.

fen is reasonably compact and human parseable,  but for sequences of empty
points you would have to use 2 digit numbers or else to keep the parser real
simple you could stick with 1 digit number and add them up.   2 digit
numbers are easy to parse in C however since they will always be followed by
a non digit.

The list of moves solution can be made more compact by removing the spaces -
but it slightly complicates the parser.

My preference is a list of moves separated by spaces.

The GTP protocol does not define a way to specify a position other than as a
list of moves or stones to be placed on the board.  However you can
represent any position as a list of moves if you allow for a null move.
 For example a board with only 3 black stones on a 9x9 board might be:

     e5 - d5 - c5

The hyphen represents non-moves by white.

If this is internal only and ascii text is not required,  you can represent
the position as 2 bit boards.  A white bit-board has a bit set that
represents all white stones and a separate black bit board for the black
stones.   The bit board needs to be large enough for the specific board size
in questions of course.

You can get into more sophisticated things with compression,  etc.

Don







On Tue, Dec 28, 2010 at 9:42 AM, davi vidal <[email protected]> wrote:

>   Hello everyone. I'm new to this list.
>
>   Sorry for resurrect such old thread, but after read it all, I can't
> reach a conclusion: is there anyway to represent a Go position?
>
> http://www.mail-archive.com/[email protected]/msg05749.html
>
>    I'm aware about the *ko rules and that I can't say if the current
> position already happened in the game.
>
>    My problem: I just need to store the current position in the game
> plus the side to move. Is FEN sufficient? Also, if I need to deal with
> *ko rules/repetition, I'm considering store all positions, since the
> worst scenario (from file size perspective) would be the entire board
> covered plus a ko point:
>
>
> bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb/bbbbbbbbbbbbbbbbbbbb
> b s19
>
>    This FEN file have 428 bytes. Assuming 300 moves, I would spend
> 130 kB. Storage isn't my problem here.
>
>    So, my question is: is my approach reasonable? What would you
> recommend otherwise?
>
>    Again: sorry for resurrecting such old thread, but I couldn't find
> any "Search archives" function. Also, sorry about my poor English.
>
>    Regards,
>
> davi
> _______________________________________________
> Computer-go mailing list
> [email protected]
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go

Reply via email to