Good points. I'll do some experiments here and I'll post later.
davi 2010/12/28 Willemien <[email protected]>: > 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 > _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
