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
