hgm wrote:I guess I should only take an easy move if the score is close to equality. If the easy-move margin is 300 cP, choosing between a move that scores 500 and a lot of others that score ~200 cP is a real choice, as the latter are still winning. Playing the 500 cP "blindly" could bungle the win, when deeper searched would have revealed the move to be poisoned, while +200 would still have easily won.
I think it's safe when not taken to extreme - but the primary consideration should probably be that the same move was maintained for several iterations. You should probably use a non-linear function for determining how easy a move is based on score so that the effect is very weak if the score is close to zero.
But it's clearly annoying to wait for 3 minutes for a move when the program is over a queen up. Same when losing. Against humans it's actually a good strategy to play quickly when losing as that will sometimes cause the opponent to also play quickly and perhaps even blunder. It's also socially more acceptable that if you don't resign in a dead lost game you should at least play quickly.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
I prefer to be conservative with easy moves. Often the easy move is the right, but sometimes it is not. And your ELO is more determined by your 1% worst moves than anything else, so better safe than sorry.
What worked in testing for me is simply to half the time limit, so long as the best move is one with a SEE > 0 (typically a recapture). For example let's say the the time allocation routine returns 10 seconds, then if after 5 seconds the best move is still an easy one (SEE > 0) then we stop at 5 seconds. But we still search 5 seconds to leave enough chance to the search to find other choices.
This is quite conservative, but it worked in my testing: note that I do not use pondering, and there is the "give opponent free thinking time with a guaranteed ponderhit effect" that HGM was talking about in pondering.
I will probably improve this at a later stage (my time management code is very simplistic, but it's also robust which is better than complex and broken). But I need to implement pondering first, and it needs to be implemented in cutechess-cli too, so I can measure this "pondering effect".
PS: Another type of easy move is a forced move. If there is only one legal move, play it instantly. This may seem obvious, but many amateur and even good engines forget to do that...
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
hgm wrote:Well, I am looking more for thinking-time reductions of a factor 5-10, in positions where all moves except one have a losing score (say < -700, in terms of normal Chess).
My 60% lower bound was found by testing/tuning. Going lower starts to hurt. Which leads to the obvious conclusion that the current approach is quite "coarse and inaccurate". Reducing the move time by 40% can save time, and doesn't tactically kill things. So that when a "not-so-easy-move" appears to be easy, the time is not reduced so far that it hurts too often...
These things are not "big elo gains." I think that if a program has the potential to use far too much time on some moves, this helps more. I have always been conservative on time allocation, so moving even quicker is not a big saver. If your program regularly hits 2x the target time or beyond, it will likely help more...
hgm wrote:Well, I am looking more for thinking-time reductions of a factor 5-10, in positions where all moves except one have a losing score (say < -700, in terms of normal Chess).
Komodo uses a scheme similar to Bob's but takes node counts of moves into consideration - and it can play very fast. So you can make it play as fast as you wish. However you could also easily allow iteration score to be a factor, perhaps speeding up even more when the score is not close to zero.
Don
I could not find anything useful with node counts. They almost look like random numbers. I even removed the inter-iteration ordering based on node counts and actually gained a small elo boost by keeping old best moves near the top of the list, rather than sorting by node counts...
Seems that the reductions and pruning simply play hell with counting nodes for me.
lucasart wrote:I prefer to be conservative with easy moves. Often the easy move is the right, but sometimes it is not. And your ELO is more determined by your 1% worst moves than anything else, so better safe than sorry.
What worked in testing for me is simply to half the time limit, so long as the best move is one with a SEE > 0 (typically a recapture). For example let's say the the time allocation routine returns 10 seconds, then if after 5 seconds the best move is still an easy one (SEE > 0) then we stop at 5 seconds. But we still search 5 seconds to leave enough chance to the search to find other choices.
This is quite conservative, but it worked in my testing: note that I do not use pondering, and there is the "give opponent free thinking time with a guaranteed ponderhit effect" that HGM was talking about in pondering.
I will probably improve this at a later stage (my time management code is very simplistic, but it's also robust which is better than complex and broken). But I need to implement pondering first, and it needs to be implemented in cutechess-cli too, so I can measure this "pondering effect".
PS: Another type of easy move is a forced move. If there is only one legal move, play it instantly. This may seem obvious, but many amateur and even good engines forget to do that...
Like anything else it's always a matter of good balance. If you speed up your program by 5% you will get several ELO for it. So you can pay for that extra performance by playing just a couple of moves faster than others. If you can cut 2 moves down to half time, you have bought a nice speedup for the other moves. Of course, as you say, it does come with some risk so it is well worth exploring the trade-offs.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
Don wrote:I think it's safe when not taken to extreme - but the primary consideration should probably be that the same move was maintained for several iterations. You should probably use a non-linear function for determining how easy a move is based on score so that the effect is very weak if the score is close to zero.
The code I posted respects that condition, and is even more skeptical. Not only should the best move from iteration 4 on stay best, but it should stay best by a wide margin (corresponding to the loss of more than half a piece). If any other move is closer, let alone if it supercedes it, then it is no deal.
But it's clearly annoying to wait for 3 minutes for a move when the program is over a queen up. Same when losing. Against humans it's actually a good strategy to play quickly when losing as that will sometimes cause the opponent to also play quickly and perhaps even blunder. It's also socially more acceptable that if you don't resign in a dead lost game you should at least play quickly.
I do not iterate more than the distance to mate. Fortunately in mini-Shogi, once you are a piece down (actually two pieces, because the opponent then acquires it) there is usually only a few moves before mate gets within the horizon.
I just changed my time management that the program starts thinking longer if it is wildly ahead or behind (but has not found a mate yet) in sudden-death games, because the estimated remaining number of moves in the game goes down then.
