「現在の技術では関数を作成するよりも実物を手作業で作成するほうが現実的」……という訳でもなさそうな気がしてきた。
(過去:「(習得時に)負担の少ないキー配列を!」という考え方。)
ええと……私、4日前にこんなことを書きました。
ちなみに、1990年代以降に設計された「個人製作の」入力法(かな・ローマ字などの入力種別を問わず)では、ここからさらに一歩進んで「文字の連なり具合について、計算による仮想最適化のみではなく【自分の指で評価打鍵して、指が痛くならないように】徹底的なチューニングをしつつキー配列を設計する」手法も普及し始めました*4。前出の「月配列」をはじめとして近年発表されているキー配列はおおむねこの方針で設計・評価されており、最もとんでもない例としては「制作期間2002日の飛鳥カナ配列」のような例すらも存在しています。エルゴノミクス関連の技術をコンピュータで扱える関数へと変換するのは容易ではない(現在の技術では関数を作成するよりも実物を手作業で作成するほうが現実的)こともあり、この状況はしばらく(少なくとも四半世紀程度は)続きそうな予感はします。
(from http://d.hatena.ne.jp/maple_magician/20061021/1161430509 )
……で、昨日こういう配列が公開されました。
698 名前:461[sage] 投稿日:2006/10/24(火) 22:43:52 0 GA評価関数で、ボトルネック計算に間違いがあったのを修正して、 たぶんこれが最終形…だと思う… こなとけろ むるいのれめ たて★かは っん★゛しー すょせきさ くう、。゜・ <★シフト> ぁねゃほゆ ぬわあにぇ「 ぃおらもふ やつまちえ」 ぅゅそよへ みりひをぉ(from http://pc7.2ch.net/test/read.cgi/pc/1139243753/698 )(from http://pc7.2ch.net/test/read.cgi/pc/1139243753/698-701 )(2006年10月27日1:25:19訂正)
手元にある「かな連なり頻度」と比べてみました。
基準の前に連接しやすい文字→ | 基準 | ←基準の後に連接しやすい文字 |
---|---|---|
もいしらうがけだつさせとたかはなて | い | れうまてたるのかでしとはんなにきっ |
つすろまおもゆのとそほこいどゅよょ | う | かしにじりでがなこのいきとほはてさ |
てじかっ、をるしになとのいつんすう | か | んいらなもくのっえ、。したとかには |
しーくつされ」たのなちきいとうすん | が | 、いあつなえしでおわかっすよ。きら |
おやていすこゃぞつさそたとっなかょ | く | しなにはてとさだじの、でりをすらる |
のをかじなにくびてもでたといまんう | し | てたょふまゅんかきいゃれな、よはく |
とにをひ。のー、きくなはいまもうん | じ | ょゅにしだかつできっめをゃたてんぶ |
つり。はしとゅかせいひじうがをにれ | つ | かいはによくのでを」うとがしづもな |
つでくて」きとそこたかうるもなんい | の | でかはうきこし「もにだほがみとまよ |
なーるしをれかくつうとんのいてにで | は | い、な「んじあずこしかっきまおた… |
ふにがしのつすくいうんひだじとこた | め | んいにてよーしるのもでりだかたな、 |
いづさえきあうこわんがとちくたなか | ら | い、なれんしっくばのかはずにべがみ |
めとかわよてみけくえーきれなあいす | る | とのこか」いよ。にはだきほたべなし |
とだけかきあなくわすおらしそさこい | れ | つてばるんまいはなたでにがをかーっ |
ほたはこぶめなへしいさてにげせけか | ん | しでがとにかじのだはなをきすてさ。 |
……GA、というか計算配列の特性として「一定のテンポで(日本語的な間の取り方をせずに)打ったときに最短になる」という癖は出ているものの、それが特に悪い方向に作用してはいないように見受けられました。というか、むしろ「色々なストリームに対して平等になるよう割り振っている」から、定テンポで打鍵したときにとてもスムーズに打てそうな……そういう印象を受けました。
「コンピュータで作った配列」とはいっても、その基礎は「延々とキーを打鍵しまくって採取したキーログ」が基礎となっているのですから、そう言う意味では「人間が打ちまくって評価打鍵をする」部分のうち「疲労には関係しない部分」についてはきちんとGA段階で評価打鍵できている……と、そう考えるのが妥当なのかもしれません。
JISX6004が設計された時代と比べれば計算資源にだいぶ余裕が出来たこともあり、「高頻度=表、低頻度=裏」と決め打ちせずに済むようになったことも、あるいは影響し始めているのかもしれません。
一番おいしいところは右手下段に「う」を置いたことと、右手上段に「るいのれ」の順で来たことかも。
見かけ上キツそうに見える「いう・うの」が、飛鳥で言うところの「とっ・っこ」の運指と同じなのですが、これって慣れてしまうと十分快適に打鍵できる範囲なので、この処理の仕方は巧いなぁ……と思いました。
そこに「るいのれ」がかかって、右手で絡みやすい運指がきれいに解消されている……と。
それと、個人的には左手の「は」と、右手の「っくん」の置き位置が良いなぁ……と、なんとなく思いました。はじめは「もっと弄れるのかも?」と思ったのですが、今の状態が一番しっくり来る様ですね。
「つ」がシフト側ホームポジションに行ったことで打鍵数は増えているはずなのですが、「T:ろ、Y:む」と低頻度文字を配置することで「指の行き戻りに要する時間」をバッサリ切り、かつ「R:け、U:る」に中頻度文字を配置して同効果を引き上げる……と、こういった処置をすることで「早くホームポジションに手を戻して、さっさと中指シフトを掛けられるようにする」仕掛けが巧く回っています。
中指シフト配列では「如何に低コストで中指シフトキー位置に復帰できるか」が入力速度を上げる&疲れずに入力し続けるための肝であり、かつ「中指は一番長いので、上段全域に高頻度文字を割り振るのではなく、指の形に添って高頻度文字を分布させる方が、移動距離を圧縮できる」ので、結果としてこういう配列がGAで選定されたのかも……と、そう予測してみたり。
わずかな打鍵増を殊更に心配する必要はないような気がしました。
たぶん、打鍵数が増えているにもかかわらず「指の移動距離自体は短く、手のひらを動かす範囲も狭く」なっているはずで、親指をほとんど左右に振らなくとも(=親指を使ったホームポジション探しが容易に出来る状態を維持しつつ)打鍵できそうな感じです。
中指シフト系配列の「新しい可能性」が見つかった……のかもしれませんね。
鍵盤上の文字ならびに依るならば「無類の*1」中指シフト配列に至る可能性を秘めた、興味深い内容だと感じました。
既に打鍵評価されているようで、今後の進展が楽しみです。
#一目見て、あやうく惚れそうになってしまったのは……ここだけの秘密で^^;。
(以降は2006年10月25日23:49:36の追記分です)
ぱっと見たGA法の利点。
- アルペジオと交互打鍵へと意識して振り分けなくても、それなりに(手作業で日本語というパズルを解くよりははるかに高速に)振り分けて、良さそうな手を見つけることが出来る。
- 「全配列中最も最適な配列を見つける」ことは出来ないが、「(たくさんあるピークの中の)特定のピークから中心値を見つける」ことが出来る……しかも「現実的な」時間で。
- 初期配列の考え方をうまく生かした最適化が可能である(初期配列が特定ピークの中腹〜上部辺りにある場合)。
単純に考えられる応用方向、現時点で既にGA/総計算法の方が有利だと確信できる用途。
- 実際に多量の打鍵評価をすれば「確実に指を壊す」鍵盤──たとえば携帯電話用の10キー(親指打鍵)とか──用のキー配列を製作する場合。あらかじめGAで当たりをつけてから……というのが現実的な評価打鍵の限界だと思う。
今後必要になると思うこと。
- 色々な文章を評価打鍵してみて、「特に弱いと思った分野の創作文章を評価対象として加える→再計算」とか、そういう処置が必要になってくるかもしれません。清書後の文章は「推敲段階で弄られている」ので、むしろ「清書前の文章」っぽい(=普段バルクで打っている文体に近い)文章を含めるほうが良いのかもしれません……清書文の打ちやすさよりも、下書き文(会話文を含む)の打ちやすさのほうがはるかに重要ですし。
で、最後に。
プログラムを組める方が羨ましいです……orz
*1:この配列は、右手上段が「むるいのれめ」になっている。