> In MLA, in line move generation is performed as follows
>> Why add? Why not simply overwrite? It ought to be faster.
True. But adding makes undo a substraction of the same numbers. Also it allowed
me to define ranges for the move number, due to unchanged fields (0 values can
be added to anything). It's probably the reason why it's still performed this
way in MLA lol.

> But i'm also searching for a faster move generation
> I have previously posted a paperon how to do incremental computation of
compactness.
I found this paper long time ago lol, maybe i needed to understand it (gosh i
dont know latex lol i'm a windows guy). I finally converted it to PDF, lol, you
are right again. I'll most probably enhance the speed significantly (evaluation
is about 30% of the time i use).

> With respect to bitboards, I have not found a convincing case for them.
oh yes, finding patterns and handling rotation is documented by the author of
crafty too. your C is interesting. But trying to use the ONLY bitboards for
center of mass computation, move generation, domove/undomove might be hard. Hmm
this would even impact my search ... hmm for MLA 4.0 lol.

>Seriously, though - I would really love to hear more about useful patterns.
Oh yeah, i'll keep you posted, once i've understood why MLA 3.0 wins lol. As it
questions connectivity, connectivity means radius-1 patterns.

So well, i'm all set, i have good leads to increase speed, and probably good
leads to increase strength :)

What else would i need? Hmm maybe a good beer ;)

David.