Author: Gerd Isenberg
Date: 00:17:24 08/27/04
Go up one level in this thread
On August 26, 2004 at 19:25:01, Lance Perkins wrote: >I'm aware of the aparent advantages in cut-off situations. What I was hoping for >is that someone has the statistics that show that it is significant and worth >the effort to do. I guess we are talking about a one percent range or even less. > >If someone already has the numbers, I don't want to have to write-up the code >just to prove it mysef. > >Stuart seems to have actually made the comparison, and found no advantage >whatsoever. I suppose it is due to a better move ordering when you actually have >all the moves to compare and sort (this is the same claim that Ed makes with >Rebel). > >I'm in no hurry to bloat the code for a minor gain. Yes, one has to avoid bad move ordering due to partial generating. With rotated bitboards looking for hashmove, obvious winning captures like pxQ and killers is fine and don't requires much additional memory and bookholding overhead for partial generating. A few additional rotated lookups to get attacks for captures and quite moves on the fly is not much overhead. If one generates attacks and move bitboards considering pinned pieces with fill-algorithms, it might be smarter to generate all moves too, to avoid too much multiple work and/or blowing up ply indexed, recursive used memory, like keeping additional movesets in bitboard metrics. Another pro for generating all moves might be possible interactions/sideeffects with eval. Gerd > > >On August 26, 2004 at 17:42:31, Gerd Isenberg wrote: > >>On August 26, 2004 at 16:25:07, Lance Perkins wrote: >> >>>After seeing the posted NextMove code, I wonder how much better this is than >>>simply generating all the moves and then sorting them in one go. >> >>It depends on the design of the engine. >> >>In general it is a good idea to delay as much as possible and hope for an early >>cut. Beside hash or pv move, you often cut with winning captures, only >>generating them seems to make sense. Probably same for generating/trying >>killers. >> >>With classical board presentations, traversing the board in one direction with a >>sliding piece, it might be better, to generate quite moves on the fly into a >>separte move list, while looking for capture targets. Of course there is some >>waste of memory write cycles if generating all and early cutoff. >> >>Anyway, after hash/goodCaptures/Killers/EvalHints it might be the best to >>generate all remaining moves (captures, checks, winning double attacks) and to >>assign history/psq or whatever scores to them to pick the next best. >> >>With my current finite state movegen i delay/skip generating piece >>captures/moves to squares attacked by opposite pawns or other negative SEE >>values. >> >>With bitboards one may even keep legal move target bitboards, piece or direction >>wise. So you have an idea of the number of moves or stalemate without >>serialising moves into a list. >> >> >>> >>>This code is a little to complex and tool long for my liking, but if it offers a >>>very significant gain, maybe I should give it a second look. >>> >>>I can immagine that when one gets a cutoff, the rest of the moves don't have to >>>be generated (captures vs non-captures). However, in leaf nodes, one is very >>>likely to generated all the moves anyway. >> >>Leaf nodes, if not hash hits or repetitions, are eval cut nodes or stand pat >>nodes with no or only (bad) pruned captures because of eval+gain < alfa. The >>first one needs no generated moves at all the second only captures. Pruning >>might already considered during movegen. >> >>Simply use some counters and do some statistics. >> >>Gerd >> >>> >>>Has anyone compared these?
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.