This page lists the available time controls and thinking modes:
- Time per move (seconds): minimal, 5, 10, 20, 30, 60, 120, 180. This setting is on average, i.e. the thinking time can be increased by up to 25% on individual moves.
- Game-in (minutes per player): 5, 10, 15, 20, 30, 45, 60, 90. The user can configure a factor between one and four for his thinking time. So you can play e.g. with 60 minutes for the player and 15 minutes for the computer.
- Tournament modes (moves/minutes+minutes): 40/90+30, 40/120+30, 40/120+60, 40/120,20/60+30.
- Analysis mode: 9 hours per move, interruptible.
- Mate solver mode: finds mate in 1-8 moves.
- Fischer delay (seconds): off, 10 s, 20 s, 30 s.
- Player bonus (seconds): off, 10 s. That is to make up for the time you need for entering the moves, independently from the Fischer delay.
In time modes “game-in” and “tournament”, the time countdown starts only after White’s first ply. That makes tournaments easier.
After loss on time, the game can be finished in “time per move” mode.
When the computer is thinking, it checks whether starting the next depth iteration makes sense with regard to the remaining time for the move. If not, it will save the time. In time modes “game-in” and “tournament”, this saved time will be used for the endgame, together with the time savings from using the opening book. In the more relaxed “time per move” mode, this will compensate for the computer occasionally requiring 25 % more than the configured time.
The thinking time countdown for the player to move is paused during dialogues, menu calls or viewing the position. While this allows for cheating the computer, it is also a convenient way to pause the game.
Displays the move number of the ongoing game; what is automatically being updated are evaluation, search depth, time to the current starting move of the principal variation, current thinking time and the principal variation with up to eight plies.
However, the evaluation is not geared to human play, but to get useful moves. With regard to the available strength of play, the principal variation is rather fine, but the absolute evaluation has to be taken with a grain of salt. Besides, the evaluation is partially asymmetric as to lead the engine to positions it can handle better.
Mate solver mode
Finds mate in 1 to 8 moves. While the search is in progress, the CT800 shows the configured search depth in moves and the thinking time. Maximum search time is 4 days, and the user can cancel the search. The solution is displayed as a move list in pretty print format. The CT800 can also look for possible alternative key moves in order to detect double solutions.
There are several hash tables implemented, 117 kB in total:
- Main hash tables: two tables of 4k entries (48 kB) each, one for each player. The game information stored is the evaluation, the kind of evaluation (upper bound, lower bound or exact), the associated search depth from the board position, and if available, the best move. The algorithm used for overwriting is “depth preferred”.
- The pawn hash table of 2k entries (20 kB): stores the evaluation for the pawn formation alone, along with an indicator whether it is a middle or endgame evaluation. Preferred rook files, derived from the pawn formation, are stored as well.
- The history of killer moves: 1.5 kB for storing decisive moves within the search, mostly for getting quicker search tree cut-offs in irrelevant lines. Technically, these are not hash tables, but they work in a similar way.
The idea is to save thinking time under time controls (not in analysis mode) and avoid annoying the user with unnecessary thinking:
- If there is only one legal move, the computer will do that without further thinking.
- If the computer can mate immediately, it will do so.
- If the computer cannot avoid being mated in the next move, it will stop computing and do some legal move.
- If the score drop between the best and second best move from the 3 plies pre-search is at least 200 centipawns and the best move is either part of the previous PV or the score is within a +/- 50 centipawns window from the previous position.
The position evaluation in these cases will be either the one of the principal variation from the turn before in case the player has been following it, or else from the shallow pre-search (one ply) used for sorting the moves. If there is only one legal move, but the player has not been following the principal variation, no evaluation will apply. In short, the computer will use the best data that are available despite the quick reply.
Pondering is not implemented, which renders it rather a non-feature. While pondering is not uncommon, I decided not to use it for a variety of reasons:
- There is not that much to be gained to begin with. Looking at tournament time controls and assuming that every ponder resulted in a ponder hit (i.e. the opponent always plays the expected move), this would effectively double the CT800’s thinking time. That would be equivalent to doubling the speed, which would yield a gain of around 60 ELO in strength, as a rule of thumb.
- The observed hits in the principal variation are a good measure for what ponder hit rate can be expected, and that is likely to be around 25 %. The major reason for that quite low hit rate is that forced moves or tactical manoeuvres are clearly shared because they are objective necessities – but in unclear situations, the unique playing style causes low hit rates. So the effective speedup factor would not be 2, but only 1.25, corresponding to a gain of about 19 ELO, which is not really significant at ELO 2100.
- The major drawback would be to nearly double the energy consumption, roughly cutting the battery running time in half. Currently, the system drastically reduces the clock speed when waiting for user input, which it could not do with pondering.
- The second drawback would be that the application coding would need two independent control flows since the strictly sequential one would not work any more. On the target platform, this would call for a small real time operating system. In turn, that would create a major gap between the code base on the target and the test/development version on the PC, thereby breaking one of the key features of the software.