Author: Bas Hamstra
Date: 13:40:57 11/22/98
A few qestions for the more experienced:
First a short explanation of what I am doing. I made a movegenerator that
generates 1 move at a time. My board is such that each square contains a 32
bit field that indicates by which (uniquely identified) pieces of both
colors that square is attacked. Example:
A square that is attacked by all pieces would hve all attack bits set as
follows:
KQRRBBNNPPPPPPPPkqrrbbnnpppppppp = 32 bits
During make/unmake I incrementally update the attacks. To get the first
capture, I get look at the most valuable enemy piece and with LastOne I get
the least costly attacker. It works ok so far.
Further:
- simple alpha beta
- qsearch
- only material eval (also incremental)
- Move order is a) Caps, sortof MVV/LVA b) Killer c) Rest
Thats about the whole program now.
Now the questions:
1. During iterations the NPS count varies wildly. Look at this (ply
iterations for the SAME position):
ply 7: 106.000 NPS
ply 8: 43.000 NPS
ply 9: 93.000 NPS
ply 10: 40.000 NPS
Note that I *reset* the node counters for each iteration. Why in the world
is the NPS at odd plies twice as high??? My profiler indicates most time is
spent in updating attacks during make/unmake.
2. When I play a few more moves on the board, the qsearch explodes, up
till 300% of normal nodes. How can I prevent that?
3. According to Vincent Diepeveen incremental movegeneration=good idea
BUT incremental attack updating=BAD idea. Would NPS go up if I did *not* do
attacks incrementally during make/unmake?
Thanks in advance,
Bas Hamstra.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.