Author: Omid David Tabibi
Date: 04:12:01 08/24/03
Go up one level in this thread
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? > >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.