Author: Uri Blass
Date: 03:45:16 08/24/03
Go up one level in this thread
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. Uri
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.