Yeah. I started to read the GTP specification, but I'm more
interested into SGF. I want to be able not just to store the games,
but it would be very interesting if I could open the games, say, in
Cgoban.
The SGF is not the problem, but I don't want to parse an entire
SGF just to show the current position, that's why I'm trying to find
something like FEN, or, in the case that is doesn't exists, suit FEN
(or other) to it.
Since I'm an "experienced" chess player, FEN looks nice for me,
that's why it's my starting point. :-) But I'm open to suggestions.
For the engine part, I won't bother with that for now. I think
that the 'FEN problem' is simpler. :-)
davi
2010/12/28 Jonathan Chetwynd <[email protected]>:
> Davi,
>
> if you are considering the possibility that you might save games and serve
> them at a future date,
> SGF, and GTP require an engine or sophisticated parser that 'understands' Go
> rules.
> This is a chore.
>
> JSON or XML offer possibility of multiple transforms, such as SVG or
> HTML.[1]
> One needs to include captures for appearance, rather than scoring.
>
> regards
>
> Jonathan Chetwynd
> peepo.com
>
> [1] peepo.com is currently served by Node.JS and stores games as space
> separated moves in a Redis-JSON database.
> An earlier LAMP versions stored games in XML format.
>
> On 28 Dec 2010, at 19:02, davi vidal wrote:
>
>> 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
>
> _______________________________________________
> 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
