Author: Bernd Nürnberger
Date: 05:10:21 04/03/04
Go up one level in this thread
On April 03, 2004 at 06:17:57, Vasik Rajlich wrote: >On April 02, 2004 at 07:19:40, Bernd Nürnberger wrote: [...] >> >>Maybe I did the killers wrong. I did two for each ply, and for every >>beta cutoff, I move killer2[ply] to killer1[ply] and overwrite killer2[ply] >>by the move, causing the beta cutoff. > >Yes, that's correct. > >Actually, I put the new killer move such that it is the first one. (Ie chosen >first during subsequent move generation.) Intuitively this seems slightly more >correct, but I haven't tested this and it really shouldn't matter much. I put back killers now into my engine, and they indeed helps -- to less or more account depending on the position (that's clear ...). I will also try some experiments with the idea I read in another thread: also take killer[ply-2n], killer[ply+2n]... [...] >I think this also depends on the speed of your engine. The faster your engine, >the less time you should spend on move ordering. (More generally, the faster >your engine, the less time you should spend on everything.) I am not sure about this. A small improvement in move ordering is often a very large improvement in speed. But details are nethertheless dependent on the engine. btw. With a small eval function (pc values, pc-sq values, castling), my engine uses about 2000 clocks/move. Hopefully it will not drop to much with a more sophisticated eval (the things now can all be done incementally) ... but after all, I am using Java and therefore it runs really fast IMO ... >>Maybe I should try to do killers before even or bad captures, as you propose. >>I will test it, as soon as I have some SEE function implemented. Right now >>I am doing a MVV/LVA ordering, so I cannot clearly say: what is an even, >>what is a bad capture and the ordering itself does not do clear cuts here >>either. > >Bad captures and moves which allow the opponent good captures should definitely >go at the bottom of the list. The question is whether it's worth the computation >to put them there. I am pretty sure, in most cases it is worth the computation. I just added some plain vanilla internal iterative deeping, which *really* consumes much time because doing a complete depth-2 search - the results were positive as far as I can say this after just implementing it ... Greetings, Bernd
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.