近年(というか、ここ1ヶ月？)の「飛鳥カナ配列・堂々巡り総集編」において、とても気になる変更が2つ。
- 「ざ」の位置が動いた。
- 「に」の位置が動いた(というか、元に戻った)。
「ざ」。
えーと……(かえであすかの場合)「せぜ」を上に動かす都合で、「ざ」を下へと動かしただけ(＝「ざ」のcomfortabilityを狙ったわけではない)なのだけれど、これは結構気に入って使っていたり。
「ざ」は覚え間違いによる誤打が「よりよい場所」に来たからあまり間違えないし、「ぜ」は「せ」の清濁隣置だから強い印象が残るし……ということで、使い続けてきた割には間違えが発生していなかったところは、今になって思えば印象的だったり。
「に」。
Rayさんが「に」について強く指摘していらした点は、「理論的には」ものすごく納得いく話だったんですよね……それに、これは「かえであすかでは、ほかに置ける場所がなかった」ということと一緒に「かえであすかがかえであすかであるために、宿命的に背負うこととなった制限」でした。いや、正確には「制限として仕掛けたつもり」でした。
「に」の出現頻度は「いうんかしとてなのはたす」に続き、「でき」よりも頻度が大きいという都合があり、「いくら【てにをは】の【に】だからとはいえ、高頻度のかなをヤバめのところにおいておけば、これが飛鳥とかえであすかの差に気づくためのキーポイントの一つになるだろう……」という狙いもありました。
……でも、使っていても「【に】が人差し指にあるのは確かに不満だけれど、【に】が下段にあること自体には(21世紀-290版を使っているときと同様に)不満がない」状況であることには変わりませんし、【に】が小書き文字へと接続するシーンをのぞけば「文中にいきなり【に】が出現連接したりはしない(「に」でいったん途切れる)」ので、 なんだか納得がいかなかったんですよね……。
けっきょく、「気づいてもらう仕掛けとしてわざとそうした」つもりだった「に」がらみの仕掛けは、どうやらうまく働きそうにないらしいです……って、ふつう使っていれば気づくじゃないかorz。
うーん……狙いが外れてしまったのはちょっと痛いです。もうすこし「かえであすかWiki」側できっちり飛鳥へと誘導しておかないと、へたに「かえであすか」だけに気づく方が増えてしまうと困りますし……。
計算配列について、ふと思ったこと。
文字の出現頻度解析をする場合には、それが「単なるN-gramとして」解析するのではなくて、「品詞情報などをもとに、一定の単位で分かち書きをして」からN-gram解析をするほうが、【打鍵評価に使用するための出現頻度解析】のためには、重要なのかもしれない……と思ってみたり。
すくなくとも、今まで公表されてきた計算配列について見てきた限り、「かなの単独出現頻度」と「かなの連接頻度」についてはきっちりと考慮した配列ができていた……はずなのだけれど、品詞情報を使わずに配列評価をした結果として
計算配列に近いほど「一定テンポ打鍵時に高効率をたたき出す可能性が高い」。
(from http://d.hatena.ne.jp/maple_magician/20070321/1174405288 )
……となってしまうのでは、ちょっと勿体無い*1気もするわけで。
計算配列の設計手法は手捏ね配列によって発見されて進化するし、手捏ね配列の進化が正当かどうかを評価するためには計算配列の設計手順をアップデートすることが重要になるし……と、結局両者は「切っても切れない関係」にあるのかもしれない。
とりあえず、計算配列には「まだまだ進化の余地はたくさんある」と……私はそう思います。そして、このアプローチは最終的に「計算配列の評価」だけではなく「手捏ね配列の評価」*2にも応用されていくはず*3だと思います。
*1:定テンポ打鍵時に最大効率になっている「必要はない」んですよ。現行法で見れば特性が歪んで見えるような配列であっても、人間が「普通の創作入力」をするときに「最大効率になる」のであれば、それでコピータイプを職業とする方以外の「ほとんどの方は幸せになれる」わけで。将来の日本語入力利用者の多くにとって必要なのは、多分そういう配列なんです。それが何なのかは、いまだに私は確信を持っていえる立場にはないですけれども。
*2:太字部分は2007年11月11日20:24:23に追記しました。
*3:2007年11月11日20:24:23追記……解っていない方はいないであろうことを前提にあえて書き足したいのだけれど、今の状況では「手捏ね配列」の評価をまっとうに行える「評価関数」は存在していないと思うのです。手捏ね配列の精度に追いつくまでに、あとどれほど掛かるのかは解らないですけど……それができるときはきっと来ると、私はそう信じてみたいのです。
