Re: [gnugo-devel] 38x38

[Gunnar Farneback]

Evan wrote:
> The code is optimized to be fastest on the maximum supported board size;
> since the most common case is 19x19, that is what we set as the default
> maximum boardsize.

I doubt that the code is faster on 19x19 than, say, on 17x17. I do
agree that the speed on 19x19 should be slower with a larger
MAX_BOARD, though. More important than speed, however, is that the
memory consumption would increase (with indirect effects on the speed
as well).

> If you wish to change the maximum supported size, you will need to compile
> gnugo yourself. You will need to change the constant MAX_BOARD, defined in
> engine/board.h.  However, I don't really know if this will work; I have
> verified that it compiles, but have not done anything more.

It wouldn't work flawlessly at least. As far as I can remember we have
the following restrictions on board size:

* The caching scheme cannot handle boards larger than 31x31.
  I'm unsure how bad things might turn out with larger boards.
  Possibly it would only cause corrupted read results but I wouldn't
  rule out crashes or infinite loops.

* The GTP interface is restricted to 25x25 boards due to protocol
  limitations. 

* The GMP interface is restricted to 22x22 boards due to protocol
  limitations.

* The ascii interface is limited to 25x25 boards due to the
  interpretation of commands as moves.

* SGF input is limited to 52x52 due to SGF format limitations. GNU
  Go's sgf implementation doesn't seem to be able to handle more than
  26x26, however.

/Gunnar