Author: Pat King
Date: 13:15:49 04/01/04
Go up one level in this thread
On April 01, 2004 at 07:45:19, Bernd Nürnberger wrote: >On March 31, 2004 at 19:49:22, Pat King wrote: >>a) I sort all quiet moves by the history table. It's probably a waste, but it's >>simpler. > >Doing this strangely I get even more nodes (and still another different PV) >on the starting position: > 8. 0:01.38 1169525 0.00 d4 Nc6 e4 d5 exd5 Qxd5 Nf3 Be6 >(?!) >Why does the amount of nodes go up, when the ordering should be better? >I am aware of that the heuristic is just a prediction that do not have to >be true, but should the prediction not be more accurate? >What parameters for increasing score (+ 1<<depth) and aging (at 64k nodes >do /8 on all from-to pairs) do you propose? The lower numbers in the history table are probably considerably aged, and so perhaps somewhat random. So your ordering may actually be worse for doing the full sort in this position, and maybe better in some other position. In Zotron I age before the start of each search, merely dividing each entry in half. Based on this discussion, I now understand why many divide by 8 -- it zeros out a lot of entries that might just be screwing up the ordering. > >>b) If I chose to limit my sorting (which quite probably is a good idea) I >>wouldn't make decisions based on the starting position. Very few (I would say >>"no", but I always get in trouble with absolutes) chess engines are any good at >>openings with a pre-made "book". >That was just an example to illustrate. Propably the starting pos. is a bad >test pos., but I also tested other positions ... > >>The two lines you present are not unreasonable for a chess engine with no book. >But is it reasonable that they are so much different for just sorting *one* >more move by history score. It varies very widely when altering move ordering! >Is this ok? Again, based on this thread, I'd say yes! > >> >>> >>>(2) >>>[move ordering] >>You mention that you've implemented null move. I believe the proper place to put >>this is before even your hash move. This could seriously impact your cut rate. >>If you're not counting null move cutoffs as 'cuts', then I think you may have an >>apple and orange type problem when you compare yourself to other engines. >Strangly this do not change anything in my engine. Will try this more thourougly >when I have more time. But why do the null move before hash table lookup. >Isn't it cheaper to place it after the hash lookup, because if I got a >hit (and I often got hits), null move will not be examined at all?! First examine the hash score, and if it allows you to, return right away doing no further search. Next try null move, which searches to a reduced depth. Then try the hash move, which requires search to full remaining depth. > >>Glad to shed what feeble light I have on your problems :) >:) > >Greets, 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.