部首合成風（無？非？）連想式コード計画中

introduction

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

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

• 高頻度パーツをプリフィクスとして用意する

  プリフィクスに2ストローク使ったら部首合成変換に比べて利点がほとんどない。 1ストロークを割り当てるならあまり数をふやせない。1キーに多重定義したらどうか。bushu.revから調査……
  木, シ+目, サ+足, 才, 口, イ, 糸, ……高頻度なもの同士で多重定義はむり。

• 1打目を特定のキーにするとそのパーツがつく（プリフィクスをつける時に本来の1打目を捨てる）

  "支"=4p、"丁"=,/なんだけど"技"=up、"打"=u/みたいな。 2ストロークでは数的に収納力が足りないし、 そもそも斤近折逝みたいなのを収納できないので却下。

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

原理

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

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

　シ
イ０之
　才

×××　　　×××　　　×汁×　　　×洲×　　　　伎支　洲
×斤近　＋　伎支×　＋　什十辻　＋　×州×　＝　斤近技汁州
×折逝　　　×技×　　　×××　　　×××　　　折逝什十辻

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

仕様案

• 2〜nストローク方式である。 G-Codeなどの 疑似2ストロークのようにするか、SPC前置や中置のようにするか、は未定。 以下ではSPC前置式を想定してプリフィクスと称する。 いずれにせよ、(総打鍵数)+(1打目位置)+(2打目位置)で記述できるものとする。

  大本の親字の位置は無連想とする。対象字種は第1水準+人名用漢字+親字として必要なもの。 親字に派生字がたくさんくっついてくるが、これを5次元の中に詰め込む。

  筆画に至るような分解はしない（必要なのは互いに自由に配置できる複数の まとまりだから）。パーツの単位とそれを表す文字は tc2の部首合成変換で 使われているものを流用する。 （しばらくは分解ルール自体も部首合成変換辞書から借ります）

  かな部分の配置は未定。

• 1打目シフト表その1。例えばこんな。親字に手偏をつけたい時は、 1打目を1つ左下にずらして打つ。

  日月火山院
  木金土宀之
  シ目０サ性
  イ才口竹ネ
  糸足言石初
  

• 1打目シフト表その2。例えばこんな。親字にけもの偏をつけたい時は、 1打目を1つ左下にずらし、プリフィクスを1つ増やして打つ。

  禾食王穴え
  冫貝　四舟
  彳独耳雨示
  

• 同様に、2打目シフト表の例。1打目シフトでも2打目シフトでも、 増えるプリフィクスに区別はない。

  羊大田巾部
  木广厂囗門
  リ力０鳥心
  米車口立方
  虫女魚馬酉
  
  攵病尸匚行
  欠貝　隹頁
  釆革　弓歹
  

• 上下方向にはみ出したらプリフィクスを1つ増やして反対側から入る。 左右方向は片手5列の中でプリフィクスはそのまま反対側から入る（暫定）。

  打｜　　　　｜　｜　　宜萓柤｜上
  鍵｜▲　　　｜　｜　且　　沮｜↑
  数｜■■▲▲｜　｜　咀　　　｜↓
  ↑｜　■■●｜　｜　　　祖組｜下
  　下←　　→上　左←人中薬→右
  

• "疋"に対して孫にあたる"掟"が同じ位置に来たり、 "斤"の子の"芹"と孫の"逝"が同じ位置に来たりします（以下自家干渉と呼ぶ）が、 上記の折りたたみルールを利用することにより*ある程度*回避することができます。 （この効果はどっちかというと頻度順を反映するのに使いたいですが）

  上｜　　　　　｜　｜　　　　　｜　／２　｜　　　　｜打
  ↑｜　　　定　｜＿｜　　　定　｜／　段　｜　　　掟｜鍵
  ↓｜　　疋　　｜　｜　　掟　　｜　／ず　｜定　　　｜数
  下｜　　　　　｜　｜　　　　　｜／　ら　｜　　　疋｜↑
  　左←　　　→右　左←　　　→右　／す　下←　　→上
  
  上｜　　　　　｜　｜　　　　　｜　／２　｜　　　　｜打
  ↑｜　　斤芹　｜＿｜　　　逝　｜／　段　｜逝　　　｜鍵
  ↓｜　折　　　｜　｜　折　　　｜　／ず　｜　　　折｜数
  下｜　　　　　｜　｜　　　　　｜／　ら　｜芹　　　｜↑
  　左←　　　→右　左←　　　→右　／す　下←　　→上
  

検討

• 3ストローク以上の時のルールについて。疑似2ストロークかSPC中置を採用すれば、 phoenix配列や 風のような検索性が得られます。 1打目が共通する場所に適当に旧字や異体字や第2水準の字を入れてしまえば探すのに便利だ、 という感じ。例:（略）

  しかし、SPC中置は（何か+SPC）の英数字直接入力とぶつかるので、 なるべくなら避けたい。かと言って、疑似2ストロークは最上段の機能キー （22とか44とか）とぶつかるし……あ、（何か2連打+SPC）って誰も使ってないな。 機能キーはここに追い出すか。

• bushu.revの中を見ると、開の中のパーツ（幵という字が一応ある）を 開という字で代表させたり云々、といったエントリがあります。一見不自然ですが、 部首合成変換ではシ+談→淡みたいに（この場合bushu.revの中では談が炎の代用に なっているわけではない）字の一部からでも合成することができるので、特に 開という字を意識する必要はありません。形でも研でも使っていいわけです。 実装としては美しくないと思いますが、「合成の手数を少なくする」という方針の表れ なのでしょう。（ですよね？）

  しかし相対シフトではそういった融通がききません。（解角牛の上の刀はどこから 出てきたんだ、という話は部首合成変換と共通ですからわきに置いておきます。） 門がまえがシフトで表せるとすると、開などの扱いはどうするべきか。

  1. そのまま親代わり字とする

     融通がきかないので特別扱いであることを記憶してもらう必要がある。 「開は研から石をアンシフトしただけ〜門のシフトはいらないよ」

  2. 正常化させて幵は隠し親字にする

     例外はなくなるが頭の中での操作が多くなる。 「開の中のパーツって言いたいだけなのに、なんでいちいち門のアンシフトなんて 考えないといけないんだよ」

  うーむ、こうして見るとbushu.revに逃げたのはむしろ正解だったのかもしれない。

進行状況

打鍵配置生成プログラムを作成中です。
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:
脳内で仕様が固まる。対象部首選定開始。