[computer-go] Problems in SGF format

[Mark Boon]

On 1-okt-06, at 17:49, Antoine de Maricourt wrote:

> I was one of the (probably many) people that suggested Thomas Wolf  
> to use SGF. However, I found out that SGF files were not practical  
> to handle large collections of problems. I finally developped a  
> small custom database-like format that I found much more convenient  
> to use. The main problem I had with SGF files was to automatically  
> add new positions that caused an assertion to fail in my program  
> (in order to build non-regression tests), and to ensure I did not  
> add duplicated positions in the collection.

Those are valid points. I agree that storing problems in a database  
offers more flexibility. But it's harder to share. For now I'm happy  
to think of problem collections in an SGF file. Maybe later I'll move  
them to a database, but with the proper access interfaces the  
difference shouldn't be major.

I've been thinking about this and related issues for a few days now  
and haven't gotten to much actual programming. So far I haven't  
concerned myself with any UI for my project, I've used GoGui where an  
interface was required. But now I need to debug a 3-liberty module  
and I need a way to inspect the move-tree and the results of the  
reading process. I may be able to deug it simply using a debugger,  
but I know I'm going to need this later for other readers anyway.

Previously I had made a simple front-end where I used the concept of  
data-providers and tactical-readers. I've discussed data-providers  
before, I'll now concentrate on the tactical-readers. Basically an  
engine will contain several tactical readers to perform different  
tasks. What I'd like to have is a way to ask the engine for the  
readers available. Then I'd like to be able to send a reader a  
problem. This where the bit about standard coding of problems in SGF  
comes in. So I'd probably like to have a GTP command that has the  
form of "read_problem <reader_name> <problem_sgf>" which returns sgf  
containing the move-tree annotated with results.

There are different paths I can now take. I can adapt the simple  
front-end I have to communicate with GTP or I can adapt GoGui. In  
both cases I'll have to add some private extensions to GTP. (I also  
still want my engine to be able to connect to a socket instead of the  
named pipes, so I can use the front-end but run my engine in debug- 
mode. But that's maybe of a later concern.)

Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://computer-go.org/pipermail/computer-go/attachments/20061002/64eb30c3/attachment.htm