Author: Severi Salminen
Date: 04:25:29 03/09/01
Go up one level in this thread
On March 09, 2001 at 01:47:53, Matt McKnight wrote: >That's a good idea. I haven't tried that yet, and I think that I didn't >communicate what I was trying to do with this idea. > >I'm only keeping two moves to play at the very end of the list, because in the >last search they were the lowest failing moves. I'm hoping that I will not get >to those two bad moves. > >Is this any good, or should I scrap it? It seems to give me fewer nodes/ply. In that case it is good if it does not slow you down? Are you reaching new plies faster or slower? Have you measured the quality of your move ordering? Try this one: count the number of fail highs you get in the whole search _with the first move tried_. Then divide this with the number of _all_ fail highs. Calculate a number that includes qsearch and a number which does not include and post the results. That will tell you something. I'm doing about 90-95 usually (including qsearch). This is without hashtable moves. I'm using: PV, SEE, killers, history. I also understood that you don't do SEE at all. It is worth trying: you can put all "likely" losing captures to the end of move list and this will improve your search tremendously. Especially qsearch as you can stop searching if eval(node)+SEE(move)+MARGIN<=alpha or if SEE(move)<0. This will cut trees a lot - but also slow things down. But with longer time controls/faster hardware this definitely pays off. Severi
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.