Author: Peter McKenzie
Date: 13:47:52 05/05/99
Go up one level in this thread
On May 05, 1999 at 11:32:15, KarinsDad wrote: >On May 04, 1999 at 23:40:34, Peter McKenzie wrote: > >>On May 04, 1999 at 15:59:25, KarinsDad wrote: >> >>>On May 04, 1999 at 15:03:01, Dave Gomboc wrote: >>> >>>>On May 04, 1999 at 11:26:29, KarinsDad wrote: >>>> >>>>>I was wondering how deeply most programs extended the search at a given ply for >>>>>check. >> >>I extend one ply for giving check, always - there is no limit on this. I never >>extend more than one ply at a given node. > >I am doing the opposite. I extend whenever anything interesting is going on >(such as non-quiescence) almost as far as I can go. I then mark the >non-quiescent children nodes as being searched so that they do not get >re-searched (when I get to the next ply). I don't understand what you are saying. Whats this about marking non-quiescent children nodes? Sounds like you might be talking about quiescence search not extensions. I think we have a communication problem here. The common meaning of the word 'extend' is that you don't count the current node as increasing depth. So for example, say we are doing a 5 ply search from the start position and we go down the following line: 1.f4 e6 2.h4 Qxh4+ So you've gone down 4 ply, and therefore normally you'd have 1ply to go. But if you extend a ply for checking moves you wouldn't count Qxh4+ and therefore would have 2 ply still to search. Thats all there is to extensions, its just playing with the depth counter. Is that what you mean by extending? > >> >>>> >>>>Maybe a simple fixed multiple of the depth you are searching to is sufficient in >>>>practice. 2 or 3 or something. You could experiment to optimize it. There's a >>>>lot of useless checks sometimes, but there's often a correct sequence too. >>>> >>>>>I implemented singular extensions, check extensions, and capture extensions into >>>>>my code last night, but ran into the problem of check extensions potentially >>>>>expanding the extensions into near infinity. >> >>This is unlikely to be check extensions causing this. It will be check >>extension in combination with single response extention, see below. > >Yes, my main problem here is that I have not yet implemented my hash tree, so I >do not yet check repeats. Once I do that, this will get pruned a lot. That was >the first reason for my concern, however, if you have a king out in the middle >of the board and the opponent has a few minor pieces around, I could see where >the king could be checked a lot as well (and the checks may not be worth much). >The expense here would not be great, however, if I can prune it a little also, >that would be nice. > >> >>>> >>>>I believe it. :) Did you implement PV or FH singular extensions (or both)? >>>>Have you experimented with your margin at all yet? >>> >>>I do not understand these terms (if you could please explain them; I haven't >>>been doing this type of stuff for long). There are two types of singular >>>extension that I perform. The first is that of extending a move when it is the >>>only move available (real simple). The other is that of extending a move when >> >>This extension is what will cause your search tree to explode. While >>technically it is a singular extension, it is usually refered to as the single >>response extension because it is such a special case. It is ESSENTIAL that you >>limit this extension in some way. > >Thanks for the info. > >> >>>is significantly better than all of the other choices. The determination of the >>>significance varies in the search. Is this what you mean by margin? In any case, >> >>This is the real singular extension, it is notoriously difficult to implement >>(a) correctly and (b) efficiently. I believe there are a number of forms of it. >> >>One of the tough things is figuring out if a move is singular (better than all >>the rest). This typically involves actually searching the move (and all others >>at the node), and then re-searching the best move to a greater depth if it is >>singular. Is that what you are doing? That is pretty expensive. > >Yes, I am doing this. However, there are a few limits. I only do this for >quiescent nodes (non-quiescent nodes are extended due to check or capture). I >also do not do this if the scores returned by the non-quiescent nodes are not >lower scores as well. And, if I get I cutoff, I do not do this. > >[snip] >> >>How is your move ordering? Expect your nps to drop as your move ordering >>improves. > >I keep hearing this type of statement, but I haven't figured out the reason for >it. Could someone tell me the rational behind this? > >As to my move ordering, I have a sophisticated one in the design spec, but at >the moment, we have a simple one of pieces most likely to be moved in chess >first, other pieces later. The order is the same throughout the entire game (at >this point of the implementation). > >KarinsDad :)
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.