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
