Author: Robert Hyatt
Date: 21:57:08 12/26/02
Go up one level in this thread
On December 26, 2002 at 23:15:41, Miguel A. Ballicora wrote: >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 > I don't do any razoring or any extensions based on alpha, so no. Pruning in the q-search is done, but that is all. > >> >> >> >>>> >>>>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.