衒思力発電所

TWOR 解析 (1)

2 ゲッターさんが TWOR を頑張っている（混在 ZE おめでとうございます）のを見ていてオリジナル熱が出てきたはいいが打ったら絶望したので語るに落ちる^*1．

TWOR はとんがった種目なだけにスマートな攻略法はないものかと解析・考察される機会が多いような気がする． その流れ^*2に乗って．

TWOR での運指がどうこうシフトがどうこう先読みがどうこうといった考察は一般タイピング論とでもいうものに吸収されるべきだと思うし，それは複雑系（笑）すぎて今適当にやってどうにかなるとも思えないので，エントリのタイトルの通り，解析に焦点を当ててちょっと頑張ってみよう企画（TWJ のワード抽出の続きでもあったり）．

例によって一応概要を説明すると，TWOR の OR は 「オリジナル」 であってどうして「オリジナル」なのかは未だにわからないでいるんですがとにかくランダムっぽい英数記号をガリガリ打つ競技．

その TWOR の恐ろしい部分として，TWJR や TWEW では「ワード」という単位があるので部分に分解して読んだり練習することができるが，TWOR ではランダムな文字列がひたすらランダムに出てくるだけなのでとにかくその場で読んでその場で打ちこなすしかない！　というものがある．初めて TWOR をプレイした時はそこになんだか途方もないものを感じる（はず）．

だが実は，TWOR の出題文字列は完全にランダムというわけではなく，そこには頻出のパターンが存在している……ということが，TWOR プレイヤーの間では経験的に知られている．これは必ずしも断言されていないが，ある程度やり込んだタイパーであれば確信していると思われる．

にも関わらず詳細にまで突っ込んでその規則性・パターンについて調べた記録が見あたらない^*3． 薄々感じてるのに詳細は明らかになっていないっていうのは気分が悪いので，目下このあたりを調査してみる． TWOR のワードセット的なものを調べる，と言ってしまうこともできる．

まあモラルの問題というか，それタイピングちゃう！ チートや！ に通じる部分というかが少なからずというか大いにある話ではあるので，公にやるには後ろめたいっつー気持ちもわからんではないし，過去の識者もそんなわけで自重してたのかなぁとか色々思わないでもないんですが，情報の透明化が叫ばれる 21 世紀，は関係ないにしろ昨今の風潮を見るに，大顰蹙ってわけでもなかろう……と傲慢にも思いまして，お友達を増やすべく，過程をそれなりに書くつもり． 解析推奨！　とかこんなに簡単にチートができるぜ俺ってスーパーバッカー！　とかそういう意図はまったくとはいわないけどほとんどなくて，より快適に気分よくストイックにうひうひタイピングを楽しむための燃料になればと思ってやってることをどうかご承知置き下さいませ（丁寧！）^*4．

さて，目的とするような解析を行うにはいくつかの方法があって：

• 実際にプログラムを動かした結果を見て，そこから法則を推定する（観測）
• データとしてのプログラムからソースコード（の再現）を得て，そこから法則を取得する（デコンパイル）
• デバッガで実行中のプログラムの動作を追いかけ，そこから法則を理解する（デバッグ）
• プログラムの作者に聞いてみる （ネタバレ）

と穏やかじゃないもの含め色々．

とはいえ二番目と三番目は手元に完全なロジックを含むプログラムデータがあり，かつ自由な環境でないと使えない^*5し，突っ込んで勉強してないとできることじゃないので一般にはどうかと思う．四番目は今回のケースのように作者とユーザの距離が近い場合にはこれ以上なく強力だけど，禁じ手もいいところで興ざめなので，今は一番上の真っ当な観測によって進めよう^*6．

そんなわけで実際に TWOR を動かして，出題文字列を観測（記録）しようと相成るわけですが． その方法^*7にもいくつか考えられて：

• 出題文字列が格納されているメモリを参照する （直接参照）
• GUI 周りの API を利用して，描画に使われている出題文字列を取得する （問い合わせ）
• 画面に描画された結果を画像として読み込んで，出題文字列を抽出する （OCR）
• タイパーらしく手でメモする （全手動）

オナニーで並べてるだけなので詳細は脚注行きだ^*8が，ここでは三番目の OCR を採用．

表示されてる画像としての文字を見てその文字を特定するという，人間がやっていることに近いことをプログラムにやらせるわけで，これはまじめにやると論文になったり製品になったりという深遠なそれであることは素人目にも明らかなわけだけど，限定的なものなら素人にも書けてしまう．とりのさんが言ってたことにも影響を受けて，フォントファイルとかサイズとかスタイルとか文字集合とか全部手動指定するとようやく動き，拡大にも回転にもノイズにも全く強度がないというとても割り切ったスクリーンショット専用 OCR モジュール的なものを書いて^*9，その子に TWOR の出題文字列を収集させる．TWOR といっても四種目あるけども，さしあたり（一番ハデな）すべキーをターゲットにしよう．

（……一晩で 40 円ばかりの電気代を消費……）

結果，一晩で 10 万のデータを得る^*10． これについては公開して差し支えない物だと思うので，置いておく．

http://dvorak.jp/archive/twor_subekey_sample.zip (9.5 MiB)

解凍すると 20 MiB 弱の big なテキストファイルになるにょ！ 一行が一度の試行で，すなわち各行 200 文字にょ！ この長大なデータを統計的にあれやこれやすれば，あんなことやこんなことがわかったりわからなかったりするというわけだにょ！ お暇な人は自分でやってみるといいにょ！

と主に口調が盛り上がってきたところで次回に続く． 次回予告としてはいわゆるテキストマイニングによって TWOR すべキーの出題文字列の基本的な性質を明らかにし，TWOR の出題文字列には頻出のパターンが存在するということを統計的に検証します．(ｷﾘｯ

と格好良くキめたところでアレなんですが，どなたか TWOR の数字モードについて，「時間帯によって数字の出方が違うな，朝だと昇順の並びが多めで，夕方だと……」 みたいな考察をしているページ知りませんかね． いつかどこかで見たんですが，失念． 多分 TWOR が極まってる人だったと思うので， Q さんとか，その辺なんじゃないかと思いつつ発見できていない． 心当たりあったらたれ込んでくれると喜びます．

1. 誤用です．「語るに落ちる」は「えらそうなこと語るだけの奴になり果てる」という意味ではない，って当たり前すぎるんだけど，そういう誤用が増えているらしいぞ日本語が危ない！ [↩]
2. というほど流れてないけど． [↩]
3. アンテナ低いんで知らないだけかもしれない．ご存じの人がいたら教えて plz [↩]
4. こんなくどくどした前置きがなぜ必要かは次の n 段落でわかります． [↩]
5. 具体的には，ネトゲーとか手元で動かないロジックがある場合や，自由にあれこれできないコンシューマゲームなどで無理． [↩]
6. デバッグもデコンパイル結果の解読も断念したからなんてことは……． [↩]
7. この辺が競技的な視点から見ると悪いことできちゃう証明になっていてアウアウ．変な方向に強調すると印象が良くないことは先例 @2004 からも理解してるつもりなのでそっちは敢えてスルーします． [↩]
8. 一番目は上でデコンパイルやデバッグを否定した理由と同様の理由で却下，二番目は使える状況が限られ，実際 TW では無理だったので残念，四番目は最終手段だが現実的に限界を感じるので却下． [↩]
9. 特にこの界隈では問題ありまくりなんで一般公開はできませんが． [↩]
10. 手動でこの数は死ねる． [↩]

Trackback URL

コメント (6) to TWOR 解析 (1)

コメントをどうぞ