Author: Robert Hyatt
Date: 06:56:13 01/09/04
Go up one level in this thread
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. 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? > >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... > >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. >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. > 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.