Author: Koundinya Veluri
Date: 05:07:57 10/16/01
Go up one level in this thread
On October 15, 2001 at 13:09:16, Dieter Buerssner wrote: >On October 15, 2001 at 04:28:42, José Carlos wrote: > > >> In Averno I haven't seen this problem yet. I simply order queen promotion >>before other promotions. > >I do the same. And, I usually do not see this problem. But I have seen it. > >>So if the promoted piece is taken, the different lines >>will lead to transpositions and be quickly discarded. In the lines where the >>piece is not captured, the line with the queen on the board will yield the best >>material score. >> Then I don't understand how this can be a problem is move ordering is correct. > >I feared, that I failed to express myself clearly ... > >First, this may all depend on many details, including the replacement scheme >used for hash tables. Of course, when we get a hash hit immideatly after a >capture of the promoted piece, we will get the same score for the different >promotion pieces. If not, we start to search. But now, we search the tree with >a differently filled hash table. And in general, we will search a different >tree, because of this, and we may get a different score. (Similarily, many >programs find the solution at different search depths for Fine 70, when the HT >size changes). It may be, that we get a hash hit later, that cuts off the tree, >that really has more depth than needed. I think it is obvious, that this can >change the score. > >Another thing are path dependent extensions, for example recaptures. We get a >cutoff for the same position, but if we would search, we would use different >extensions (depending on the last move(s)), and therefore get a different score >and/or PV. One may be able to fix this, by storing some path information, but I >guess nobody does this consequently. I actually tried, but it only worsens >things, because the HTs get less efficient. > >Other examples (50 moves rule/repetition) or discussed in Dennis Breuker's >thesis under GHI (graph history interference?). I think, a link is available at >the "CC recsource center". > >Then, in general we will start to search e8Q and e8B with different windows. >This can yield in different pruning/extension decisions. > >I think, this is very related to the problem, of failing high in zero window >search, and a later fail low when searching the same depth with a wider open >window. I think it is just unavoidable, when not using some plain alpha-beta >search without HTs. Funny you mentioned this, I started noticing this fail high / fail low problem only recently. I found that this doesn't happen when null move is turned off. When I traced some positions, I found that on the re-search, null move cuts off at a certain depth where it didn't cut off on the zero-window search. I thought it was just a side affect of null move. Koundinya > >Regards, >Dieter
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.