NEW POST: Maximum Blocks

tgiphil — Wed, 31 Oct 2007 19:15:46 GMT

Thanks for the correction; it was actually John Tromp <john.tromp@gmail.com> that posted the formula on the computer-go mailing list.

NEW POST: Maximum Blocks

jhouse — Wed, 31 Oct 2007 14:28:16 GMT

I don't remember creating any generic formula for the maximum number of blocks on the board. That formula may be the work of someone else.

NEW POST: Maximum Blocks

tgiphil — Wed, 01 Aug 2007 15:51:39 GMT

Regarding the maximum number of blocks on a board:

Jason House <jason.james.house@gmail.com>wrote:

> which confirm yours. we also found a general formula n^2 - floor((n^2+4n-16)/5)

Gunnar Farneback <gunnar@lysator.liu.se>wrote:

> The formula can also be written floor(4n(n-1)/5+4) for a slightly more compact expression.

This may be useful when optimizing the tracking of adjacement blocks.

NEW POST: GTPv3 & Asyncronous responses

tgiphil — Wed, 01 Aug 2007 15:46:50 GMT

Gunnar Farneback <gunnar@lysator.liu.se> wrote to the computer-go mailing list:

This is in the same direction I've been thinking. To make it consistent
with GTP version 2 and fully backwards compatible it can be designed
like this:

* Asynchronous responses from the engine are encoded like Paul proposes
but with "!" as first character (there is precedence in a protocol GTP
was originally inspired by). Naturally one response must be complete
before starting on another, whether synchronous or asynchronous.

* Asynchronous messages may only be sent as responses to asynchronous
commands. Thus a GTP version 2 controller would never become confused
by asynchronous responses it knows nothing about since it would only
send synchronous commands.

* Asynchronous responses have the same id as the command initiating
them. The id may as usual be omitted by the controller if it is
confident that it don't need it.

* An asynchronous command must first be acknowledged by a synchronous
response (would usually be an empty response if there are no problems
and otherwise an error response).

* An asynchronous command may additionally have zero, one, or multiple
asynchronous responses, depending on the nature of the command and the
situation. For example an asynchronous genmove command would normally
have one asynchronous response, but zero if the command is aborted. A
command requesting debug output could produce any number of
asynchronous responses.

* Whether an engine is capable of doing asynchronous responses can as
usual be tested by knowncommand or listcommands to see whether it
supports specific (asynchronous) commands.

* The asynchronous genmove command would be named async_genmove. In
contrast to the normal genmove command it would only generate a move,
not actually play it. (To keep sanity and avoid undos when the
ordering of move generation and abort command depends on race
conditions.)

* To abort the asynchronous genmove, the controller should send the
(synchronous) command abortasyncgenmove. If the engine has not
returned the asynchronous genmove response before responding to the
abort command, it is no longer allowed to return a move. I'm open for
discussion on the exact name and whether it should return an error if
the move had already been sent (I don't think it should).

Example 1: Asynchronous genmove with an intervening synchronous command.
Command 3 is sent after receiving the asynchronous move.

Controller:
1 async_genmove black
2 version
3 play black E5

Engine:
=1
=2 4.0
!1 E5
=3

Example 2: Asynchronous genmove, aborted. The controller plays an own
move instead.

Controller:
1 async_genmove black
2 abort_async_genmove
3 play black C3

Engine:
=1
=2
=3

Example 2b (BAD): Like example 2, but the engine makes an incorrect
response.

Controller:
1 async_genmove black
2 abort_async_genmove
3 play black C3

Engine:
=1
=2
!1 E5
=3

Example 3: Like example 2, but abort command comes too late.

Controller:
1 async_genmove black
2 abort_async_genmove
3 play black C3

Engine:
=1
!1 E5
=2
=3

Example 4: Asynchronous genmove sent to an engine not supporting it.

Controller:
1 async_genmove black

Engine:
?1 unknown command

/Gunnar

NEW POST: Open-source community development

tgiphil — Fri, 06 Jul 2007 19:57:07 GMT

If you have a passion for both computer Go and C#, please consider joining the GoTraxx project development team by e-mailing the project coordinator.

GoTraxx Forum Rss Feed

NEW POST: Maximum Blocks

NEW POST: Maximum Blocks

NEW POST: Maximum Blocks

NEW POST: GTPv3 & Asyncronous responses

NEW POST: Open-source community development