Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Move Ordering

Author: Miguel A. Ballicora

Date: 20:15:41 12/26/02

Go up one level in this thread


On December 26, 2002 at 10:55:55, Robert Hyatt wrote:

>On December 26, 2002 at 01:34:46, Miguel A. Ballicora wrote:
>
>>On December 25, 2002 at 15:18:29, Robert Hyatt wrote:
>>
>>>On December 25, 2002 at 10:46:17, Dieter Buerssner wrote:
>>>
>>>>On December 24, 2002 at 23:05:09, Robert Hyatt wrote:
>>>>
>>>>>[...] Why don't you go read Knuth/Moore's paper on
>>>>>alpha beta.  There you will find that move ordering does _not_ affect the
>>>>>final score, only the size of the tree.  Something every senion-level computer
>>>>>science student should know.
>>>>
>>>>I think, in most modern chess programs, move ordering can affect the final
>>>>score. Reasons can be extensions/pruning/hash tables.
>>>>
>>>>Regards,
>>>>Dieter
>>>
>>>If move ordering affects extensions or pruning, _something_ is broken.  As
>>>that violates the basic premise of alpha/beta...
>>
>>I am really surprised by this statement. Any pruning or extension that depends
>>on alpha will be affected by the move ordering. With different move ordering,
>>the same position might face different bounds, hence, different extensions could
>>be triggered.
>>
>That is the point.  Do you want to find something by serendipity?  I don't.
>I want consistent behavior every time.  And if something is dependent on move
>ordering, it is dependent on luck.  IE do you overwrite a position that
>eliminates a hash move which eliminates an extensions?
>
>_not_ a good design, IMHO.

Don't you have any pruning/razoring/extension method that depends on the value
of alpha? Hard to believe that any modern program has not any of those.

Miguel


>
>
>
>>>
>>>Hashing _can_ cause quirks, but it actually is more important to search _worse_
>>>moves first and then graft those search results on to better searches.  That is
>>>how we solve fine 70 faster than we should.  If the tree were ordered
>>>perfectly it takes 26 plies, period...
>>
>>IMHO, faster in plies does not mean faster in nodes (time). With terrible move
>>ordering you could solve a position in less plies but it could be in more nodes
>>than with good move ordering.
>
>
>I am talking time to solution.  Fine 70 takes 26 plies with perfect move
>ordering.  Most solve it at a considerably shallower depth, and there are no
>extensions whatsoever to help, so it is simply an artifact of hashing.  And
>the only way hashing can help is as I explained earlier...
>
>
>
>
>>
>>Miguel



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.