It depends on what you want to do with the representation. Usually a
go programmer only needs to match the current position with an old one
either to implement super ko correctly or perhaps updating some
statistics for the position like in an opening database.
For this purpose using a standard 64-bit Zobrist hash code where you
simple xor together a random 64-bit integer each stone on the boards
and for example the direct ko or who is to play. Thus you need only
store 8 byte for each position + whatever extra you want to associate
with it.
But you cannot reconstruct a position from the Zobrist code, so if you
need to access what the board actually looked like i guess you need to
use at least 2bit per possible stone, unless you make it really
compressed.
Does it have to be human readable? I guess this what you want when I
reread your post.
A more standard way in my thinking is to not store the position but
simply list the moves that lead to the position, for example the
standard SGF file format which is then universally portable as well. I
am not used to FEN notation in chess so I do not know what uses it has.
Well that was at least some alternatives that would be standard for a
go programmer but maybe you need something new and then perhaps you
are the first to do it.
Oh, where are also standard pure text ascii diagrams that for example
gnugo and gogui can read and export. You might have a look at that
too. This is from Gogui:
A B C D E F G H J
9 . . . . . . . . . 9
8 . . . . O X . . . 8
7 . O O O + X + O . 7
6 . X X . X . X O . 6
5 . . + . X X O . . 5
4 . . . . . . O . . 4
3 . . + X + O + . . 3
2 . . . . X . . . . 2
1 . . . . . . . . . 1
A B C D E F G H J
Black to play
But this may lack complete state information. I do not know if there
are some proper definition of this.
Best
Magnus
Quoting davi vidal <[email protected]>:
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
