Author: Robert Hyatt
Date: 11:48:14 03/16/04
Go up one level in this thread
On March 16, 2004 at 13:52:21, Mridul Muralidharan wrote:
>On March 16, 2004 at 13:06:34, Robert Hyatt wrote:
>
>>On March 16, 2004 at 12:41:55, Sune Fischer wrote:
>>
>>>On March 16, 2004 at 12:30:42, Robert Hyatt wrote:
>>>
>>>>On March 16, 2004 at 12:04:22, Sune Fischer wrote:
>>>>
>>>>>On March 16, 2004 at 11:25:55, Vincent Diepeveen wrote:
>>>>>
>>>>>>On March 16, 2004 at 11:19:17, Renze Steenhuisen wrote:
>>>>>>
>>>>>>I principally agree with GCP here. I do not understand how in certain software
>>>>>>HH can work. Must be a bug in their move ordering IMHO.
>>>>>
>>>>>If you can't make them work, why do you reply to his post?
>>>>>
>>>>>-S.
>>>>
>>>>
>>>>Ignorance. Unabashed ignorance...
>>>>
>>>>What else?
>>>>
>>>>HH works just fine. Of course if Vincent can't get them to work, then it is
>>>>impossible that they will work for anybody. "proof" enough??
>>>
>>>Yes, and this time the poster even gets to contact him personally for more
>>>information on how NOT to make them work!
>>>
>>>I admit I can see his point, precious secrets _like that_ are not to be posted
>>>in a public forum :)
>>>
>>>-S.
>>
>>
>>none of his "precious secrets" should be posted...
>>
>>:)
>
>Just try this - after the end of a 3 min search from a fairly complicated middle
>game position (like for example - Nxh6 nolot position) , print out the history
>values.
>
>You will see the junk that is contained in the table.
Do you understand what this "junk" means???
I don't see how it can be called "junk". The data simply reflects how useful
each move was in the search done.
>
>If you seriously expect much of information to be obtained from this for move
>ordering - I dont know what to say.
I feel the same, except in an inverse way.
History works for me. Turn it off and the tree gets bigger. A couple of
samples:
nodes w history nodes wo history
pos1 38,151,984 42,728,175
pos2 167,685,660 184,874,107
pos3 81,663,363 124,704,814
Now if you believe those three randomly chosen positions are worse because of
"random junk" feel free. The tree size is _remarkably+ smaller on pos 3, and
significantly smaller on the other two...
>
>I like some other mentioned here though - clear it x number of ply or y number
>of seconds - helps to reduce the randomness.
Why would I want to do that? This data is useful all over the tree. This is
the very idea behind it. Killers are local. History is global. Use both.
>Also Ed's idea is also somewhat better.
>
>I have not tried these , so cant comment - but helps in localising the effects
>to a smaller subtree where the tables could be potentially more relevent.
>
>But essentially , history tables in the general sense will detreriorate into
>random move ordering quiet soon for higher depth when number of nodes increases.
Then explain how my "random move ordering" is way more efficient. You are not
understanding what goes on in the history heuristic within the tree...
>
>Is that one of the reasons why you sort and try history scores for only first n
>(i think 4) number of history moves in crafty ?
Nope. It is for efficiency. at ALL nodes ordering is irrelevant. If, after
the hash move, good captures, two killers, I can't get a cutoff on one of the
first four history moves, I give up as I probably won't get a cutoff at all.
>
>Maybe this could be an optimisation reason also - i dont know.
It isn't anything but performance based...
>
>But if there is a possibility of hitting a better move earlier on using history
>tables , then shouldn't crafty not be trying it for all the moves ? - the gain
>could be potentially exponential in case of earlier cutoff !
I _do_ try it _everywhere_....
>
>Mridul
This page took 0.01 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.