次世代NIK-Code (名称募集中)

月Yxが落ち着いたので、ふたたび遊びの時間です。遊びの方が主目的ですかんね。
http://d.hatena.ne.jp/ytqwerty/20060122#p3の続き。
まず、NIK-Codeの欠点まとめ。

  • 小さな部品単位のため打鍵数がとんでもなく多い。
  • 小さな部品単位のため字形の変更に弱い。
  • 漢直なのに確定操作を要する。
  • シフトキーまで使う。

長所。

このうち打鍵数については、以前私がやってましたNIK-50上では、省略込みで7打鍵が限界として確認しています。以下の漢字です。

……以上が、一年ちょっと前の到達点でした。
さて、これらの問題を解決するには。
まずNIK-Codeの部品が細かすぎるのが問題の多くを占めていますので、これを解決する方法を探しましょう。
(案1) 部首(部品)をそのままキーに振る。
キーが足りるわけがありません。そんなことができるならNIK-Codeも最初からやっていることでしょう……。
また、これではやはり確定操作が必要になります。
(案2) 最初に分割を指定して、以降は部首(部品)を埋めていく。
例えば1ストローク目で、左右分割の漢字、と指定したら、2ストローク目で偏を、3ストローク目で旁を指定します。
1ストローク目の時点で全体のストローク数がわかるため、確定操作が要りません。
しかし、これでもキーが足りないのです。漢字の部首は、偏だけでも30種類なんか軽く超えます。シフトキー使えばいけるとは思いますが、どうせならシフトキーも使いたくないですしね。当然数字段も却下。
1ストロークで選択できるのは30種類以内に収めるのが条件です。
(案3) 最初に1画目を指定して、以降は部首(部品)を続ける。
案1に追加して、最初の部首(部品)を指定するためにプレフィクスを用いるわけです。プレフィクスとしてはこれも視覚連想の、1画目を採用します。横線、縦線、はらい、点、などですね。最初の部首(部品)が決まったら(魚偏などを除いてですが)以降はだいぶ絞られるため、2つ目以降の部首(部品)にはこのプレフィクスは不要であろうとの見通し。
よさそうです。
しかし、このままではやはり確定操作が必要になります。
(案3') 最初に1画目を指定して、以降は部首(部品)を続ける。確定用の部首(部品)と継続用の部首(部品)を分ける。
つまり、同じ"木"であっても、木偏として使う場合と"木"の字そのものを入力する場合では、別のキーを叩くことになります。

これなら、上手くいけば、件の漢字のストロークはこうなるはず。

ヨコ、車、人、一、冊 or {月、りっとう(Unicodeの5202)}
ハライ、金、立、見 or 里
ヨコ、りく(Unicodeの5774)、九、丶、よつてん(Unicodeの706c) or 力
テン、米、广、字が無いですけど尹っぽいやつ、口 or 水
ヨコ、酉、日、疋 or 生
ハライ、豸、艮、心 or 土
ヨコ、車、几、又、手 or 糸

やったぜ最大6ストロークだ!
あんまり変わんない?いやいや、NIK-50では、省略も使って7ストロークと要確定。これは、省略は使わずに6ストロークで確定不要。

……という試案のもと、かなりいい加減に、ひらがなカタカナと3画までの漢字を配列してみました。
[XXX]が1画目、括弧付きは確定しない部品、それ以外は確定する部品です。

1画目:

    [HoT] [LPt] [Ver]         [Hor] [VeZ] [SlX]    
[VeX] [RPt] [HoZ] [RAr]     [Kut] [SlB] [HoX] [HoL] [Ten]
[LAr]     [RSl] [Sla]     [VeL] [Tot] [HLX]        

[VeL]に続く部品/文字:

                    
                             
                          

[HoT]に続く部品/文字:

                          
                 
                          

[Sla]に続く部品/文字:

      丿         
                 
                       

[SlX]に続く部品/文字:

      丿                     
                    
                    

[VeX]に続く部品/文字:

                       
                       
                          

[RSl]に続く部品/文字:

                          
                       
                             

[Ver]に続く部品/文字:

              
              
                       

[LAr]に続く部品/文字:

                             
                       
                             

[HoZ]に続く部品/文字:

(九)

[HLX]に続く部品/文字:

                    
                    
                          

[RAr]に続く部品/文字:

                       
                    
                             

[RPt]に続く部品/文字:

     
  
         广   

[LPt]に続く部品/文字:

                 
              
                    

[SlB]に続く部品/文字:

      (勹)
   (人)
   (←)       (几)   

[VeZ]に続く部品/文字:

        
     
           

[HoL]に続く部品/文字:

(了) (又) (刀)
   (コ)

[HoX]に続く部品/文字:

[Hor]に続く部品/文字:

           
(一)   
           

全部品/文字:

だぺフ 了十巾おチばヲ (九)丿亠厂手がぐめそれヂヤ尸 礀力いたアピキミサ 囗ずぷイモズ 厶彑ダノゥベポ(了) 千(又)巛口きすどジ下 亅弓ちづべウほリルレヰ久 えぜ冂ペユセ几ヴ 九(勹)工ゑ(刀)ぽ冫彳寸屮
女于うとのハホ夂ヨ丁 よわ廴デ冖パゲムメロン七丈 土ろつぬドニふぼマゼ一 やにヅ廾バカギ刀ボケ 也勹卜匸もをヌネ彡 亡てブオ(一) (人)ぁげしるゐテビエゾ 二ぅかごじらナぱヒみク山 之匕けなね入ぴィスー上 己Lくび夕大
乙トは尢ゴザ乃 人子ぎぢぶ凵 宀ぃせぞへ夊乂 (←)さプまワ士 ぉこりァ 幺兀ざで(コ)儿ソ 又广んひ八ォガタ与 匚干ぇ弋ゆツグヱヽ 及あ小(几)コシラ万 丶卩むェヘ

矛盾しないような条件でOCamlで並べただけですので頻度とか運指とかは見ないでいただけたら嬉しいです。OCamlインタプリタHugsよりだいぶ高速に動くようで、この程度ならocamloptはおろかocamlcすら必要ないのが嬉しいですね。

例えば"丸"なら[HoZ](←水平線からZ字に曲がる画……の意味のつもり)、"(九)"、"丶"の3ストロークとなります。
パクリ図で書くとこうですね。て→九→丸と書き足していく。

□□□九□ □□□□□ 
□□て□□ □□□□□ 丸
□□□□□ □□□□丶

うん、この図はぴったりです。ありがとうございますと勝手にパクって勝手にお礼。
みのりさん曰く、●とかですとアルファベットを覚えてしまって困るとのことですが、これなら漢字部品がアルファベットを代替するので、そんなこともないでしょうしであって欲しいです。
次のとどっちがいいかな。

□□□九□ □□□□□ 
□□て□□ □□□□□ 
□□□□□ □□□□丸 

左右ないし上下に2分割できる漢字は多いので、かなりの字が3ストロークになる筈。でも「祭」みたいな漢字は4ストロークになってしまいますね。「疑」なら5ストロークです。(案2)ならキー数が足りれば全部3ストロークもできうるのですがキー数が足りないのですから仕方が無い。いや……1ストローク目に、1画目と分割の両方の意味をもたせればいけるかな……しかしその場合「タヌ」や「ヒ矢」のようなものが部品になってしまい、部品数が普通の漢字コードの2ストローク文字の数に匹敵してしまう予感。

仮名は、全部2打鍵で打てるように、ひらがなカタカナ濁音半濁音小書き全部含めてしまいました。見ただけでもう覚える気がしません。1画目を1ストローク目とする条件上、ひらがなとカタカナの分離は必然なのですが、せめて、濁音半濁音はポストフィクスにするかな……。1画目はキーが余ってますし、書き順による連想ですとその方が自然ですし。

それと確定用部品と確定しない部品は、わかりやすく並べるような条件をつけたほうがいいかも。同じ指の別の段にするなり、左右対称の位置にするなり。
それと1画目ぐらいは(手で)意図を込めて並べた方がいいかもしれません。句読点はQWERTY位置なりDvorak位置に置くとか、濁点後置するならやっぱLかなあとか、[Ho?]は全部左手にして[Ve?]は全部右手にするとか。

それよか漢字かな混じり文の頻度データ調達してくる方が大変な……。もう、データは取らずに常用漢字 > 人名漢字 > JIS第1水準 > JIS第2水準の4レベルぐらいの重み付けでいいじゃんなんて考えている自分がいる。フォントに無い、シフトJISでの扱いが面倒etcの理由でJIS第3水準以降は無視します。ああ……どのみち連接データは必要になるのか……。

ああそうか、確定操作不要ということは変換操作もないということで、全角記号も配置しなければならないんだ……●の一画目ってなんなんだろう……忘れとこう。

それにしても、先駆者の開発日記はかなり参考になります。

三打鍵の漢字の割り当てを考えてました。訓読みが多いのは左から右、音読みは右から左へ、というのはリズム的に良さそうなので、意識してそうしていってます。
二打鍵の時もそう出来れば良かったのですが、もう遅い。
http://www.geocities.jp/minori632/nikki2.html

センス・オブ・新JISでいくと、音読みは左から右で訓読みは右から左かな。もし濁点をポストフィクス化してLに置くならの話ですが。といってもナラコードがH濁点ぐらいで、他のカナ配列は大抵清濁分置ですので、参考にするべきものがあんまり無いのが実情なだけですけれども。
何も参考にしないで考えますと、濁る清音は1画目が[Ho?]が多い([Ve?]は"くけはほ"の4つだけ)ため、1ストローク目は左手として、ひらがなは高頻度ですので運指で最適化すると2ストローク目は右になるでしょうから、濁音は左かな。次もまた左で始めることを考えるとCあたりが妥当かも。半濁点は「ぱ」があるので右かな……。
いやまてまて、既存のデータでは果たして「ぱ」が多いのか、それとも「パ」が多いのかわかりません。やっぱ調べなおさないといけないのか……。濁る[Ve?]に"ト"追加。ひらがなカタカナ分置って思ったより面倒なのかも。

結局データ集めて、濁点の位置も探索させるのが一番いい気がしてきました。漢字の中の濁音は考えなくてよいため、仮名配列の濁音ほど高頻度ってわけでもないでしょうし。

その前に名前ですよ。命名要件としては(1)漢直の伝統らしい「なんとかコード」にする (2)NIK-Codeに少し絡める (3)SFにも絡める……ううむ。今読んでる「キルンピープル」にグレイなるコピーロボットが出てくるのでグレイコード。勿論没。