部首合成風(無?非?)連想式コード計画中

introduction

字形分解を直接入力に持ち込む時には、打鍵数の増大が問題になります。 石+申なんて字はない(?)のに、原理的にはそれを表すストロークが存在する、 その表現力の過剰さが原因です。 五筆字型は 多数の規則により4ストロークにおさめ、一方 NIK-Codeの 実装においては部品を一意に特定できる所まで入力すればTabで補完ができます。 これら打鍵数を削減する方法は、情報圧縮技術とも関連性があります。

私はこれまで、T-Codeの ような無連想式コードに対して、高頻度パーツに関してだけは規則性を持たせようと、 様々な思いつきを検討してきました。例えば、

本稿では、高頻度パーツに適用できる方式として、相対座標シフトという概念を提唱し、 実際に使用できる漢字直接入力コードを設計する。

原理

相対座標シフトとは、 アンシフト側の字の打鍵とシフト側の字の打鍵がお互いの位置関係によって特徴づけられ、 かつアンシフト側とシフト側の空間を区別する絶対的な境界が存在しない、という構造を指す。

何が言いたいかというと、 打鍵同士の関係を保ったまま全体を自由に動かしてしまうわけです。 これを使って、存在しないor直接打てない字を表す打鍵に別の字を割り当てよう、 というのが今回の目的です。1ストローク漢直コードでの概念図を下に示します。

 シ
イ0之
 才

×××   ×××   ×汁×   ×洲×    伎支 洲
×斤近 + 伎支× + 什十辻 + ×州× = 斤近技汁州
×折逝   ×技×   ×××   ×××   折逝什十辻

つまり「似ている文字を一かたまりにして配置する」というルールが増えた以外は、 ごく標準的な無連想式コードです。

仕様案

検討

進行状況

打鍵配置生成プログラムを作成中です。
kaminari.rb (sjis)
suppli.txt (sjis)
下の節で生成したbushu.th
あと適当な漢字出現頻度ファイルとtccのedu.tblを読み込みます。

Gかな+打鍵コスト最小化出力例Ver. 0.2
最大打数制限+打鍵シフト表再検討出力例Ver. 0.3
合成ルールの内容検討開始出力例Ver. 0.4
makerevを基に出力例Ver. 0.5
Ver. 0.5の漢直Win(1.27以降)用
to-tbl.rb

Ver. 0.5を試用して問題点を洗い出しているところです。

bushu.rev再検討

tc2のパッケージの 中にbushu.revというファイルがあります。これは部首合成変換という、 漢字の組み合わせで一つの漢字を入力する機能のための辞書ファイルです。 さて、ちょっとこの中を覗いてみますと……

  1. 漢字を構成している部品と部品を素直に並べたもの: 唖=口+亜
  2. 似ている字で代用したもの: 葵=サ+発,
  3. 部品の過不足が代用字の考え方で説明できるもの: 阿=院+可 (院=阝)
  4. むしろ異体字変換に近いもの: 單=単+口, 蠍=蝎+欠
  5. JIS X 0208のどの版の例示字形に従っているのか不明なもの: 祇=示+氏

と、なんでもありのデータが生のまま渾然一体に入っています。 これをそのまま扱っていたら、とてもじゃないが能動的には関れない、 と思い、『正しい知識』×『目的に応じた変換プログラム』の形に 再構成することにしました。

似たようなデータを持っているプロジェクトとしては 和田研フォントキットCHISEなどが ありますが、いずれも字形を表現することに主眼が置かれており、解字として 正しい分解かどうかを情報として持っているわけではないようです。

続きはブログにて。

makerev.rb (euc)※obsolete
makerev2.rb (euc)
cidbushu.txt (euc)※obsolete、makerev2.rbを用いてフォーマットを変換すること
cidbushu.alias (euc)
cidbushu.alias.by_pos (euc)
tc用のbushu.revとkaminari.rb用のbushu.thとCLWFKのjointdata/*.lもどきが生成できます。

G-Codeむりやり連想記憶

自分はこういう形でしか漢直を始められなかったのです。

EELLLTXT.g L112までほぼ確定
予定表L126まで183字分
たぶんこれで打ち止めです。

意味連想を使うのはやはり問題があります。 連想を忘れられるくらい練習すればいいんですが、 そんなにヒマならこんなのは不要なのかも。 石橋を叩いて壊さないと気が済まない人向け。

でも心理的バリアを解除するのには明らかに役立ちましたよ。

history

2006.3.19:
cidbushu.txtはフォーマット変更することにしました。
(確定じゃなかったんかいって話)

2004.12.18:
bushu.rev再検討計画はコードネームcidbushu。
中身のフォーマットほぼ確定。

2004.5.30:
コードとしての正式名称は雷コードに決定しました。英名は未定。
knapsack.rbはkaminari.rbにリネーム。
bushu.rev再検討の節を増やす。

2004.3.28: knapsack.rb
木と口について、偏かどうかを手作業で選り分け。偏パターンのみ1打目シフトに 割り当てるため。余裕があればCHISEを導入したいところだが (まずCドライブが一杯なもので)。
合成の対象を拡げたら、戈+土+口=哉と戈+口+土=域のパターンにぶつかった。 (土は1打目でしか定義してないし、口は偏に見えないから2打目で扱いたい。 そしてこういう孫孫干渉は折りたたみルールでは回避できない。) とりあえず裁土戈のところで分離することに。
あちこち修正。シフト表段階から再生成。生成例Ver. 0.4。

2004.3.23:
40字までいったところで一週間練習が止まってましたが、 この程度なら暗唱だけで維持できるものです。(追加なし)

2004.3.14:
Ver. 0.3練習開始から4日目。派生字を除いて現在32字。

2004.3.8: knapsack.rb
kwbushu.rev読み込み部分を修正。不足字を追加。頻度ファイルフォーマットの自動認識。
打鍵シフト表を見直して再生成。
教育漢字の最大打数を3打に押さえる→成功。
ただ最上段に機能キー領域を取ると全然だめ。とりあえず4ストロークに 追いやることにした。生成例Ver. 0.3。

2004.3.3: knapsack.rb
打鍵数最適化アルゴリスムの分散の定義に丸一日堂々巡り。
1字の最大打数を4打に押さえる→余裕。
T-Code文字の最大打数を3打に押さえる→無理。
教育漢字の最大打数を3打に押さえる→3年生分までなら成功。

2004.2.29: knapsack.rb
隠し親字実装。打鍵数最適化アルゴリスム。生成例Ver. 0.2。 やってることはすさまじく小難しい。

2004.2.27: knapsack.rb
打鍵配置コーディング開始。生成例Ver. 0.1。乱数でも結構つめ込めるんだな。

2004.2.26: knapsack.rb
部首配置探索についてはとりあえず完成。

2004.2.18: knapsack.rb
OOPっぽく書き直し開始。

2004.2.15:
説明を追加。

2004.2.14: knapsack.rb
パグ修正。対象文字制限。ようやくまともそうな結果が。

2004.2.14:
このページ公開開始。

2004.2.13: knapsack.rb
対称位置の条件を使わないと計算時間が無駄だと気づく。
しかし本当に正しく動いてるのか?

2004.2.11: knapsack.rb
部首配置探索プログラム。とりあえず1打目基本パターンのみ。

2004.1.24:
脳内で仕様が固まる。対象部首選定開始。


「ロストアワー」に戻る
Copyright © 2000-2004 Yamanobe Kiichiro.
yamky@cocoa.freemail.ne.jp