Are chess programs designed to win or to last longer?

Suppose you set a position on a chess program rated 3400, and you give it a complex middle game position where it is the computer's turn and it knows it can be checkmated in 14 moves. It is actually more of a mate in 11, but it can postpone it to 14 by putting its queen and then two rooks into the path of your bishop on the fisrt 3 moves.

Is the computer going to play the board and shoot for mate in 14, even though it would be easy for a person to beat it after that? Or would it play the opponent, and make sneaky moves to disarm the mate in case the human does not know how to get force it?

Do computers take risks because they know their opponent would have to play perfectly for 10 moves and decern between 6 other closely good moves each time to punish the move? Or do computers always play the safest strongest move on the assumption that it is playing itself (the board).

There is plenty to be gained from picking riskier high reward moves that only an expert could punish.

When I start a game without my queen and take on a novice, I don't develop my entire army with my opponent. I get 3 pieces out and launch flawed but hopeful attack against the king and hope my oponent does not know how to stop it.

I think if we had computing power for exhaustive computer depth, the computer should not play the board. Instead, it should pick variations where the human has many plausible looking but fatal alternatives to choose from, and must play perfectly 12 moves deep in order to punish the computer. With this approach, the computer could win games faster and start with less material. Sometimes playing just to last long is not the best option if the line is easier for the human to follow to its end.

Computers play the move they calculate gives them the best position. It may not be the best move but they don't play inferior moves because it gives them better practical chances because they don't understand what that means.

The engine Junior uses some sort of opponent modelling.  Of course it still uses minimax in its search pruning but in its selection of moves it chooses tactically interesting positions.

All engines I know would postpone the mate as long as possible, even if it would involve making a Queen sac that makes it a totally lost position on the first ply.

It is quite easy to prevent this, btw: a combination of making evaluation scores saturate (e.g. R+P ahead is hardly any better than R ahead, and Q+P vs Q differ even less, but the difference between equal and P ahead is much more, and making scores age (i.e. capturing a Queen deep in the tree is worth less than capturing it near the root) would lead to the desired behavior. If a mate in 14 would receive less score than winning a Queen on the next ply, the engine would refrain from the Queen sac. Even when the Queen sac would push any mate completely out of its horizon.

But as long as engines are optimized for playing against other engines, there is little chance we would see such behavior programmed into them.

Engines should make moves that have the highest probability of winning, not moves that prolong the game the most against a perfect player.

As for picking the move that leads to the "best" position, that is subjective and circular reasoning. How do we mortals know what the best position is?

I read a math article on this site saying there are maximum of about 4 million chess games possible, with about 10 million possible positions on each move from the beginning. It reaches steady state because of all the games that end. Most games end around 30 moves.

We need to take those 4 million games and start at the end and work backwards, making an arrow tree with minimax. That is the correct way. Starting at the beginning or assuming one position is better than another will only lead to an inferior engine, unless speed is a huge problem.

Here is the kicker though: The side that is forced to lose via minimax should not care about the number of moves it can prolong mate, but rather should pick moves that have the highest probability of switching to a win or draw if the currently winning opponent ever deviates from the propper minimax tree.

Finally, the engine should evaluate how often and how strongly its human opponent deviates from the ideal minimax path based on beginning to end, and should estimate how many moves ahead its opponent is able to see in order to think it is actually picking the right path. From that number of moves, the computer can play the opponent and not the board, winning the game sooner and appearing to be stronger than it actually is. And it can pick inaccurate moves which do neutralize its advantage completely, so that if the human does start playing perfectly again, the computer can still win but just much longer.

My suggestion would work great in a computer against computer competition where one of the computers actually evaluates each position but does not look all the way to the end of every game.

My computer would save some computing power by not needing to evaluate any games, but just looking at the final outcomes. If it evaluates them at all, it would be for the level of complexity to guess whether the human would be confused by it or know how to proceed, not to determine how strong the position is.

My engine would be mostly a database with arrows, and require very little computing power. Any computing power would be needed only for evaluating its competitior to determine if it can win faster with riskier play. The 200,000,000 or so positions could probably be saved on a 5 GB flash drive or portable micro USB device that could hook up to a phone. All the needed computing would be done before the game, stored in the arrows.

Solving chess is impossible at this point in time. Do you think that if they could they would have? 6 pieces is all they have solves so far. There are way more than 4 million possible games.

The irony.

You so sure he didn't read an article that was wrong without realizing it couldn't be trusted as opposed to simply making it up himself?  Could be he read it somewhere -- I know I just did.

You probably shouldn't make statements unless you're sure they're true.

The numerical values metioned by Aaron are ofcourse completely wrong. Even a 4-men end-game like KBNK has 16 million (64^4) positions (OK, many are illegal, but most are not) with black to move. The number of possible ways to play through those positons is astronomically larger. And that is then only KBNK.

But that does not alter the interesting point he raises much, and in the end-games simple enough that there is absolute knowledge about them in the form of tablebases (so roughly upto 6 men), it is not at all a hypothetical issue: If you are in a theoretically lost position, how can you maximize your chances for a draw against a fallible opponent, and, similarly, if the position is theoretically a draw, how can you maximize your winning chances?

Most current computers are really stupid in this respect. If they are in a draw position of KBPPKB with unlike B, they might sac one Pawn on the first move, another on the second, and the Bishop on the third. After all, KKB is also a theoretical draw, so any move is as good as any other, right?

Problem is that it is not so obvious how you can do better.You would have to know in which way your opponent is fallible. Some obvious strategies, such as doing that move that has the smallest number of correct responses (that keep the draw, say) and the maximum number of losing responses, do not work inpractice at all. It would for instance trade Q in a drawn KQRKQPPP, because there is only a single move (the recapture) that keeps the draw by converting to KRKPPP, while all moves that fail to recapture the Q (of which there are a lot) immediately lose.

Well, that would be great if you were playing a random mover, but of course every real opponent would recapture for sure. And a computer opponent would be more likely to have the smaller tablebase to which you convert, reducing your winning chances to an exact zero in the quickest possible way.

So you can't just count the number of good vs bad opponent replies. You have to weight them with the probability the opponent is going to play them. And this requires opponent modelling.

As for opponent modelling, I'd say if it involves recaptures, or combos that restore material within few moves, the probability of them seeing it should be assumed to be higher. That might even take precidence over the number of possible correct moves. But in some games positional is more important. I think opponent modelling works well for lower rated players. But to trick a GM, the computer would 1) need to look 8 moves ahead, and 2) have a very good way to evaluate all those positions 8 moves ahead, that or rate them more quantitatively by looking an additional 4 moves ahead. But either of those are well outside the realms of our computing power or storage capacities.

Programs today can reach 16 ply in standard time control, AaronSolt.  On my weak machine, the programs get 15 ply in about 15 seconds.  So that kind of computing power does exist.  (With sensible pruning techniques, of course, which you have said you agree with.)

What point would there be in making computers understand the shortcomings of human opponents, if they can crush humans anyway? Do you think there would be educational value in a seeing an engine playing hope chess (albeit very advanced) ?

James_Bond_Fan there could be spite checks while the winning king runs for safety, and then when it is safe the other king gets mated.

One way for opponent modelling would be to suppose his search depth is limited. So you could optimize by maximizing the number of lines that look good at, say, 8 ply, but lose at 9 ply. But this is still not very helpful if you have no idea how many ply you can think ahead.

Let's face it: to beat an opponent as quickly as possible requires completely different strategies, depending on how stong that opponent is. Amongst 6-year olds, hardly anything is as effective as shephard's mate.

i think he will play defensive, lowering the moves a little and attempting counterplay

I believe that Aaron is referring to something along these lines: http://www.chess.com/chessopedia/view/mathematics-and-chess, which means that he is stating the possible number of logical games to be around 4x10^6, which is arrived at by dividing the number of possible logical positions, which is estimated to be around 1.4x10^8 by the average length of a game, around 30 moves. This argument is flawed - how is this division justified - there is such a thing as transposition (and in many cases not just move order but move number) in chess? Never minding that, just what is this number, 4x10^6, that we have calculated? What does it actually represent? One assumption necessary (and on its own not even sufficient) for this calculation is that the variance of the length of chess games is zero, i.e. all chess games are precisely 30 moves long, which is patently ridiculous (think about four-move Scholar's Mate, to fifty-move plus struggles). Moreover, the 'tail' of long games cannot simply be casually dismissed (as they are in the article) - they actually come to a huge number of possible logical positions (which again throws into doubt the 1.4x10^8 possible logical positions). We can easily discern another problem with this method - by dividing thus, 1.4x10^8 different positions, by the average game length, we arrive at the result that all chess games form mutually exclusive sets!? What is the mathematical/chess background of the writer of the piece?

However, even if we can take the numbers as given, there is another problem - how long would it take to compute all these reasonably logical games? Furthermore, the 5 GB seems to be a gross underestimation - it requires around 1.2 TB for the Nalimov seven-piece tablebase, post-compression, whilst using a bitbase only approach is clearly infeasible. And just how much RAM would be necessary for the operation of the thirty-two-piece tablebase? In the region of YB?

Incidentally, a lot of people unfamiliar with chess engines actually seem to think that the engines are not calculating, but simply playing moves stored in its memory. Hence the OP's idea is not new, and not currently possible, else we would have solved chess already.