感覚と計算値の狭間で……。

　飛鳥ネタからの派生なのだけれど、GA手法などを用いた計算配列においても「文末または特定の言い回しなど、低コストで打ち切れないといらつく様なところに対して、(本来の頻度よりも大きめに見積もった値を与えることによって)差別的に打ちやすくするという工夫が必要になるのかも」と感じていたり。
　このあたりは、新JISかなでは採用されなかった(新JISかなは「か」→「゛」を基準にしている)のだけれど、TRONかなではたしか「変換キー」を基準にしていたはずなので、結果としてこの方針が採用されているのに近い効果が出ていた……のかも。
　日本語の文章は「(本来サクッと打てるべき)文末とかが打ちにくいと、全体効率が悪く感じてしまう」ところがあって、これはかえであすか(の元となった飛鳥カナ配列)だけではなくて、手組みの新配列系ではたいてい考慮されていると思う(あるいは新JISを基礎とする月でも、月2-263はうまく回避してるし、私製異版系では自然と回避してると思う)。

　それと、この手のネタは、PC用のキーボードに限った話ではないのかも、とも思っていたり。
　たとえばかえで携帯配列とか……あれは「(濁音・半濁音・小書き文字を含む)かな＆頻出記号の2打鍵統一」方向に振っていて、結果として「です。/ます。/ですが、」などの打鍵コストが(ポケベル入力よりは)増加せずにすんでいる……という結果を生んでいたりするわけで。
　私はポケベル入力(の濁点・半濁点・読点・句点に関する操作)がどうにも許せなかった(というか、情けないことにそれらを覚えられなかった)のだけれど、むしろ満足に使えていたら「かえで携帯配列」のようなものを組み立ててみようとは考えもしなかったはずなので、結局は「結果オーライ」なのかも。

　計算配列に対して「適切と思える出現頻度バイアス」を組み込むのはとても大変だと思うのだけれど、「アルゴリズム」と「打鍵速度データ」だけではなくて、「出現頻度データに対するフィルタ」*1についても考慮する価値があるのかも……と思ってみたり。
　……って、このあたりは私の専門じゃないので、あまり口出しすべきではないのかもしれませんけれども^^;。

2008年8月11日23:07:03追記。

　飛鳥カナ配列スレッドで採りあげていただいた様子。

552 名前：名無しさん[sage] 投稿日：2008/08/11(月) 11:55:11 0
yfi氏が
「(本来サクッと打てるべき)文末とかが打ちにくいと、全体効率が
悪く感じてしまう」と書かれているが、yfi氏個人の文章は、下記の
ように、言い切らない文末が多い。何か関係あるのだろうか。

「と思っていたり。」
「するわけで。」
「なのかも。」
「かもしれない」

「orz」

553 名前：名無しさん[sage] 投稿日：2008/08/11(月) 12:17:30 0
そもそも「文末はさくっと打てるべき」が証明されていない。

554 名前：名無しさん[sage] 投稿日：2008/08/11(月) 12:17:38 0
いやそれはおかしい。
日本語は文末も文節区切りも大差ないはずだ。
単語で切って改行するトンデモ文章ならともかく
助詞で切るのが打ちにくいというなら飛鳥そのものが
打ちにくいと言ってるのと変わらん

555 名前：名無しさん[sage] 投稿日：2008/08/11(月) 12:21:29 0
「かもしれない。」はやたらと使用されているだけで、
言い切ってないわけではなかった。スマソ。

556 名前：名無しさん[sage] 投稿日：2008/08/11(月) 13:30:19 0
作者はだらだら長い文末の言い回しがすらすら打てると言ってるが
作者が想定した文末はですます調ではなかったか？
「かもしれません。」ならサクっと打てるという話なら使う人の問題になってしまう

(from http://pc11.2ch.net/test/read.cgi/pc/1174639472/552-556 )

　このあたりについては、手元に「それを証明するための論理・データを持ち合わせていない」のです……と、現状ではこのように回答させてください。
　全体効率が「(数字的にも)悪くなる」様なことであれば、まだ測定などによる証明が可能かもしれないのですが、私が今回気にした話は「(使った場合の主観として)悪くなるように感じてしまう」ということなので、現状ではどうしても歯切れの悪い物言いしかできないという事情があります。

　こういうところについては、近年の「(飛鳥に限らず)手動での評価打鍵をもとに調整されてきたけん盤配列」をお使いになる方がだいぶ増えるなどしてから、その時点で大規模アンケートを行ってようやく答えが出るのではないだろうかと考えています……最近覚えたばかりの言葉なので使い方は変かもしれませんが、たぶん「帰納法で先に仮定が成立する状況にならないと、演繹法での表現が出来ない」のかも。
　仮説の真偽を証明する方法が手元にあれば、今すぐにでも確かめてみたいという衝動に駆られるのかもしれません……しかし、いまはまだそういうリソースが確保できそうにありませんので、なかなか断定するには勇気が要ります。

　日本語入力に対する本格的なけん盤配列の検討が始まってから、もう四半世紀を越える年月が過ぎています……が、逆に言えば「たかが四半世紀しかやってない」ともいえるのかもしれません。
　四半世紀前の技術に対して正当な評価を行うこと、そして今後の四半世紀にむけて正当に評価されうるけん盤配列を作成すること＆正当にけん盤配列を評価する方法を見つけていくこと……そういった技術も必要になってくるはずです。
　そのためには、けん盤配列の評価について「1980年代の技術ではなく、現在の技術で」解析してあげることが必要なのかも……こういったところは作業分析そのものを職業とされている方による解析を待っていられるかどうかわからないので、私としては「素人なりに調べてみる」つもりでいます。

　Rayさんが「ですます調を優先」した……というのは、それが「ですます調だけを優先した」というわけではないのかも、と考えていたり。
　新JISかなで「だ。/(であ)る。」を打つときのような右手依存シーケンスで、飛鳥でも「だ。/(であ)る。」を処理していたりしますし。
　私の日記では、いつのころからか「ですます調の優先ルールを排除」したのですが、それをやったからといって打ちやすさが損なわれたりはしませんでしたので、実際にはもっと広い範囲での検討が行われていたのだと思います。
　#探せばどこかには、一つ一つの検討結果が書かれているはず……なのですが、毎回探すたびにひどい思いをしているので、本件ソースの例示要求については勘弁してください……。

557 名前：名無しさん[sage] 投稿日：2008/08/11(月) 13:49:42 0
そもそも日本語が間違ってるんだよ。
英語なら「must」の一音節で済むような」使用頻度高い基本概念を表現するのに、
「なければならない」という八音節が必要なんて、効率が悪すぎる。
概念に対する音声の割り当てのレベルから考え直したいね。

558 名前：名無しさん[sage] 投稿日：2008/08/11(月) 14:04:10 0
つまんない釣りだな。

559 名前：名無しさん[sage] 投稿日：2008/08/11(月) 19:02:05 0
must　→　やれ

(from http://pc11.2ch.net/test/read.cgi/pc/1174639472/557-559 )

　【{し|され}なければならない】とか【{する|される}必要がある】とすると、確かに長ったらしいような。
　長ったらしい表現が必要だということは、そもそも「日本語で使うには使用頻度の高い概念ではない(orもとからあった概念ではなくてあとから輸入してきた概念である)」のかもしれないですね。
　音声言語の改定とか、あるいは音声言語の表記系改定といった話題については、「既存の音声言語/表記言語を、いかに打ちやすいカタチに折りたたみながらけん盤配列へと落とし込むか」というけん盤配列スレッドの方向性とはベクトルが異なるようなので、言語系スレッドで話題を展開されるのが望ましいと考えます。
　【{し|され}なければならない配列】の設計が必要……というのであれば、それは「よろしければ〜」スレッドで話題を展開されるのが望ましいでしょう……いずれにせよ「単独配列関連スレッド」で展開するには、話題の範囲が広すぎるように思います。

　仮にわたしが【{し|され}なければならない】という表記を頻繁に用いなければならないような状況に追い込まれたら……うーん、特に対策はしないかも。
　あるいは、そういう語彙の入力効率をどうしても必要とするのならば、ワープロ速記や速記系けん盤配列への移行を考慮するほうが適切なのかもしれないですね。
　大和言葉の入力コストを下げにくい……というのは、非速記系入力法に共通の課題ではあるものの、特定の言い回しに対してのみ最適化を図ることが許されるのならば、それに対して調整をした私製入力法を作成して逃げるという方法も、あるいは選択可能なのかもしれません。

　ちなみに、かえであすかを用いて【なければならない】【必要がある】と打つには……以下のような感じ。*2
　#かえでレフティあすかではBキーを軸にして29個の文字キーを左右反転し、シフトキーも逆にする……のですが、シフトの変移関係はそのままになります。

かな文字　　なければならない
文字キー　　Ｄ：ＥＰＤＦＤＫ
シフトキー　→　→　→→→　

かな文字　　ひ つ ようがある
文字キー　　Ｘ Ｌ ＩＤＭＤＪ
シフトキー　← → ←　←←←

　パッと見たときには「なければならない」というのは打ちにくそうだなぁ……と思ったのですが、意外と漢音を交ぜた「必要がある」よりもシンプルなんですね。
　過去の日記を見ても、「なければならない」と「必要がある」はあまり区別されずに、両方とも使っていましたし。
　ややこしいシフトの変移を伴うものは前半のみに集中していて、後半はシフトの連続で処理されている……というのが、いかにも飛鳥系らしいというか。
　#基本的に「飛鳥カナ配列のかえで化」ではシフト変移がらみの設計をあまり弄っていないので、ほとんど飛鳥の特定版が持つ特性を継承しているはずです。

　参考までに、飛鳥カナ配列の21世紀-364版(Rev.8)での打鍵例も示します。

かな文字　　な け れ ば ならない
文字キー　　Ｄ Ｘ Ｅ Ｚ ＤＦＤＫ
シフトキー　→ ← → ← →→→　

かな文字　　ひ つ ようがある
文字キー　　Ｚ Ｌ ＩＤＤＥＪ
シフトキー　← → ←　←←←

　うーん……本流の新版では「なければならない」の打鍵コストが上がるみたいですね。
　どんな表現を頻繁に使うのかによって、配列にも微調整が必要になってくるのかも。
　……親指シフトらしく「きちんと同期打鍵すれば」シフトの変移はどうということなくこなせるのかもしれませんが、私にとっては「なんとなく打鍵するだけで出てくれるほうが嬉しい」ので、とりあえず「かえであすかの改定はしない」方向でよさそうだな……と感じていたり。

　私にとっての親指シフトは、実際のところ「同時打鍵であること」にはあまり関心がなくて、「シフト遅れの補償機能が付いていれば、あとはただ押しやすい位置にシフトキーでありさえすれば、それでいい」という感じです。
　そんなラフな考え方だから、BTRON(超漢字)のような実装とか、あるいは「タイムシフト」のような新JIS論文方式の近似スタイルは全然許容できるのに、逆にシフトの変移が左右間で頻発するということがあるとツラいんですよね……。
　根本的に使い方を間違っているのかもしれませんが、私にとって「飛鳥系がラクに使える」と思う理由は、そういうところにもあるのかもしれません。

*1:出現頻度そのものを弄ると、GA系配列作者さん同士での検討に支障が出ると思う……ので、出現頻度に対して付加するフィルタ(倍率データ)として、別に用意して共有できるようにすると良いとおもう。

*2:2008年8月12日1:18:13追記……シフト→もう片方のシフト、というシフトシーケンスでは、シフトミスを明示的に回避する必要があるため、私は現状で1/2打鍵分程度の無打鍵時間を挿入しています。これを忘れるとシフトミスが頻発して、かえって修正ロスが大きくなってしまうんですよね……。そういう絡みから、例示については半角スペースによって区切りを挿入することにしました。きちんと打鍵できる方でしたら、この半角スペースに相当する無打鍵時間の挿入は不要だと思います。