Author: scott farrell
Date: 22:32:15 01/09/04
Go up one level in this thread
On January 09, 2004 at 09:56:13, Robert Hyatt wrote: >On January 08, 2004 at 23:14:49, scott farrell wrote: > >>On January 08, 2004 at 22:29:58, Robert Hyatt wrote: >> >>>On January 08, 2004 at 21:30:16, scott farrell wrote: >>> >>>>I know there was a huge thread about the array being 32, I think it might only >>>>need 4. I also didnt read that howle thread, so someone can just tell me if you >>>>came to this conclusion already. >>>> >>>>Given the rules of what is in crafty: >>>>- minimax outcome >>>>- LVA - fixed ordering, must always use smallest first >>>>- king can take, and is scored as mate (or thereabouts if you capture) >>>>- currently crafty goes through all attackers, until on side has none, it uses a >>>>32 sized array to hold capture values, that are built up, and then minimaxed >>>> >>>>now that maximum score returned than can be minimaxed, is the whole piece you >>>>are capturing, any more and it will be minimaxed away. >>>> >>>>the minimum score is the piece being captured, less the attacking piece, >>>>anything less will be minimaxed away. >>> >>>Correct, that is the _largest_ score. But not the smallest. You could start >>>off taking a queen with the queen, then re-capturing with a rook, and so forth >>>until you win a pawn at the end. >> >>if say the move is QxP, the smallest score returned is going to be -8. If >>anything got smaller, it would be minimaxed away. Even if it followed with a >>bunch of other captures - and the sidetomove would in effect stand pat after the >>initial QxP so its doesnt get worse than -8. >> > >That's a lower bound. I need the _upper bound_. And, in fact, I don't >need the upper bound, I need the _exact_ win or loss or equality score >for the capture. > yes I understand it is a lower bound, I was making a point you can now the bounds before you start SEE. >I use this to order captures. -8 doesn't tell me a thing unless if I take >the pawn with a queen, my opponent recaptures and I have no more pieces to >take with. > >>> >>> >>>> >>>>I hope the 2 statements above are sound. >>>> >>>>The next part of my argument is I think you only 3-4 entries in the array, and >>>>you dont need to iterate all pieces, just the first 1 or 2 captures each >>>>(depending how you count them - and if you count the first one or not). >>>> >>>> >>>>after the initial capture, the other side either has a good capture, or they >>>>dont. To determine if there is a good capture or not, I dont see that we need to >>>>pile a nearly unlmited number of pieces on. The minimax could would need a >>>>slight tweak to disregard the last capture I think. >>> >>>Think about this sequence of moves to win a rook: >>> >>>QxQ RxQ RxR RxR RxR >> >>using my rules above, the least returned would be Q-Q=0 (ie. QXQ can never >>lose) , and the best would be then Queen=+9 (if say in the best case, nothing to >>recapture). > > >No, the score is +5. I am winning a rook. I am not winning a queen or >losing a queen. I play QxQ and you reply RxQ. We are even, but it is my >move and I choose to reply RxR. Now you are down a rook. Do you stand pat >or play RxR to even the score up again? You play RxR here, and we are equal >again. But I play RxR for the last time and you have no move to play. How >can you discover that without playing through the _entire_ sequence of captures >and then backing up the scores in minimax fashion? > again, I was commenting on the bounds before SEE is started. > > >> >>using my thinking, the RxQ capture is bad, but not nearly as bas as not >>capturing the queen, and it took 3 more captures to see that it was bad. > > >I don't follow. If you don't play RxQ you are down a _queen_. Afterward >you are only down a Q-R... > > we are saying the same thing here - using different words and a different view point. > >> >>the SEE minimax shows that ends up +5 for the rook. >>+9, +9-9=0 , 0+5=+5, 5-5= 0, 0+5=+5 >>it just happens to be the 2 captures each, how about >> >>QxQ RxQ RxR RxR RxR RxR RxR >>same +5 > >Yes, but how do you _know_ until you run out to the end of those >captures? That is why minimax is "depth first". > >> >>now if there are any bishops, they must go first > >Nope. A bishop can be _behind_ a queen. yes, but what I finally worked out, it doesnt effect the ordering unless there are 2 queens .. unlikely, or other strangeness that Sune/Uri pointed out. > >>QxQ BxQ RxB NxB >>+9, -9=0, +3=+3, >> >>.. that's getting too hard for my head, maybe I'll put a high water mark on the >>highest value in the array that ends up not being thrown away by minimax, and >>then run lots of postions through it. >> >>These things end up totally brain teasers for me. >> >>maybe the only savings to be had, is to once it gets into RxR RxR, remove equal >>numbers of rooks, but the hidden pieces might differ. >> >>I also noticed that the order of using sliding pieces, say rooks can matter, and >>crafty chooses them randomly. > > >It doesn't choose them randomly. It chooses the lowest valued piece first. In >every case. Once that piece is gone, it adds the piece behind that one if it >moves in the same direction so that it is among the set of pieces to be used >the next cycle, where again the smallest-valued piece is always used first. > my point is if there are 2 rooks which are both lowest, it chooses which rook randomly with pop/lsb/msb type rule. Given Sune and other showed positions where this is wrong, that is my point. > >> Say one Rook reveals no hidden attacker, and the >>other reveals a Rook, OR, one reveals a Q, and one reveals a R, this must surely >>have an outcome that would be different if you randomly selected the other rook >>to start with. > > >Stop and think about this for a minute. I have two rooks bearing on the >target, one backed up with another rook, one backed up with a queen. > >Suppose I choose to use the latter first, so after one cycle, I now have >a rook backed up by a rook and a lone queen. I choose the rook. Now I have >a rook and queen. Third try chooses the rook. > >There is _no_ randomness here. It is all very much pre-calculated to always >use the smallest piece first. > > > > >> or maybe there is no difference, as it is unlikely to be a >>smaller piece, which is the only case that upsets the apple cart. Larger >>revealed pieces dont change the order at all, they go to the end of the queue, > >That is correct. > > >>even reveals pieces (rook reveal rook) dont change the order either. A Rook can >>only reveal rooks or queen, bishops can only reveal bishops or queen, the queen >>is the only piece that can reveal smaller pieces, and it is unlikely to have 2 >>Queens in which that is the only case you can reveal a smaller piece. So the >>order of queens capturing is the only place where this can go wrong. > >It can't go wrong there. Smaller pieces get used before the queen, then the >queen, and _now_ the smaller pieces behind the queen. Minimax makes this work >perfectly too, otherwise our q-searches would always produce the wrong answer >when they don't. > >> >>Scott >> >>> >>> >>>> >>>>if we have a position that starts of pawn x pawn, we dont need to minimax >>>>through all the RxR and RxR QxR QxQ KXQ stuff to work out that somewhere adding >>>>in more captures will always be minimaxed away. >>> >>>Until you get to the _end_ and "minimax" your way back, how can you do that? >>>That is the definition of "minimax". "depth-first". >>> >>>> >>>>I need to think more on exactly the maximum number of captures is required, but >>>>I am sure it is way less than 32, no matter what is on the board. So I am saying >>>>instead of exhausting the captures for one side, make an early exit after a >>>>maximum of 2 captures each - or some other similar small number. >>>> >>>>Or I could be completely wrong. >>>> >>>>I might try coding it up both ways, and see if the answer ever differs. >>>> >>>>Scott
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.