World Shogi Computer Championship games Analysis............

[pichy]

Puella α is former Bonkras. It has changed its name since this tournament. I don't know why exactly.
The below is the game between Gekisash and GPS in the first round. I am surprised to see GPS's left gold moves. I cannot believe the side which moved one of his Gold too far from the castle like this win. If Sente chose Px2d instead of B-2b at the 47th move, P*6f G7i-7h B*4i would be sever since Sente could not defend Gote's Rook's breakthrough on the sixth file.

http://homepage.mac.com/junichi_takada/ ... K_GPS.html

Another game that surpise me is this. It's a game of GPS and YSS in theAt the 29th move, GPS moves his right Silver to 4f and neglects YSS's N-8e threatening to take the Silver on 7g in the next move to start attacking with P-3e. It's amazing GPS allows materially-disadvantageous-kNight-Silver trade in this early stage and overwhelmes YSS from that onwards.

http://homepage.mac.com/junichi_takada/ ... S_YSS.html

The third one is a game of Tsutsukasa and GPS in the fifth round. GPS does not follow many texbook theories. At the 30th move, he neglects Sente's previous pawn push to allow him to capture the Pawn on 3d for nothing for a while. He leaves his King staying on the initial square. He offers Bishop exchange without hesitating to get his left Gold in bad shape. How freely he plays!

http://homepage.mac.com/junichi_takada/ ... K_GPS.html

The final one is GPS vs ponanza in the final round. GPS wins this game to decide the victory of the tornament. Everybody is astonished the Bishop sacrifice at the 19th move.

http://homepage.mac.com/junichi_takada/ ... PS_PON.htm

[pichy]

White: OtsukaSoufu 5 Dan Versus Black Ponanza
#KIF version=2.0 encoding=UTF-8
開始日時：2012/05/09
場所：81-Dojo (ver.2012/04/08)
手合割：平手
先手：PONANZA
後手：OtsukaSoufu
手数----指手---------消費時間--
1 ２六歩(27) ( 0:22/)
2 ３四歩(33) ( 0:5/)
3 ７六歩(77) ( 0:2/)
4 ４四歩(43) ( 0:5/)
5 ４八銀(39) ( 0:2/)
6 ４二飛(82) ( 0:7/)
7 ５六歩(57) ( 0:2/)
8 ９四歩(93) ( 0:14/)
9 ６八玉(59) ( 0:2/)
10 ７二銀(71) ( 0:4/)
11 ７八玉(68) ( 0:2/)
12 ３二銀(31) ( 0:5/)
13 ７七角(88) ( 0:20/)
14 ４三銀(32) ( 0:5/)
15 ５七銀(48) ( 0:2/)
16 ６四歩(63) ( 0:5/)
17 ８八玉(78) ( 0:12/)
18 ７四歩(73) ( 0:6/)
19 ６六歩(67) ( 0:31/)
20 ６二玉(51) ( 0:7/)
21 ９八香(99) ( 0:16/)
22 ５二金(41) ( 0:14/)
23 ９九玉(88) ( 0:16/)
24 ７一玉(62) ( 0:6/)
25 ８八銀(79) ( 0:16/)
26 ８二玉(71) ( 0:7/)
27 ２五歩(26) ( 0:12/)
28 ３三角(22) ( 0:6/)
29 ５八金(49) ( 0:18/)
30 ８四歩(83) ( 0:5/)
31 ３六歩(37) ( 0:17/)
32 ９五歩(94) ( 0:4/)
33 ７九金(69) ( 0:10/)
34 ６三金(52) ( 0:10/)
35 ６七金(58) ( 0:15/)
36 ７三桂(81) ( 0:5/)
37 １六歩(17) ( 0:15/)
38 １四歩(13) ( 0:5/)
39 ３八飛(28) ( 0:13/)
40 ３二飛(42) ( 0:7/)
41 ４六銀(57) ( 0:33/)
42 ２二角(33) ( 0:7/)
43 ３五歩(36) ( 0:17/)
44 ４五歩(44) ( 0:22/)
45 同　銀(46) ( 0:11/)
46 ３五歩(34) ( 0:5/)
47 ２四歩(25) ( 0:15/)
48 同　歩(23) ( 0:4/)
49 ２三歩打 ( 0:13/)
50 ３三角(22) ( 0:6/)
51 ３五飛(38) ( 0:12/)
52 ４四歩打 ( 0:8/)
53 ２二歩成(23) ( 0:14/)
54 同　角(33) ( 0:6/)
55 ３二飛成(35) ( 0:12/)
56 同　銀(43) ( 0:6/)
57 ６五歩(66) ( 0:27/)
58 同　桂(73) ( 0:6/)
59 ４四角(77) ( 0:12/)
60 同　角(22) ( 0:6/)
61 同　銀(45) ( 0:2/)
62 ５九飛打 ( 0:24/)
63 ６二歩打 ( 0:14/)
64 同　金(63) ( 0:32/)
65 ３五角打 ( 0:9/)
66 ３四歩打 ( 0:8/)
67 ４六角(35) ( 0:10/)
68 ２九飛成(59) ( 0:24/)
69 ６四角(46) ( 0:9/)
70 ７三桂打 ( 0:20/)
71 ７五歩(76) ( 0:21/)
72 ６三歩打 ( 0:24/)
73 ３七角(64) ( 0:8/)
74 ５八角打 ( 0:17/)
75 ６八歩打 ( 0:20/)
76 ４七角成(58) ( 0:10/)
77 ５五角(37) ( 0:18/)
78 ５四歩(53) ( 0:5/)
79 ６六角(55) ( 0:11/)
80 ８五桂(73) ( 0:19/)
81 ４五飛打 ( 0:15/)
82 ３六馬(47) ( 0:30/)
83 ６五飛(45) ( 0:11/)
84 ９六歩(95) ( 0:23/)
85 同　歩(97) ( 0:11/)
86 １九龍(29) ( 0:18/)
87 ８六桂打 ( 0:7/)
88 ８一玉(82) ( 0:7/)
89 ７四桂(86) ( 0:33/)
90 ７八歩打 ( 0:15/)
91 同　金(79) ( 0:16/)
92 ６九馬(36) ( 0:6/)
93 ７九金(78) ( 0:33/)
94 同　馬(69) ( 0:4/)
95 同　銀(88) ( 0:2/)
96 同　龍(19) ( 0:11/)
97 ８八角(66) ( 0:32/)
98 ７八龍(79) ( 0:8/)
99 ４六角打 ( 1:27/)
100 ７三歩打 ( 0:9/)
101 ５五歩(56) ( 0:12/)
102 ９七歩打 ( 0:6/)
103 ８二桂成(74) ( 0:2/)
104 同　玉(81) ( 0:10/)
105 ５四歩(55) ( 0:2/)
106 ９八歩成(97) ( 0:6/)
107 同　玉(99) ( 0:2/)
108 ８六桂打 ( 0:4/)
109 同　歩(87) ( 0:2/)
110 ８七銀打 ( 0:5/)
111 ９九玉(98) ( 0:2/)
112 ９八金打 ( 0:1/)
113 投了 ( 0:2/)

[hgm]

Alas, this is something WinBoard can not read. They write the piece last?

[Dan Honeycutt]

Alas, this is something WinBoard can not read.

WinBoard is not alone.

Best
Dan H.

[shogi4fun]

Alas, this is something WinBoard can not read.

WinBoard is not alone.

Best
Dan H.

It's the most common format for shogi in japan world.

I can convert it to an other format used in western world, but still I'm sure it's also not comfortable for chess players.

So I suggest, maybe better use the program Shogidokoro (http://www.geocities.jp/shogidokoro/dow ... dokoro.zip) where you can also set western looking pieces in the options dialog.

[hgm]

Well, it seems better to use a converter, and then load it into WinBoard, which would show it to you as normal PGN.

I am not sure if it can be parsed by a game-state-unaware parser, though. In fact, I am not even sure how disambiguation works. There seem to be kanji for 'left' and 'right' piece, but that doesn't seem to be enough, because you can have 4 pieces of each type.

[shogi4fun]

Well, it seems better to use a converter, and then load it into WinBoard, which would show it to you as normal PGN.

Still I don't know even one shogi program/converter supporting PGN.

Short moment thinking about implementing it ...
No.

I am not sure if it can be parsed by a game-state-unaware parser, though. In fact, I am not even sure how disambiguation works. There seem to be kanji for 'left' and 'right' piece, but that doesn't seem to be enough, because you can have 4 pieces of each type.

Implementing 100% KIF (that's the name for this format) functionality would be some work, but implementing the main thing shouldn't be so hard.
Yes, there are Kanjis for 'left', 'right' and some more, but you would need it only for the KI2 format, because the KIF format also gives the position of the source field: it's the number in brackets

Taking any line:
1 ２六歩(27) ( 0:06/00:00:38)

- ２六: target field (from upper right - second one is a kanji representing the number)
- 角: piece to move (only needed for drops, because number in brackets
- 27: source field (from upper right)

and
- 同: same (target) field than last one

and ( 0:06/00:00:38):
- first part: move time
- second part: whole thinking time

[hgm]

Still I don't know even one shogi program/converter supporting PGN.

I hadn't expected one, but WinBoard can also read PSN, and I would be surprised if there was no convertor for that.

Implementing 100% KIF (that's the name for this format) functionality would be some work, but implementing the main thing shouldn't be so hard.
Yes, there are Kanjis for 'left', 'right' and some more, but you would need it only for the KI2 format, because the KIF format also gives the position of the source field: it's the number in brackets

Oooooh! I had not figured that out yet. That indeed makes life a lot easier. Is this just a number 1-81, raster-scan mode, or should I interpret the digits as coordinates. (I guess I could figure that out by deciphering the posted game, but I am lazy! )

Taking any line:
1 ２六歩(27) ( 0:06/00:00:38)

- ２六: target field (from upper right - second one is a kanji representing the number)
- 角: piece to move (only needed for drops, because number in brackets
- 27: source field (from upper right)

and
- 同: same (target) field than last one

and ( 0:06/00:00:38):
- first part: move time
- second part: whole thinking time

With source and destination field given parsing becomes almost totally trivial. Recognizing the piece kanji for the drops can still be tricky, because you would have to prepare for different encodings (UTF-8, wide char, code pages...)

Easiest would of course be if WinBoard could directly parse the format, but OTOH I don't like to have an infinitely complex parser that can understand a zillion different formats in WinBoard.

Perhaps I should equip WinBoard with an option to invoke a pre-processor when loading a file. Or perhaps try to invoke it automatically when a non-standad file type is loaded. E.g. for a .kif file it could try to execute the command "kif.exe name.kif > temp" and then read temp in stead of name.kif. Then I would only have to provide a pre-processor that converts the KIF format to something WinBoard can understand (like long-algebraic, which should be possible without game-state awareness, and thus totally trivial.)

All that people then would have to do to allow WB to understand their local format would be to supply a converter, and put it under the proper name in the WB folder.

[hgm]

1 ２六歩(27) ( 0:06/00:00:38)

Oh man, this is awful. The leading '2' of the move is a kanji 2, rather than an ASCII 2...

An octal dump of the line is:

Code: Select all

061 040 (357 274 222) (345 205 255) (346 255 251) 050 062 067 051 040 050 040 060 072 062 062 057 051 040 012

Where I put parentheses around the bytes that together form one kanji (in the UTF-8 code that is apparently used by the browser).

[shogi4fun]

Oooooh! I had not figured that out yet. That indeed makes life a lot easier. Is this just a number 1-81, raster-scan mode, or should I interpret the digits as coordinates. (I guess I could figure that out by deciphering the posted game, but I am lazy! )

Oh, and I also made a mistake: there re not all all used Kanjis 'left', 'right' in KIF, only in KI2.

Japanese uses BOTH numbers for horizontaly and verticaly lines. Still first is described by latinum number, second one by Kanji.
(Look for example here)
And because western world has not good two kind of numbers (there was thinking about using roman numbers), the Kanjis are "translated" to letters (1=>a, 2=>b, ..., 9=>i).
First number is horizontaly starting right, second "number" verticaly starting from top.
So 99 is (in your thinking) A1, in "shog-type" 9i
98 => A2 => 9h
97 => A3 => 9g
89 => B1 => 8i
88 => B2 => 8h
...

And I fogot:
成: promote
打: drop