Author: Christophe Theron
Date: 17:59:45 01/25/00
Go up one level in this thread
On January 25, 2000 at 14:52:53, Robert Hyatt wrote:
>On January 25, 2000 at 13:28:33, Christophe Theron wrote:
>
>>On January 24, 2000 at 16:05:00, Robert Hyatt wrote:
>>
>>>On January 24, 2000 at 15:34:39, Christophe Theron wrote:
>>>
>>>>On January 24, 2000 at 09:10:12, Robert Hyatt wrote:
>>>>
>>
>>(snip)
>>
>>>>I'm really curious about this. Using a SEE to "close" the search is in my
>>>>opinion a beginner's mistake (no offense intended).
>>>>
>>>>It's the first thing I have done myself when I started programming chess, and I
>>>>suspect many of us have followed the same path.
>>>>
>>>>But if somebody tells me it really works, then I have, once again, to reconsider
>>>>seriously all I know about chess programming.
>>>>
>>>>It's not new anyway. Every now and then I realize how little I know. That's part
>>>>of the fun.
>>>>
>>>>
>>>
>>>
>>>Good question. I did this around 1972 or so, and found it was a great addition
>>>since I couldn't afford a q-search at the speed of 10 nodes per second or so. I
>>>too dropped this around 1978 when I went "full-width + q-search" to become yet
>>>another "clone" of chess 4.x after the Frey book came out.
>>>
>>>I'll let the 'author' of the suspected non-q-searcher speak up if he wants,
>>>to avoid starting a long "did, did not, did too" type discussion. I am not
>>>sure it is totally bad with a decent search in front of it. When I did it I
>>>was doing a 4-5 ply selective search. It was ok. I went to a 4-5 ply full-
>>>width search. It was not ok after that. Maybe after 13-14 plies it is OK
>>>again?
>>
>>
>>I think the SEE idea is not good because on deep searches the QSearch typically
>>is very quick, looking at a very reduced number of nodes in average (maybe one
>>or two nodes is enough in most cases).
>>
>>If your make/unmake move and evaluation is fast enough, this is going to be much
>>faster than using a SEE in this position. Because to be reliable a SEE has a lot
>>of work to do (bitboarded or not).
>
>
>Maybe or maybe not. I have not (personally) given it any thought, and don't
>plan on doing so. I used it a long time ago (20+ years) to see if the _last_
>move in the tree was safe or not. With a fixed depth (more or less) search,
>the last move was always suspect, as it would be a capture of something where
>there was no way to recapture since the search had maxed out. SEE could make
>sure that you weren't planning on winning a pawn, just to lose the queen or
>whatever. I didn't do it on _all_ my pieces, just on the one moved at the
>final move in the PV.
>
>I suppose you could do something more clever... as SEE is way faster than
>any sort of tree search, if done as I did above... IE my SEE code takes
>less time than it does to recursively call search, generate moves, etc...
I have tried for many years to have a fast enough SEE, but I did not succeed...
Basically, a SEE has at least to identify which pieces can make captures, which
is already close to generating captures. The capture tree virtually "searched"
by the SEE is degenerated, but in order to overcome several problems (pieces
alignments or pins for example) you actually have to do a lot of work.
Just because I did not succeed doesn't mean it's impossible, but...
>But if I tried to do it for several pieces, I think it would be too slow.
That's what I think too.
>>Another thing is that a QSearch is more accurate than a SEE. Being accurate is
>>important, because it makes your tree smaller. If your SEE is wrong often
>>enough, then the next ply depth is going to have some extra work to do because
>>the last time you have found this position (a position near the horizon) you
>>actually did not find the best move. Your move ordering near the horizon is less
>>good with a SEE, and this is expensive.
>>
>>I have actually found several cases in my program where looking at a bigger
>>potential tree was actually faster than trying to reduce the potential tree.
>>
>>Very often, an algorithm that has a bigger potential tree runs faster than a
>>reduced potential tree algorithm, because it extracts more accurate information.
>>And when you go to the next ply depth, the accurate information is extremely
>>efficient.
>>
>>The most interesting example for me is that without QSearch my program is much
>>slower (and of course less accurate).
>>
>>Search+QSearch has a bigger potential tree, but is far better (and actually
>>faster) than Search alone.
>
>maybe or maybe not. remember that one program is apparently doing this and it
>is _very_ strong. That is the only reason I gave it even a minute's thought
>in this discussion, as it is working for someone...
I'm surprised, but why not after all.
I hope Amir can tell us if it is Junior or not...
Christophe
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.