The move decision in Handtalk is mainly based on static evaluation. In the earlier versions up to 1994, look-ahead is not included in the move decision. In 1995, look-ahead is tried to be included, but the strength appeared not higher. Although it was getting a little stronger in the recent years, the look-ahead for move decision seems disappointing. Recently I made a new version of Handtalk without look-ahead for move decision. It seems somewhat weaker than the version with look-ahead in the games vs. the latter, but nearly the same strength as the latter in the games vs. other programs.
The strength of Handtalk mainly depends on the precise calculations in its static evaluation. An important key is block identification and safety estimation of blocks (here I use the term 'block' instead of the common used term 'group' to avoid confusion with the term group in group theory of mathematics).
Block identification in Handtalk, similar to that proposed by Ken Chen, depends firstly on the influence of stones, and then appended by some connection patterns.
However, the influence function is obviously different from that proposed by Ken Chen. The influence of a normal white stone:
A normal black stone radiates negative influence.
Dead stone radiates influence with opposite sign. Half-dead or injured stone radiates less influence.
The influences of stones on a point are additive, but not linear additive. For example, the influence on a point adjacent or diagonally adjacent to both black and white stones is 0, independent on the numbers of black and white stones. If the influence value of a point is 1 or -1, set it 0 (retaining 1|-1 to denote false eye-point of white|black). If the influence value is greater than 2, it is treated as a full white controlled point first and then rounded (see below); if the influence value is less than -2, it is treated as a full black controlled point first and then rounded. A full white|black controlled point has its influence value of 6|-6.
The unit of resulting influence is referred to as dot.
The rounding scheme includes the following rules:
Mutually contacting non-dead white stones, dead black stones as well as empty points with 1 dot or over 3 dots are combined into a white block; and then the nearby white blocks mutually linking together (unseparable) are combined. The black blocks are formed in similar way.
Block danger can be shown as a quantity with a suitable unit. The usual unit for evaluation in goe is MU in Chinese, MOKU in Japanese, or point in English. I prefer the Japanese term 'moku' to avoid using the polysemantic word 'point'. Block danger can also have its unit moku.
The factors of block danger are: 1. lacking of two eyes, 2. without enough freedom. To estimate the danger value quantitatively, the size of the block should be considered. Thus, the danger of a block should be a function of 3 arguments: lack of eyes, freedom and size. The concrete form of the function has to be set up empirically and changed by tunning.
Ken Chen explained the term freedom as the openness at the surrounding of a block.
Freedom of a block can be represented as the number of foe moves to surround it. It has been found that the related function is an exponential one: when the number of moves to surround a block increases by 1, the danger will be halved.
However, the number of foe moves to surround a block may be difficult to calculate. We have to design suitable scheme to estimate the freedom of a block instead of the number of moves to surround.
There are two schemes in Handtalk for freedom.
The earlier scheme: freedom is counted at the empty points adjacent or diagonally adjacent to any point (empty of with stone) belonging to a block.
The second scheme: freedom is counted at the empty points jumping or knighting from any stone of a block.
In the second scheme, farer scope is considered, so it seems more reasonable. However, an ambiguous estimation often has some superiority over an unambiguous one in goe programming, so the first scheme may be more suitable in many cases and leading to better moves. In the recent version of Handtalk, calculations are more and more precise, so it needs the more precise second scheme of freedom.
There was still a third scheme for freedom in recent years, but recently it has been found containing mistakes. A corrected new scheme has be adopted in the new version of another program, Goemate.
The second key of the strength of Handtalk is the efficiency modification of move values. That is, positive efficiency is set for good move (urgent move, tesuji, etc.), while negative efficiency for bad move (bad shape, trivial move, etc.).
The move value is multiplied by a factor greater than 1 when the efficiency is positive, and less than 1 when negative.
The efficiency is mainly evaluated from pattern recognition. However, Handtalk used a stupid method of pattern recognition: all jobs are done only by instructions without pattern database. Thus the pattern recognition is difficult to be modified or appended, and only a amall number of patterns can be included.
The size of the patterns is not fixed, but not exceed the following scope:
...
.....
.......
...*...
.......
.....
...