Author: Gerd Isenberg
Date: 13:31:00 03/16/04
Go up one level in this thread
>>>>>>>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... Ok, i may find three positions too where some additional random move ordering results in similar smaller trees ;-) I believe in HH too, still use byte arrays with some degree of saturation. I count overflows for each color if 255. I age them by div two if some amount of overflows occurs. I use higher increment for mate threads if < 200. I use countermove or butterfly heuristic too and of course killers. With depth left > 3 i use more sophisticated move sorting. In my next generation approach i will try move-index in a range of about 0...4000 (quite moves per side) to distinguish not only between coordinates but pieces too. Curious about the infuence on HH with those indices. <snip>
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.