GIBBON Home Page

Home - Links - Siamang ? - More about Gibbons - Contact

Incremental-between-nodes move generation

This is maybe particular to Gibbon, as it does not use bitboards. Gibbon keeps for each piece a pointer to its actual list of moves. Before a node gets explored, a routine rays from lastmove-departure-square and lastmove-arrival-square to mark the pieces whose move lists are now obsolete. Only the moves of theses pieces are re-generated, and the move-list pointers of theses pieces are set to point to the new lists.

Advantages :

- after each ply, only a fraction of all moves need to be re-generated

- mobility is known at no additional cost

Drawbacks :

- overhead in list management

- the routine that rays from departure and arrival square takes time.

I could not figure out a way to get rid of it.

It would an achievement if the program could say easily :

last move departure was 24, arrival was 25 and thus pieces to actualise

are x and y. The attempts I made to get around this would

involve even more computations.

If you have got a clue, please let me know :-)

About Gibbon's name

At one point, I thought that a program that would be able to map the search tree into areas (programmatically) and thus better distinguish, and maybe decide, between major and minor branches, would be able to play with them like a … gibbon.

Unfortunately, the promise was not fullfilled, or maybe it is, but not in the way I expected, through the combination of nullmove and PVS. It seems to me that this combination does map the tree between PV nodes and potential nullmove nodes in a very efficient way.

Gibbon's future

- better speed, maybe threads, and other ideas !

Dreams

- improvements on evaluation function to recognise :

- patterns for initiative on queen side/king size

(only when king is safe, no passed pawns stuff, no opposite castling)

- win/loss patterns based on passed pawns and kings and rooks positions

Visitors :