人は、どうやって指折り数えるのだろうか。

(関連:http://gohan.wotaku.jp/typing/576)


　この記事を拝見してからコメントするまで、実は数日悩みました。
　私なりの答えは、結局以下のような感じかなぁ。

パターン 左小 左薬 左中 左人 左親 右親 右人 右中 右薬 右小
[R]前置 0 9 8 7 6 1 2 3 4 5
[L]前置 5 4 3 2 1 6 7 8 9 0

　内部処理で使うなら「どちらの親指から数えるか｣なんて気にしなくていいので、どちらか片方だけを採用すればいい……と思うのだけれど、どちらの手から数え始めるのかは人それぞれだと思うので、ＲかＬを前置して区別できるのが一番適当なのかも……と。
　ちなみに私は、ここで言うところの「Ｒプレフィックス」で数えている……のだけれど、こういうのって地域によっても差異があるのかなぁ……。


　ちなみに、「かえであすか」で従来私が【R{d}jflklj】と表現していた打鍵列だと、この例では以下のように表現する必要があります。

  • R18 274342 (または、R1{8}274342)
  • L63 729897 (または、L6{3}729897)

　プレフィックスシフト、もしくは同期非連続シフトな入力法であれば、スペースもしくは中括弧による「シフト打ち切り表現」は不要。
　で、普通のシフト、文字キー同時押し方式、もしくは同期連続シフトな入力法であれば、スペースもしくは中括弧による｢シフト打ち切り表現｣が必要になる、と。
　……って、中括弧では「シフト打ち切り表現」を表すために２文字必要だし、(連続シフト前提の配列でもない限りは)直感的じゃないんだよなぁ。結局はスペースで区切るのがシンプルかな。


　それにしても、こういう話題って、基本的に「運指法とけん盤配列が切り離されていて、各人が自由に運指法を規定できる入力法」でしか面白みを得られそうにないところが、個人的にはちょっとつまらないなぁ……という気も。
　……ああ、そうか。アレに対してこれを使って表現すればいいのか。

「かえであすか」と「かえでライティあすか」との違いについて。

　「かえであすか」と「かえでライティあすか」では、けん盤配列はまったく同じものの、一部の運指法が異なっています。
　以下に、Qwerty配列での文字キーに対する運指法の違いを示します。

配列名 Shift z x c v b
かえであすか[R] 0 0 9 8 7 7
かえでライティあすか[R] 0 9 8 7 7 7
かえでレフティあすか[L] 5 4 3 2 2 2

　#かえでライティあすかを使う人は「右親指＝１」として、またかえでレフティあすかを使う人は「左親指＝１」として数え始めるだろう……とか勝手に考えて例示しています。


　んー……これでいいのだろうか。ちょっと不安。

個人利用目的のけん盤配列には、「効率のよさ」も「スタンダードであること」も関係ない。そこに必要なのは「しっくり来るかどうか」と「指が痛まないかどうか」だけだ……あとは「一度覚えた方法が、これからも末永く使えるかどうか」かなぁ。

　……って、こんな乱暴な結論でいいのかなぁ。
　いや、デバイスを限定せずに語ろうとするなら、これ以外には答えなんて存在しないような。


　結局、鈴見咲さんによる

が「私自身がずいぶんと悩んでいた感情に対して、ほぼ唯一しっくりと来る代弁をしてくれていた」ことが、この結論に至るきっかけになったように思います。
　で……一般的に、不安でたまらなくなるのは

  • 「いま私自身が使っている入力法が、将来使えなくなったらどうしよう？」

という、その点のみに集約されるわけで*1。
　この手の感情を抱いたときに、ウザい人たちは短絡的に「オレサマが使う方法だけがJIS規格化されていて、それ以外は殲滅してしまうべきだッッッッ！！！」とかいう極論を吐いたりする*2のだけれど、それってどーよ？何か変じゃねーの？と疑問をぶつけてみたくなる私が、今ここにいるわけで。
　20年前の8bitワープロ専用機でさえも複数の入力法をサポートしていたというのに、21世紀の今になって「HID関連システムが退化していく」というのは、ちょっと微妙だよなぁ……とか考えてもみたり。


　私は実際、いま【かえであすか配列】を使ってます……が、世間の事情が違えば、たぶん他の入力法を使っていた(or作っていた)はずです。

　当時既に、JISかなに回帰するのは無理だっただろうし、NICOLAかなは4ヶ月でコケたのでこれも無理、と。
　そのほかの入力法で……というと、たぶん以下のようになるのだと思う。

  • 新JISかな(SandS)。
    • 先に論文を見ていたら、たぶん惚れていただろうと思う。
  • 月配列2-263。
    • 正直、あんなによく出来てるってことは、後から思い知らされたんですよね……ちょっと悔しい。
  • 月配列Ux(U8以降)。
    • 飛鳥がなくて、ポストフィックスシフトな「かえで配列・もみじ配列」のテスト直後だったら、たぶんUxを選んでいたと思う。
  • 月配列4-698。
    • 「こなとけろ　むるいのれめ」なアレ。GA系をはじめから信じていたら、たぶん飛びついたと思う。実際驚いたし……。
  • 小梅配列。
    • 出現順序が逆だから無理だよなぁ……と思うものの、そうであったとすればNICOLAから乗り換えたと思う。

　だいたい想像できる範囲では、このあたり……だろうと思う。
(from (メモ)私が「かな系」に回帰しようとしたときに、「飛鳥カナ配列」が存在せず、かつ「○○配列」が存在していたら、たぶんそれに慣れていたんだろうなぁ……と思うものリスト。 - 雑記/えもじならべあそび)


　そういえば……こういうところは、「工程改善と作業改善の違い」にもあらわれているのかも。
　工程改善って、全体から見れば「改善」であっても、個々人から見れば「改悪」でしかないことがままある……のだけれど、工程改善をせずに「作業改善だけをやって、それを適当に運搬してつなげば、まぁどーにかなるんじゃねーの？」みたいな無茶苦茶なことをやったら意味がないわけで。
　工程改善ってのは、作業改善したい人にとっては「制約」でしかない……という意味では、日本語入力法にたとえると

  • 工程改善──キー入力入れ替えツールと、そこからハードウェア側。
  • 作業改善──キー入力入れ替えツール用定義と、そこから人間側。

とかになるのかなぁ、と。
　もちろん、配列が決め打ちされている場合には、若干条件が変わって

  • 工程改善──入力方法と、そこからハードウェア側。
  • 作業改善──運指最適化と、そこから人間側。

となりそうなのだけれど。


　……まぁ、会社で無理やり入力法を覚えさせられるなら、せめて満月配列とかにしてほしいです。
　定義を８０とか９０も覚えなきゃ使えない方法では、とても覚えられる自信がない*3ので……。

*1:実際、私は(普段使いの配列なんて、また新しいのを作り直せばいいのだから……という感じで)「Qwertyローマ字入力」を保険代わりに温存してるから、それが廃れない限りはどーでもいいと思っている……のだけれど、個人的な予測では「20年後のシェアが見えない」ので、そのあたりでの不安は確かにあるんですよね……。

*2:技術的な問題を無視すれば「どの配列を排除しようとするのも暴論」というべき……なのかも。技術的なところを含めると、特に個人的には、「JISかな廃止論」が一番の暴論だと感じています。JISかなが死んだら「(JIS X6002＋JIS X4064＋JIS X4063の複合技で処理している)あかさたなキーボード」さえも含めた、数多くの「イネーブルハードウェア」が被害を受けるわけで……とっくの昔に「JISかなはJISかなユーザーだけのものじゃない」状況になっているのに、そういうところについて気にも留めていない方がいるのだろうか……というところが、個人的にはとても心配です。

*3:飛鳥カナ配列では「低頻度濁音・半濁音・小書きかな」のうち比較的多くを完璧には覚えられなくて、それを解消するために「かえであすか」を作ったような状況でしたし……。

親指の付け根で圧迫し、人差し指と薬指で解放し、中指の腹でアクセスする……とか。

(過去:(TitleOnly)やっぱり俺には「Ｂ下割れキーボード」が向かないらしい……。 - 雑記/えもじならべあそび)


　ホントはこのタイトル、もともと【人差し指と薬指には「中指を中心に鏡像となるような、等価の負荷」が望ましいのではないか……とか、そんなことを考えてみたり。】だった……のですが、なんとなく変更してみたり。


　HIDのうち「人間側」として捉えていた「手指や腕」について、ふと考えてみると

  • 「手指や腕」は確かに、出力用のインターフェースである。
  • でも、「手指や腕」は出力時に「感触を捉える入力側の」インターフェースでもある。
  • そして、手指や腕などは「人間に触れる」ための出力用インターフェースでもある。

……とか、そんなことをあれこれと考えていたり。


　マウスを触れるときの行動にしても、この絡みで考えていてようやく

  • 普段は、「右手の人差し指と中指」で2ボタンを担当してる。
  • タバコ片手に作業してると「右手の中指と薬指」で2ボタンを担当してる。
  • マウスホイール操作時は「右手の人差し指と薬指」で2ボタンを担当し、ホイールは中指で操作してる。

ということに気づかされたり。
　

　……と、３回も「〜たり。」を使うのは微妙な感じで、ようやく考えが飛散していることに気づいて、とりあえずこのネタは放置しようと考えたわけで。
　でも、HIDと性の間には、すくなからず関連性があるような気もするんですよね……。
　話題が下品な方向に行くのはちょっと考え物……なのだけれど、そのうち避けては通れない時代が来る*1のかも……。

*1:ここでエロ話を展開することはアリエナイ(てゆーか意味がない)にせよ、そこにHIDとしての「あるべき姿」があるのならば、結局は完全回避を試みても無駄なのかも、と思うんですよね……。

(作業メモ＋追記済み)「タイプウェル適応○○○配列」向けの検討事項。

(過去:自分のBlogにおける「ひらがなの出現頻度」を、パソコンを使って調べてみよう！(kanji2na＋morogram編、244万文字頻度付き) - 雑記/えもじならべあそび)

  • http://typinger.hp.infoseek.co.jp/typing/study.html で公開されている、Typewell国語Rの単語列に対するn-gram分解。
  • GAの使い方がわからない……ので、(時間があれば)手作業配字試験をする。
    • 特に、月配列系を中心とした、中指シフトのカナ系……だろうなぁ。ほかに最適解が取り出せそうな配列群が見つかるアテはない気がする。

(2009年2月8日14:58:31追記)1-gram解析をしてみた。

　2-gram解析とかをしてもスカスカになりそう……なので、1-gramのみ。グラフをクリックすると、何とか読めるサイズには大きくなるはず。

  • 「くつちらる」が若干多め。
  • 「がてでにのは」が少ない。
  • 「ぅぉを、。！？」とかはそもそも存在しないので、Typewell適応配列からは除外してもいいでは打鍵性を無視していい(将来使われる可能性がゼロではないので、除外はさすがにやりすぎかも)。

　……わたしの日記自体も偏ってるから、単純に比較するのは誤りなのだけれど、Typewellのそれはまるで「高校教科書のかな出現頻度から拾った」みたいに、比較的固めの文章に合うような選語がなされたように見えるところが不思議だなぁ、と。
　#たとえば、おなじ月配列系でも、オリジナルに近いほど向いていそうな気がする。


　すごく意地悪なことを言えば、「【標準運指×右利き×Qwertyロマかな】にとって苦手なところを微調整で落としてる」ッぽく見えてしまう……のだけれど、これってそもそも「文章ではなく単語を打つ」ソフトウェアであるために、自動的に発生してしまう(＝Typewellのやり方ではそもそも回避できない)問題だからなぁ……。
　このくらい偏っていると……1-gram〜3-gramを見つつ「Typewell適応月配列(GA)」を作ることによって、「Typewellでの最速を目指すためだけのけん盤配列」は設計可能だと思います。
　とくに3-gramクラスになると、

  • そもそも、語彙が2155語しかない。
  • 膠着語としての体裁をなすために必要な要素が欠落している。

という部分が非常に響いてくるので、たとえば小梅配列における「そろそろやめさせろ」問題とかのような、ややこしい問題をほとんど潰してしまうことができる……と。


　……もっとも、「タイプウェル適応○○○配列」としてだけ作ってしまうと、実用上は使い物にならないんですよね……実用でも使えるようにと色気を出すと、とたんにややこしいことになりそうなあたりは微妙。

(2009年2月8日16:19:42追記)ごめん、わたしが馬鹿だった……。


　タイプウェルにおける「ひらがな下し」単語のワード長さは、平均で3.68文字/wordでした。
　こいつがCRLFでセパレートされ、2155語/file収録されて、全体の容量が10082かな/file(CRLF込み)でした(注:Shift-JISコードで数えています)。
　……ってことは、文中にCRLF(＝全角空白と等価の数)は2155個入っていて、当然これはタイプウェルにおけるセパレータとして「Spaceキー」を押すことになります。
　このとき、セパレータの打鍵比率は全打鍵中の21.379%にものぼるわけで……これを親指で打つべきかどうか、という点については考慮しなきゃいけないと思います。
　もしも文字キー領域にセパレータ(Space機能キー)を収めるのならば、間違いなく「E＋I」もしくは「D＋K」キーの1等地に重複割り当てなきゃダメなレベルですね……このとき、物理的なスペースキー自体は「JIS X6004方式シフト」もしくは「スペースキーによるプレフィックスシフト」用として使うことになりそうです。
　#ただし、10.69%/指の打鍵頻度が掛かることを考えると、とてもじゃないけど「両親指以外に耐えられそうな指がない」気もします……が、このあたりは「タイムアタック用と割り切って使う」のならば、まぁなんとかなる……のかなぁ。安全性に問題がある配列は作りたくないから微妙なのだけれど。

(2009年2月8日19:11:48追記)

　あの「月配列(GA)4-698」を生成したプログラム( http://www.geocities.jp/rage2050a/GeneKana/ )を使わせていただいて、清濁分離配列の生成……じゃなかった、選別を試行中。
　ほんとはn-gramで被りが生じる「長いn-gramと、短いn-gramでの重複加算を補正する」処理が必要……なのだけれど、今回選出した配列を使う場合は【Typewellに出てこない単語は一切打たない】という前提条件があるので、むしろn-gramを被らせたままにして「ワード最適化」を強く出す方向へと振ることにしました。
　打鍵速度データはそのまま使わせていただくことにして、1〜6gramのデータだけをTypewellJRのものに差し替えて、ただいま計算中……かなり時間が掛かりそうですね。
　計算中は特に行動しない予定。

(2009年2月8日19:36:16追記)

　Pentium-M(1.4GHz)ではあまりにも遅すぎる……ので、とりあえずPen4(2.8G)の機体で始めからやり直し中。
　#でも、この手の処理ってPen4は苦手そう……なので、PenMノートの方も止めずに、2台同時で走らせることに。


　あと、「GeneKana0723」の使い方は……極めて不親切に書くと、こんな感じ。

  • GA選別パッケージをダウンロードして、さくっとアンパックする。
  • フォルダngramの中に、「半角かな下ししたTypewellJRのテキストを、1〜6gram処理して降順ソートしたもの」を突っ込む。
  • GeneKana.iniの中身を、↑の通りにテキトーに編集。
  • GeneKana.exeを起動。
  • Ctrl-Nで、テキトーな文字を打ってEnter。
  • Ctrl-Sで、テキトーなファイル名をつけて保存。
  • Alt-Pしてから、スライドバーを「右端」に動かす。
  • Alt-VしてからEndを押して、表示番号を257(自動追尾)にする。
    • ここで↓を押すと、256(現時点の最高記録)を表示する。
  • プログラムが走ってないときは、F5(Run)を押す。

　……あとは、ひとまず放置プレイで行くしかなさそう。

(TitleOnly)ただいま「タイプウェル(Typewell)用のけん盤配列」を、2台のパソコンが計算中です……。

(過去:(作業メモ＋追記済み)「タイプウェル適応○○○配列」向けの検討事項。 - 雑記/えもじならべあそび)
(元ネタ:http://typinger.hp.infoseek.co.jp/typing/study.html)
(元ネタ:rage2050)

　……って、うまく行くかどうかは解らないけれど、とりあえず「月配列(GA)4-698を生成したGAプログラム」と「TW国語R基本常用語ver2.1.0出題語句リスト(txtファイル)」を使わせていただいて、【TW国語R基本常用語ver2.1.0適応の月配列(GA)】を自動探索中です。
　この実験では、次の2点についての知見が得られる可能性があると期待されます。

  • そもそもGAアルゴリズムを使って作る「月配列(GA)風味のTWJ適応カナ配列」が、本当にTypewell(J)で使い物になるのかどうか。
  • 「月配列(GA)風味のTWJ適応カナ配列」が、TWJ以外の用途──とくに自然文入力──にとって使い物になるのかどうか。

　特に後者は重要で、TypewellJの打鍵練習が「自然文打鍵と悲観比較したときにどういう癖を持っているのか」を知るために、役立つ可能性があります。
　過去に【(作業メモ＋追記済み)「タイプウェル適応○○○配列」向けの検討事項。 - 雑記/えもじならべあそび】で挙げたとおり、単語の選出頻度は「ちょっと偏ってるけど、1-gramで見た限りでは、固めの文章に偏った程度の話……と言っても差し支えなさそうに見える」のだけれど、ぱっと2〜6gramを見ても捉えようがないので、そういうところは「月配列(GA)風味のTWJ適応カナ配列」というフィルタ配列を通して観察するほうが、よほどわかりやすいのではないか……と考えています。


　ただし、Typewellに限ったことではないのですが、真面目に「月配列(GA)風味のタイピングソフト適応カナ配列」を作ろうとする場合は、たぶん「清濁分離配列」よりも「清濁分置」のほうが、最適化の効果が出やすいものと思われます。
　そういう意味では、今回生成されるであろう「月配列(GA)風味のTWJ適応清濁分離カナ配列」だけではなく、「月配列(GA)風味のTWJ適応清濁分置カナ配列」も必要になるはずです。
　#複雑な運指最適化を各人が作り出すのではなく、その代わりの役目を配列側が負う……と、これは近年のけん盤配列にとって「当たり前の役目」なのだけれど、こういうプロセスアプローチが「タイパーさんにとってウケるかどうか」は微妙かも……と、そっちのほうがむしろ心配。


　もともとタイピングソフトへの最適化を試みる実験は、(わたしが知ってる範囲では)Ｕジローさんによる「月配列Ux版」が発祥……のはずで、ごく最近では「Yeah配列」が登場していたり……という状況なのですが、このあたりについての新しい候補が今回見つかってくれるといいなぁ……とかいうことも考えていたり。
　本来、GAのような方法を使ってTypewell攻略？を試みるのは「明文化はされていないにせよ、明確なチート」だと思うのだけれど……こういった行動を通じて「(ワードセットの癖にかかわらず)チートされにくい＝そもそも自然文に近いn-gram出現頻度を持つワードセットに対する打鍵技術を要求される」タイピングソフトが主流になってほしいという思いがあることは、隠すことなくここで表明しておきたいと思います*1。
　うーん……こういう考えって「ひねくれている」のかなぁ。ただ、膠着語の一つである日本語を扱うタイピングゲームにとって「越えなければならない壁」であることは、たぶん確実なのだと思います。

*1:ここがクリアされないと、「自然文打鍵には適していても、タイピングソフトでの打鍵には適していない」けん盤配列が、あまりにも可哀想なんですよね……。

月配列(GA)風味のTWJ適応カナ配列、現時点での速報。

(過去:(TitleOnly)ただいま「タイプウェル(Typewell)用のけん盤配列」を、2台のパソコンが計算中です……。 - 雑記/えもじならべあそび)
　キー位置＆シフトモードの表現に【Dvorak英字配列】が用いられている……という前提のみを頭に入れておけば、すんなりと読めると思います。

　【゛】【、】【。】【「】【」】あたりの位置は固定されています(詳しくはドキュメントを参照)。
　この先、どういう配列がトップランナーになるのか……しばらく待ってみようと思います。

(2009年2月8日21:22:34追記)なんかヤな予感がしてきた……。

　もしかすると、「どんな場合であっても」n-gramの重複は除去しなきゃまずいのかも。
　「い」がシフト側にあるってゆーのは、さすがにどうよ……と不安になってしまうんですよね……。