RE: [gnugo-devel] Work in progress

[Portela Fernand]

Arend wrote:

> Well, result2 is unused in owl_attack/defend, and for the _result_ part
> of the cache entry, I don't see a need to have it work identically for
> different parts of the engine, you just need to provide different
> macros.
> If you can assure that the order of worms in catalog_goal is
> reproducable, then it might be sufficient to store the number of the
> worm in that list, so you could get away with 5-6 bits for almost
> any dragon?

Good idea. result2 is supposed to be 4 bits wide only, but if I understand
correctly, you're suggesting to use these plus the remaining bits in result.
(which would be 1 I think). So, 5 bits. It would suffice with
the current definition of MAX_WORMS (10), which should be increased I guess.
Or, should we be conservative, keep room for more codes and use 4 bits
only ? Keeping track of 15 worms looks fair enough...

Btw, about my problem with lazarus:7, it was actually a
combination of a bug and some missing handling code in value_moves.c
I could solve the problem with a workaround, but then i loose the
blunder:20 PASS. The "real" solution needs actually further modifications
in owl.c, specially with the caches I think.

Well, you were right Dan ;) this is getting quite complex.

/nando