Author: Uri Blass
Date: 04:52:42 08/24/03
Go up one level in this thread
On August 24, 2003 at 07:12:01, Omid David Tabibi wrote: >On August 24, 2003 at 06:45:16, Uri Blass wrote: > >>On August 24, 2003 at 06:35:45, Omid David Tabibi wrote: >> >>>On August 24, 2003 at 05:11:48, Sune Fischer wrote: >>> >>>>On August 24, 2003 at 02:27:59, Omid David Tabibi wrote: >>>> >>>>>On August 23, 2003 at 19:55:31, Sune Fischer wrote: >>>>> >>>>>>On August 23, 2003 at 19:35:22, Omid David Tabibi wrote: >>>>>>>> >>>>>>>>Yes you can do that, if you don't need to know where the attacks came from. >>>>>>>> >>>>>>>>It won't be a super accurate SEE, for how do you do x-ray attacks using that? >>>>>>> >>>>>>>And how do you do it accurately using your 32 bit per square scheme? >>>>>>> >>>>>> >>>>>>You get the map of "primary" attackers by the lookup, I still scan behind them >>>>>>the most primitive way to see if there is x-ray attackers. >>>>> >>>>>But how do you incorporate that x-ray attacker with the lookup's result? You >>>>>cannot just add its value to the lookup result... >>>> >>>>Like Uri suggested you can first check if the square of the attacker is attacked >>>>by a sliding piece, if not no need to look behind it as it can't expose >>>>anything. >>> >>>Sure, but what do you do if you find that an attacker is attacked by a sliding >>>piece? How do you incorporate that attacker with the lookup table's result? >>> >>>For example, there are a number of attackers who attack a square, and a number >>>of defenders; the lookup gives the value -3, i.e., a losing capture. Also assume >>>that there is an x-ray queen behind one of your attacking pieces. How do you >>>incorporate that queen into that -3 value? >>> >>> >>>> >>>>BTW gave some more thought to the squares vs indices table. >>>>It dawned on me, that a square table would not need twice the space but four >>>>times the space, it would be 64x64 rather than 32x32. >>>>There might also be a problem keeping track of the pieces with the square table, >>>>the pieces have a tendency to jump around so you'd never know where their attack >>>>board was and it would be complicated to xor out with the old one. >>>> >>>>Giving each piece a permanent ID-tag makes it easier to track that idividual >>>>piece, ie. where was that piece 5 moves ago, has it been an active piece... and >>>>so on. >>>> >>>>>>I just don't see a quicker way, do you? >>>>> >>>>>Maybe ignoring x-ray attackers altogether?! After all, quiescence search is all >>>>>about inaccuracies, isn't it? (disclaimer: I have not tried this idea yet :) >>>> >>>>If it was just for move ordering I wouldn't question it for a second, but can >>>>you still cull the losing captures using this? >>>>It seems to me it would be wrong very often. >>>> >>>>I also don't fully agree that qsearch is all about inaccuracies, think about it, >>>>all branches terminate in a qsearch, so everything sent down the tree must be >>>>garbage....? >>> >>>Until a while ago at least, Junior did not have any quiescence search at all... >>> >>>Besides, even an "accurate" SEE isn't accurate at all: >>> >>>[D]3r2k1/pp1n1ppp/2p2q2/8/2PR4/2B5/PPQ2PPP/6K1 w - - 0 1 >>> >>>SEE will deem Rxd7 a losing capture, while it's actually a winning one. If you >>>want a more accurate quiescence, use MVV/LVA. >> >>I think that it is dependent on the SEE that you define. >>I do not think that you can generalize about SEE and I believe that there are >>programs that are going to find that Rxd7 is not a losing capture in their SEE. > >It is possible to find it, e.g., look at all attackers of any piece you move and >see if they attack a new piece. However, I'm afraid it will be too costly... > >If Junior can forgo the quiescence altogether, why can't the others do some >concessions in the queiscence? I found that checks in the first plies of the qsearch made movei better so I believe that it is better to add more moves to the qsearch and not to throw moves from it. I am not sure if Junior really had no qsearch. It had no problem of explosion of the search at small depthes but the reason can be different(for example limiting the depth of the qsearch in the first iterations) I also do not believe that other programmers should do the same as Junior. I think that Junior searches too many nodes per second. Amir is a good programmer so he could develop a strong program inspite of that handicap that limit Amir's possibilities in the evaluation and in the search. Uri
This page took 0.01 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.