To be complete: If you use it for endpositions (or other plays where passes are reasonable moves)
Then it depends on what your scoring mechanism is. For Territory scoring you also need the prisoners difference. (or the diference in number of passes) For area scoring this is not nescesary and i think and the "picture" of the board is enough. On Tue, Dec 28, 2010 at 3:30 PM, davi vidal <[email protected]> wrote: > Sorry. I forgot to add that I'm storing the moves in SGF format. > What I'm going to do: get a Go position (dunno how, that's why I'm > asking about FEN), encode in JSON, parse in JavaScript and draw in > HTML. As backend, I'm using Ruby, so I can have something as > 8b10/19/19... and parse using regex. > > As far as I can understand from your posts and the previous > thread, the only drawback is the *ko rules/repetition that I *will* > miss with FEN, right? > > davi > > 2010/12/28 <[email protected]>: >> 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 >> > _______________________________________________ > 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
