Hatena::ブログ(Diary)

雑記/えもじならべあそび このページをアンテナに追加 RSSフィード Twitter

様々な文字入力手法を「運指動画」でご覧頂くことが出来ます。
「シャドータイピング50音順式タッチタイピング練習法」、ひっそりと公開中。
Advanced W-ZERO3[es]ctrlswapminiかえで携帯配列(圧縮ポケベル打ち入力)を利用中。
普通のキーボード用にNICOLA(親指シフト)を圧縮?した、「かえであすか」を利用中。
はてスタの色識別性が改善されるまでの間、私ははてスタ捨て場にカラースターを捨てます。

【注意】この日記に出てくる「運指(最適化)」という語はほぼ、タイパーさんが表現するところの
「ワード(最適化)」のことを指し示しています
……表現間違いをなくすために、現在訓練中です。

2006年07月31日 月曜日 かえでしきをいじる。

かえで式、「月配列(2-263)」「JISかな(JISX6002)」に対応。

(過去:かえで式、「飛鳥カナ配列(21c333)」に対応。)

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.ods


 月配列については……この表では苦しすぎますね^^;このままでよいものかどうか、かなり悩みつつ作成してみました。


 それと、JISかなは……運指を提示しないとどーしよーもないことに気づいて、とりあえず私が現状でやっている運指をもとに作成してみました。「ぁぃぅぇぉ」については左手小指外方のシフトキーで処理してもかまわない気がするので、その点についてはチラッと書いてみたり。「っ」については、昔の私のクセをそのまま持ってきました。


 どちらも私はこの表をもとに試す予定はなかったり……って、やっぱり試してみる方がいいのかなぁ。


今後について。

 表の規模を考えると、「月配列3-385改」のような拗音シフトつきの配列を表現するのは難しいように思います。

 いや、出来るとは思うのですが、かなり縮小されて見づらくなりそうなんですよね。

 同じ理屈で「ナラコード」の表現も無理だろうと。拗音拡張を無視しても良いのであれば通常通りにいけそうですが、それじゃナラコードらしくないですし。


 もしも「月配列(2-263)」の表現方法で解りにくくなければ、「月配列Ux版とその派生版」はほぼそのまま、「星配列」は飛鳥の様に清濁分離にして、それぞれ表現可能かな、と思います。

 「チョイかな入力」については正確な配列を知らないのでなんともいえませんが、秋月かな配列改4案4のような仕掛けであれば原理的には作成可能ですし、配列さえわかれば表の作成は(JISかなよりも)容易かと思います。


 とりあえず「○○配列の表を作れ!」というリクエスト希望しています。

 すぐに書けるわけではない(時間的にはすぐ出来るのですが、まとまって時間を取れないと作業がやりづらい)ので、最大1週間程度の余裕をいただく事になるとは思いますが……表現そのものに難儀するわけではないので、お気軽にリクエストをいただきたく思います。

2006年07月30日 日曜日 あすかをならうひび。

かえで式、「飛鳥カナ配列(21c333)」に対応。

(過去:小梅も練習してみた。)

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.ods


 NICOLA・小梅のような清濁同指配列ではないので、濁音は濁音だけで面を作ってみました。

 おかけで配列シートが見事に縮小表示されてます……見辛いッたらありゃしないですよorz


 それにしても、NICOLA→小梅→飛鳥と進むにつれて、段々と矢印が中段付近でぐちゃぐちゃになってくるのは困りました……。

 NICOLAでは楽勝だったのですが、小梅ではだいぶ混線しましたし、飛鳥に至っては線の対応関係をパッと見てもわかりにくい始末で……うーん、ちょっとこの方法はまずいのかもしれないですね。JISかなならば全然問題なくいけるんですけど……。

 それと、中指シフト系逐次打鍵配列については「シフトキーへの矢印を引かない(文字キーでシフト操作を指示する)」必要がありそうです。

 今のところ、文字キー同士同時打鍵方式のうち、親指・中指・薬指シフト同時打鍵以外のパタンも使用いる配列(姫踊子草配列・下駄配列など)についてはこの方法では表現できそうにないところも気になります……うーん、どうしようか。


 作成したはいいけど、ちょっと納得いかない部分があったので書くのが遅れてしまいました。

 

2006年07月29日 土曜日 あしもとをみないと。

WillcomのCMが更新されてる。

 http://www.willcom-inc.com/ja/gallery/cm/index.html

 がんばってる人に「がんばれ!」と言ってはいけない……という基本的なルールを無視してしまっている気がするのは、チョットまずくない?

 同じことが「働く」という行動に対しても言えるんですよね……うーん、単に捉え方がネガティブなだけなのかなぁ。


 ついでに、「働く」シリーズCMが高画質版になっているようなので、「通話無料・枕元編」も改善して欲しいんですよね……動画+音声の合計が181kbpsなので、音声部分は当然「ひしゃげた声」なのですよ。あれがWillcomの音質だと思われてしまうのは非常にまずいと思うのですが^^;、そのままでいいのだろうか。

で、ちょっとばかりCM言葉を弄ってみた。

お題は「豊かな国編」で。

豊かな国とは、

遊んで暮らせる国のことか?

メリハリつけて遊ぶために

今日はしっかり働こう。

ナレーション【働くWillcom es 誕生

A【働いてる?】、B【もちろん!】

シグネチャWillcom

「医割」?

 「学生向け割引」「高齢者障害者向け割引」なら聞いたことがあるけど、これはちょっと珍しいかも……「医療・福祉従事者向け割引」。

http://www.willcom-inc.com/ja/corporate/press/2006/07/19/index.html

W-ZERO3に内蔵のPDFビューアを始めて使ってみたけれど……

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf

 これの矢印(p3以降、キーを押す順番を指し示すために使っている)を表示させると、先端のみが表示されて線の部分が表示されないようです……orz

 

2006年07月28日 金曜日 いまはまだがまんか。

メモ。


 W-ZERO3アップデートPDFを安定して読めるようになる。

http://blog.goo.ne.jp/okapon_y/e/154b0121d9e6440d5d4974a098ed9e18


 W-ZERO3[es]のホットモックを触ってきた……文字は細かいけど予想の範囲内で、カーソルキーが画面中央に近づいて重心が安定している分「とても」操作しやすくなっている点がGood。

 かなめくり入力は「戻る」キーがないのはツラいけど、Qwertyキーボードでロマかなするよりはだいぶ楽だと思う。

 あとは側面にカーソルキーがあって「かなめくりの文字送り」ができれば良いのだけれど……。

 とりあえずは機種変時期に期待。

2006年07月27日 木曜日 れんしゅうあれこれ。

メモ。

http://k-tai.impress.co.jp/cda/article/news_toppage/29801.html

 アップデートしわすれていた。


 「しゃべるとおりに打つ」でも「書く様に打つ」でもなく、「思い浮かんだままに打つ」と表現する以外にないのかもしれない。

 ……ってコレ、どの入力方式でも当てはまるよなぁ^^;。

 うーん……「資源の再利用」の理屈を利用した漢直練習法があればいいのですが……ってあるわけないですよねorz

 さて、小梅の練習を開始しますか。

小梅も練習してみた。

(過去:かえで式、「小梅1.21」に対応してみた。)

 とりあえず、また1時間ほどシートを元にやってみました。

 基本的な練習法は全く変更無しなので、「小梅1.21」の練習をすると「NICOLA」の運指は完全に忘れてしまいます^^;。

 両者を平行して練習するということはまず無いでしょうから、まぁこれは別に問題ないかな……と。

 #逆に言うと、2つ以上の方法を同時に習得するには使えない、ともいえますな。

 少なくとも、「親指シフトかな系・同時打鍵のみ」の範囲であれば、今の「かえで式」のままで問題なくいけそうな感じです。純粋TRON配列(半濁点分離)や月配列系でどうなるかと言う点についてはまだ試していませんけれども。


 とりあえず「90個近いかなをばらばらに覚える」のではなく「14行×4〜10段のかなセットを覚える」方法なので、行段系入力法における「子音を固定し母音を変えて打鍵練習する」ことと本質的に等価な練習になるようです。

 母音位置が固定化されていないという意味では行段系よりも習得しづらく、逆に打鍵するべきキー数が少ない=運指動線が短い=S/N比が高いので、行段系よりも習得結果を定着させやすい様です。差し引きでほぼ等価ぐらいになると思います。

 #ただし、行段系のような「運指の使いまわし」は効かないので、初期を脱した後には差をつけられてしまうだろうなぁ……という気はしますが。


 ちなみに、練習シートPDFの1ページ目には、こんなテキストを突っ込んでみました。

Learn more simply

覚え方を工夫すれば、「かな入力」は「ローマ字入力」よりも簡単に覚えられるはず。20世紀常識をひっくり返すのが、私の仕事

 常識をひっくり返せるかどうかはもちろん解りませんけれども、「かえで式よりもさらにシンプルな方法」が出てくることを期待しつつ書いてみました(もちろん、私が作れるとは限らないわけですが……とりあえず)。

 他にも色々な練習方法を構築しうるはずでして、そのあたりについても考えてみたいなぁ……という感じで。

2006年07月25日 火曜日 こうめもおもしろい。

メモ。

 「しゃべるように打つ」は、本当に快適と言えるのだろうか?

 手書き入カでよく交ぜ書き変換をするけど、漢字とかなの交ぜ書きって、特に意識しなくても(手書きならば)できる(もちろん知らない漢字はひらがなで書くとして)。

 漢字と同じく「パターン」で、漢字よりも早く書ける「ストローク」を使うのだから、漢直も手書きと同じく「長くやっていれば自然に書き言葉もしゃべり言葉も書ける」と孝えるのが自然

ってゆーか、自宅で見直して気づいた。

「長くやっていれば自然に書き言葉もしゃべり言葉も書ける」と孝えるのが自然

 ……いやそれは「考える」だってばorz

かえで式、「小梅1.21」に対応してみた。

(過去:で、さっそくNICOLAで打っています。)

 ええと……管理が面倒になりそうな予感がしたので、1つのブック形式ファイルで全てをやることにしてみました。OpenOffice.orgで開けるシートと、そこから生成したPDFを公開しています。

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.ods


 ……練習する暇はありませんでした。ええ、すっかりと時間配分を間違えてしまったのですよ……orz

 それと、「あかさたな……」順での生成は取りやめました。ちょっとやってみたのですが、行をそろえる効果はあまりなく、かえって学習効果を阻害しそうな気すらします。

 ついでに、始点を指す矢印についてはNICOLA・小梅の両シートに付けてみました……かなり解りにくくなっているのは気のせいではないと思います^^;


 練習は明日(日が変わったから、今日の夜)に。

修正。

2006年7月26日2:19:24、ファイルコピーミス修正。

2006年07月24日 月曜日 もっとはやくならう。

メモ

 今日〜明日はNICOLAの練習をします……多分日記は更新しません。

で、さっそくNICOLAで打っています。

(参考:かえで式「NICOLA練習用テキスト」メモ。)

 掲示の配列シートを使って1時間、50音順練習を行ってみました。22時頃〜23時頃の1時間程度です。

 まるで携帯電話で「かなめくり入力」をしている気分ですが^^;、とりあえずは打てている様です。

 解らなくなったら「文字単位ではなく、行単位で練習し直す」と、かなめくりっぽく思い出せるので引っかからずに打てて良いのかも。

 ……かつて苦労した事は、案外無駄ではなかった……と思いたいくらいの違いに愕然としてみたり。

 なぜ始めからここにたどり着けなかったのだろうか。1時間ちょっとしか練習していないのに、過去の4ヶ月練習後よりもまともに(あんちょこに頼ることなく)打てていますよ……orz

で、速攻で飛鳥に戻す……と。

 とりあえず解ったことが。

  • 同じ暗記するにも、「ピクチャとして覚えてはダメ(というか意味がない・記憶力の悪い私のような奴には無理)」で、「指の動きで行を丸ごと(a-i-u-e-oと)たどる」方が、確実に楽。ピクチャ記憶は非運動性記憶だから人によって大きな差が出るけど、運指記憶は運動性記憶なので、若干曖昧になるという欠点はあるもののとても覚えやすい。
  • 同じあんちょこを使うにしても「毎回目で見て探す」のは「記憶ではない」のでダメ。一方で「運指群を忘れる度に目で見て一連動作をやりなおし、どれかを覚えているうちは指に宿る記憶を頼りに打鍵してみる」と、いかにも「タッチタイプできている」気がするので、心理的にとても楽だし達成感がある。ついでに、この時点で運動性記憶の良いところが上手く作用して「高頻度かなから順に、a-i-u-e-oの順をたどらずとも運指を導き出せる」様になるので、更に負担が早期に減る。

 ん、面白いね。この方向性でよさそう。

 ……ということは、ローマ字入力でも「a-i-u-e-o」で良さそうな気がしてきた。

 というか、むしろそうするべきなのかもしれない。

 (幼心で慣れ親しんできた)50音表の魔力……なのかも。

で、よく考えてもみれば……

 4ヶ月やってきたことを1時間で思い出しただけなのかもしれないorz

 やっぱり他の配列でやらないとダメか……。


 とすると、昔やっていた「JISX6002&自作配列類」も、なまじ触った記憶がある「姫踊子草配列&新JIS月配列系&下駄配列&奏コードかな部分」も実験用としては使えない……ということか。そう考えていくと、TRON配列や龍配列もだいぶじっくりと見たような気がしないでもないし……。

 まったく触ったことがない配列……むずかしいなぁ。


 ……日記を見た限り、おそらく「小梅1.2系」は触っていなかったはず。

 「小梅1.1系」に関しては記憶が微妙なものの、「紅葉配列(もみじはいれつ)」時代に「キーボードの真ん中が小書き文字」の配列を触ったことがあったから、どちらにせよ妙な学習効果が働いてしまいそうな予感が。

 うーん、次は「小梅1.2系」でテストしてみよう。シートがいつ完成するかは不明ですけど……orz


次に作るシートの案。

  • 対象版は「小梅1.2」。公開定義をそのまま用いて親指ひゅんQで使う。
  • 子音側の頻度は無視して「あ」「かが」「さざ」「ただ」「な」「はば」「ぱ」「ま」「や」「ら」「わ」「小書き文字」の順で並べて作成してみる。
  • 母音側は最近の手法とまったく同じ。同一面にの母音「あ→い→う→え→お」順で矢印を引く。
  • 始点の母音には、上(または左上)から矢印を引く。無駄な目視検索が「あ」段検索で必要な点がどうにも気になるもので……その目視走査は本来不要なはず、ゆえにガイドを付けるほうがいいと思う。

2006年07月23日 日曜日 かえでしきをかえる。

メモ。

 うーん……緊張の糸が切れてしまった気がというか、「-宣伝」と「+検証可能性」をどうやって両立しろというつもりなのでしょうか……微妙。「-宣伝」は勘違いだったらしい。となると、必要になった時点で復帰すればいいか……。

 急にやる気が萎えてしまったので、「キー配列関連そのもの」以外の記事については放置しようと思う。


 最近ヘッドフォンアンプキットの音量を乱したり、テレビの画面にノイズを撒き散らしたり……と悪さをしていた「ノイズの原因」を発見。意外にも(?)空気清浄機でした。電磁波障害のタイミング空気清浄機の排出口側エアフロノイズと同期しているので、モーター用のインバータあたりがおかしくなっているのかもしれない。

 但し、これ単体が原因なのかどうかはハッキリしないので、とりあえず運転中止ままで様子見することに。

かえで式「NICOLA練習用テキスト」メモ。

 ポイントは……今日メモに書いた

 ACTと同じように50音順、「いうんらめね」をあとまわしにしてシンプルな1枚ものをめざす。

 この方法ならば「ぱぴぷペぽ」もある程度素直にいけるはず。

(from http://d.hatena.ne.jp/maple_magician/20060722/1153553572 )

と、親指シフトの「欠点(質問)」と「それに対する反論(回答)」に書いていたこの文。

JISかなと違って文字の並びがバラバラ!どこに文字があるのか分かりにくいよ。

  • 以下の項目を順に読んで探してみてください。
  • そのひらがなは小文字ですか?
    • よく使う小文字「ゃゅょっ」は各キーの右上に描かれていて、これらは同じ手の親指シフトキーと同時に順に「RFL;」キーを押すことで入力できます(押しやすい位置にあります)。
    • 一方であまり使わない「ぁぃぅぇぉ」は各キーの右上に描かれていて、これらは同じ手の親指シフトキーと同時に順に「QBZP/」キーを押すことで入力できます(押しにくい位置にあります)。
  • そのひらがなは「いうんらめね」のいずれかですか?
    • 各キーの右下に描かれていて、これらは単独で順に「LA;YN,」キーを押すことで入力できます。
  • そのひらがなは「濁点・半濁点」を付けることができますか(または付いていますか)?
    • そうであれば、目的のひらがなはキーの右下に描かれていますので、キーの右下のみを探してかまいません。
      • 濁点を付ける場合は反対側の手にある親指シフトキーと同時に文字キーを押します。
      • 半濁点を付ける場合は小指付近にある↑Shiftキーと共に押します。
      • そのままの文字を出す場合には、そのまま押します。
  • その他の「濁点・半濁点」を付けられないひらがなはキーの右上に描かれていますので、キーの右上のみを探してかまいません。
    • これらは、それぞれ同じ手の親指シフトキーと同時に押します。
  • ひらがなは、日本語文内の「かな」出現頻度が高いものから、概ね「中段→上段→下段」順に配置されています。見て探す場合は、まず中段から探し、次に上段を探し、最後に下段を探します

(from http://d.hatena.ne.jp/maple_magician/20060104/1136314762 )

それと、ACT@かえで式の練習方法、改0訂0。でしつこく書いたコレ。

練習をする時のお約束(練習テキストよりも「お約束」の方が重要です!!)

  • 空白で区切られていない部分は、なるべく「まぶたを閉じたまま、一気に」打鍵しましょう。
    • 「あんちょこ」「問題文」「文字入力枠」を見る時間は、なるべく短く抑えましょう。
    • 目の疲れを最小限に抑えるため、極力目に頼らず「記憶に頼って」打鍵しましょう。
    • 打ち間違えていた場合でも、間違えた文字を修正する必要はありません。
  • ゆっくりでもいいのです。今は覚える時間であり、速さにこだわる必要はありません。

(from http://d.hatena.ne.jp/maple_magician/20060718/1153157146 )


 ……で、これらをどう合成しようかと考えてみたのですが……上手く思い浮かばないですね^^;。

 練習順序は……

  1. たちつてとだぢづでど
  2. あいうえお
  3. かきくけこがぎぐげご
  4. さしすせそざじずぜぞ
  5. やゆよわをん
  6. なにぬねの
  7. らりるれろ
  8. はひふへほばびぶべぼ
  9. まみむめも
  10. 、。ー
  11. ゃゅょっ
  12. ぱぴぷぺぽ
  13. ぁぃぅぇぉ

で、とりあえずシートを作ってみた。

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_for_nicola.pdf←2006年7月26日1:31:52に改名に伴い削除、以下のリンクをご利用ください。

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.pdf

 http://www.eurus.dti.ne.jp/~yfi/keylayout/bin/kaede_method_source.ods

 うーん……もう少し、何とかなればいいんですけど……難しいなぁ。

最近のかえで式が「ややこしい原理・ややこしい練習順序」を避けている理由

(過去:かえで式「NICOLA練習用テキスト」メモ。)

(過去:ACT@かえで式の練習方法、改0訂0。)

 NICOLA@かえで式では、なぜか再び50音順(以前は学習せずに使うタイプ、今度は学習専用)で学習するようシートを設計しました。

 この主たる理由は「手抜きをしたいから」とともに(いや、実際にそれもあるのですが)、「既に知っている知識を使って、目視確認時間を削減したい」ということも関係しています。


 かな系で入力効率を少しでも考えて配置すると、ほぼ必ず五十音順から崩れてしまいます。

 行段系の様に「打鍵数は多いが配列を整理しやすい(たとえばACTのような)」配列であれば、配列が定義したキーとホームキーとを見比べて、母音打鍵順序を「打ちやすいように設定」すればいいのですが、かな系にはその手が通用しません……全てのかながばらばらに配置されているのですから。

 そして、それでも練習する時点では「なるべくあんちょこを見ないで練習できる」ことが望ましいはずです。


 また、目からの余計な情報があると、指がキーを捉える感触を最大限に感じることができず、触鍵操作に本来必要のない負担が掛かります。

 そうすると、既にある記憶(ここでは五十音順)を利用して練習する以外には、目に頼らない打鍵練習をする上で支障をきたす事になるのではないか……と考えたわけです。

 また、打鍵練習と言うとまぶたを閉じることも忘れて「じっと画面を見つめてしまう」人がいるわけですが(えーと、モロに私がそのタイプ)、これは「目を悪くする」だけでなく「初期練習にはそもそも合わない」のではないか?と考え始めています。


 目視法で一番まずいのは「逐次状態が変わる」文字入力窓。これを前提に文字入力をしていると「目で確認しなければ次の打鍵ができない」という状況になります。

 つまり「キーを押す→1キーごとに目で確認する→間違っていたらその場で直す→……」となるわけで、本来触鍵操作に必要ないはずの「1キーごとに目で確認する」操作が、打鍵シーケンスの中に含まれてしまいます。これはあんちょこのような「いつ見ても変わらない」ものと比べてはるかに問題がある……というわけで。時間も無駄になりますし、目にもよろしくありません。しかもキーを打っていても「間違いなく打てた!という感じがしない」ままになりがちなので(今の私はまさにそれ)、こういう経験からも「目視に頼る文字入力習得」はお勧めしたくないんですよね……。


 で、話を「ややこしい原理・ややこしい練習順序」に戻して……と。

 基本的に、「誰でもすぐに暗記できるわけじゃない」から、目視確認に頼らなければならないわけです。

 私の場合、大昔には冗談で「シフトJISコード換算で30bit+EOFしか覚えていられない」なんてことを言っていたわけですが、そんな私でも実践できるように「極力既に覚えている知識をベースにする」「目視確認時間を短くしても支障がないようにする」「一時的に記憶するべき非運動性記憶を極力圧縮する」ことに注視してみたところ、結果として五十音順になってしまいました。

 物覚えの悪さではクラス職場でも一・二位を争えるほどでしたから(もちろん真実orz)、そんな私にでも習得できる方法を作れば、案外上手くいくんじゃなかろうか……と思ったわけです。


 暗記が苦手な人間にでも「目をほぼ瞑ったままで練習できる」方法を提供するならば、五十音順を弄ることなくほぼそのままに提供するのが自然だと考えています。もちろん、即実践投入が必要な例は多いですし、それに見合うように「最低限度の頻度順」は提示する必要がありますが、文字単位でそれが必要かどうかはちょっと自信がないんですよね……。

 清濁音のキーが一致しているNICOLATRON・小梅・月Ux系や、濁音・半濁音キーが分離独立している月2-263系・JISX6004・JISX6002などでは、今回作成した表の様な手順を用いることで、比較的シンプルにこの考えをテキスト化できるであろうと考えています。

 #飛鳥とかに応用できるかどうかは未検証。


 ……って、これはあくまでも「最近のかえで式」なので、それ以前には当てはまりませんし、それ以降に当てはまるかどうかは「予定は未定」なんですよね……どうなるのかは私にも解りません。できれば「文字頻度順学習」は最大限に生かしたいし、目視確認を可能な限り減らすという部分はそのまま引き継ぎたいですし……。


 さて、次に作るべきは「普通ローマ字入力(Qwertyローマ字入力)」と「普通かな入力(JISX6002かな入力)」なのでしょうけれども……とことんやる気が出ないのはなぜだろう^^;

 #今日の昼間に「ナビ外し」をして疲れただけ……という気はするのですが……というか暑過ぎ。

2006年07月22日 土曜日 ほうしんをへんこう。

メモ。

 NICOLA-Wikiの練習テキストは廃棄。

 ACTと同じように50音順、「いうんらめね」をあとまわしにしてシンプルな1枚ものをめざす。

 この方法ならば「ぱぴぷペぽ」もある程度素直にいけるはず。

 QWERTYロマかなは「きくこかけ」じゃなくて左手「かけくきこさせすしそ」と右手「こきくけか」……同手連打からはじめる。練習順序も「上段→中段→下段」。

2006年07月21日 金曜日 もじではなくえかき。

Wikipedia:検証可能性#方針に対する提案をしてきた。

 除去するだけが貢献じゃねーよ!と、ただそれが言いたかっただけなのですよ……ええ。

 これもかなり嫌味が入っているのですが(消す「だけ」の人がいるんですよね……)、こっそり増田式についての紹介をしつつ「ノート:QWERTY配列#文節単位から原典明示を行うための仕掛けに関する提案」の存在にも気づいて欲しいなぁ……という、しょーもない考えも含んでいたり。

 まぁ、なるようにしかなりません。それでも、始めからできるとわかっていることをしないなんて許せないわけで、少しぐらい悪あがきをしてみたいわけなのです。

タッチタイプの初期教本は「タッチタイプえほん」か「タッチタイプまんが」にするべきなのです!

(参考: ACT@かえで式の練習方法、改0訂0。)

 前に、タッチタイプ練習テキスト「よりもはるかに大事」と書いた「お約束」の件に絡んで、ふと思いついたことがあります……そのまえに、当時書いた「お約束」をここに転記してみます。

  • 空白で区切られていない部分は、なるべく「まぶたを閉じたまま、一気に」打鍵しましょう。
    • 「あんちょこ」「問題文」「文字入力枠」を見る時間は、なるべく短く抑えましょう。
    • 目の疲れを最小限に抑えるため、極力目に頼らず「記憶に頼って」打鍵しましょう。
    • 打ち間違えていた場合でも、間違えた文字を修正する必要はありません。
  • ゆっくりでもいいのです。今は覚える時間であり、速さにこだわる必要はありません。

(from ACT@かえで式の練習方法、改0訂0。 )

 これを認識していただくことが「一番重要である」とするならば、本来テキストは「文字ベース」ではなくて「ピクチャベース」にするほうが、より親和性が高いのかも……という風に思いました。


 とはいえ、これって書くのがすごーく大変そうな予感が。

 少なくとも私……絵は書けませんし、絵抜きコンテを切るどころか「あらすじ」さえも書けそうにはないわけで……うーん。

 #タッチタイプの「高速化」教材については、絵ではダメだろうなぁ……と思います。とすると、やっぱり増田式の様に音声なのかなぁ……アレも難しそう。

2006年07月19日 水曜日 けんしょうすること。

とりあえず想いをぶちまけてきた(→Wikipedia:検証可能性)。

 (めちゃくちゃ卑怯な物言いだから)ホントは言うべきじゃないんですけどね……どうにもならないので、とりあえず言ってみました。というか、半年で本当に全て記述できるのかどうかすら謎なのですが……orz

 もう検証可能性ルールに基づく削除を拒絶する気はないけど、せめて夢ではなく現実を見てほしいな……と。

文節単位での文献明示方法を考えてみた。

 ノート:QWERTY配列#文節単位から原典明示を行うための仕掛けに関する提案に記してきたのですが、ある特定の文節(一文字以上、全文以下)に対して参考文献を明示的に示す方法を考えてみました。

 本当は体裁など考えずに

○○年に何の誰それは文献『──』において〜〜〜〜〜と言及した。それに対し○○年に何の誰それは文献『──』において〜〜〜〜〜と言及し、また○○年に何の誰それは文献『──』において〜〜〜〜〜と言及した。その後○○年に何の誰それは文献『──』において〜〜〜〜〜と言及し、○○年に何の誰それは文献『──』において〜〜〜〜〜と言及したが、○○年に何の誰それは文献『──』において〜〜〜〜〜と言及した。

記述してもいいのでしょうけれども、こんなもの誰も見たくはないでしょうし、何より追記し辛過ぎて仕方がないわけです。誰も追記しない・誰も見ない……そんなものはいらない訳で。


 一方では「Wikipediaは紙文献より頼りにならねー」というあたりも確かに感じるわけで、文献情報を完全にコメントのみで埋め込み表現するのはちょっとダメっぽいんですよね。

 そこで、最小限度の表示はしつつ、かつ明示的に「その記述がどの文献を参考に記述したものなのか」を示せるであろう方法を考えてみた……というのが、先のノート:QWERTY配列#文節単位から原典明示を行うための仕掛けに関する提案です。

 記述直後に字上げで簡易参照(「*1」とかいう関連付けをWikipediaでやると後の編集を阻害しかねない)を示しているので、見る人にとっては(これでも十分に見づらい気はするのですが)ある程度文献に当たりやすくなるかな……と。


 もっとも、この方法ではソースを見なければ「どこから?」の部分を(記事を見ただけの人には)提示できないので、これでいいのかどうかは微妙なのですが……。

(Joke)「今更ながらに」和文モールス符号案……ではなくて、和文電信符号案。

【表記上のお約束

  • 短点は【■】【─】(2006年7月21日1:10:28に訂正)
  • 長点は【■■■】【───】(2006年7月21日1:10:28に訂正)
  • 点と点の間は短点と同じ空白な時間を消費するのでスペース一個。
  • 文字の間は長点と同じ空白な時間を消費するのでスペース三個。
  • 語の間は……って、それ和文では不要なのか。

 当初は人力で打つことをまったく考えていなかったため、短点優先で並べていました……それではまずすぎるので、長点優先で割り振ってみました。

 ちなみに、常識的な「短点を・で、長点を─で表す」方法では高速伝送のために必要な時間軸管理ができないので、ここでは上記の様に「打鍵回数ではなく総打鍵時間優先で」コードを割り振っています。原理的には同じ方法でコード化すれば、英文モールス符号微妙に伝送時間を短くできる気がする(注:作ってから気づいた……これって紙テープでの符号記述方法と同じ考えになっていたかも)。

 但し、エレキー(スイッチ板を左右に振って長点と短点を表現する入力機器。出力バッファが付いているので短点も長点も同じ時間で入力できる)で入力することを考えて作ったコードではないので、入力時の速度は従来コードによるもののほうが速いかもしれない。

 ※当時記述した符号化には間違い(重複割り当て)があり、2006年7月21日1:10:28に上書き訂正を行いました。

【ひらがなと常用記号(JISかな配列頻度)】

゛ ─

い ───

う ─ ─

ん ─── ─

し ─ ───

か ─ ─ ─

の ─── ───

と ─── ─ ─

て ─ ─── ─

た ─ ─ ───

き ─ ─ ─ ─

、 ─── ─── ─

く ─── ─ ───

は ─── ─ ─ ─

に ─ ─── ───

こ ─ ─ ─── ─

る ─ ─ ─ ───

ょ ─ ─ ─ ─ ─

つ ─── ─── ───

せ ─── ─── ─ ─

な ─── ─ ─── ─

っ ─── ─ ─ ───

を ─── ─ ─ ─ ─

り ─ ─── ─── ─

す ─ ─── ─ ───

け ─ ─ ─── ───

。 ─ ─ ─── ─ ─

さ ─ ─ ─ ─── ─

あ ─ ─ ─ ─ ───

ち ─ ─ ─ ─ ─ ─

そ ─── ─── ─── ─

れ ─── ─── ─ ───

ゅ ─── ─── ─ ─ ─

ら ─── ─ ─── ───

ふ ─── ─ ─── ─ ─

よ ─── ─ ─ ─── ─

も ─── ─ ─ ─ ───

お ─── ─ ─ ─ ─ ─

ほ ─ ─── ─── ───

え ─ ─── ─── ─ ─

ま ─ ─── ─ ─── ─

め ─ ─── ─ ─ ───

ひ ─ ─── ─ ─ ─ ─

み ─ ─ ─── ─── ─

わ ─ ─ ─── ─ ───

や ─ ─ ─── ─ ─ ─

・ ─ ─ ─ ─── ───

へ ─ ─ ─ ─── ─ ─

゜ ─ ─ ─ ─ ─── ─

ろ ─ ─ ─ ─ ─ ───

ね ─ ─ ─ ─ ─ ─ ─

ー ─── ─── ─── ───

ゃ ─── ─── ─── ─ ─

む ─── ─── ─ ─── ─

ゆ ─── ─── ─ ─ ───

」 ─── ─── ─ ─ ─ ─

「 ─── ─ ─── ─── ─

ぃ ─── ─ ─── ─ ───

ぬ ─── ─ ─── ─ ─ ─

ぇ ─── ─ ─ ─── ───

ぁ ─── ─ ─ ─── ─ ─

ぉ ─── ─ ─ ─ ─── ─

ぅ ─── ─ ─ ─ ─ ───

( ─── ─ ─ ─ ─ ─ ─

) ─ ─── ─── ─── ─

【数字】

1 ─ ─── ─── ─ ───

2 ─ ─── ─── ─ ─ ─

3 ─ ─── ─ ─── ───

4 ─ ─── ─ ─── ─ ─

5 ─ ─── ─ ─ ─── ─

6 ─ ─── ─ ─ ─ ───

7 ─ ─── ─ ─ ─ ─ ─

8 ─ ─ ─── ─── ───

9 ─ ─ ─── ─── ─ ─

0 ─ ─ ─── ─ ─── ─

【記号】

! ─ ─ ─── ─ ─ ───

? ─ ─ ─── ─ ─ ─ ─

& ─ ─ ─ ─── ─── ─

% ─ ─ ─ ─── ─ ───

¥ ─ ─ ─ ─── ─ ─ ─

【制御】

和 ─ ─ ─ ─ ─── ───

英 ─ ─ ─ ─ ─── ─ ─

終 ─ ─ ─ ─ ─ ─── ─

文 ─ ─ ─ ─ ─ ─ ───

訂 ─ ─ ─ ─ ─ ─ ─ ─

 ※重複符号除去と同時に、本文と訂正の順番を入れ替えました。

 ※「─ ─── ─ ─ ─」が抜けているなど、ありえる組み合わせを全て出し切っていない部分があります^^;……とりあえずはこのままで。

2006年07月18日 火曜日 わかりやすささがし。

メモ。

 飛鳥配列の記事は白紙化してきました(まだ削除はされていないので差し戻しは可能ですが……)。

 検証可能性の議論がどうなるかによっても異なってきますが、ルールがまともに訳出されて残せるようになったら(あるいは記述をするに足る要件が整えば)、もう一度始めから記事を作成してみようと考えています。

 というか、あそこのノートで議論しているヒマがあったら記事の再編成に時間を割く方がよかった気がする……言うより前にや、ってみようと思う。


 それと、安岡さんから頂いたコメントを見てようやく気づいたのですが、「QWERTY配列 - Wikipedia」の書式って辞典的事典的ではないんですよね……せっかく検索されやすいワードだけに、もっと「時間軸順に、Qwertyの歴史や現状を学べる」ページになると、知識欲を満たしたい人にとっていい記事になるんじゃないかな、と。

 「QWERTYの良し悪し」だけが載っているなんて、いくらなんでも勿体無さ過ぎですし。

 とりあえず和文献でできるところを少しばかり弄ってみようかと思います。

 改訂初版で「○○(人名)はxxxx年に〜(内容)〜と言及している。」という風に全内容を記述することがポイント。そうしないと次版以降で記述する人が追記するときに困る。特定の人が同じ年に全然違うことを文献として残すことはそう極端にはないはずだから、多少読みづらくともこの書式で書く方が追記編集しやすいと思うし。

 〜内容〜(人名、xxxx年)というスタイルでも良いかも。

やり方を理解・体感してもらうことが重要。同一型番の事務電卓を使って、実用度がより高い「電卓のタッチタイプ」をやってみる方法も有りだな。


 「W-ZERO3[es]」開発者インタビュー

 またもやシャープLCフォントは非搭載ですか。今のサイズですら見づらいから速攻で直していただきたいところなのですが……。期待しているんだけど、もしかするとこのまま出ないのだろうか。機種変時期にいいものが出てくることを期待したいところ。

Wikipediaのキー配列関連記事全て(記事「キー配列」そのものを含む)に「{{要出典}}タグ」を貼ろうと考えています。

 ちょっとアレな提案なのですが……Wikipediaのキー配列関連記事について、全部の記事(削除依頼中の「飛鳥配列」と、ほぼ原典のみで構成したことがわかりきっている「ACT_(キー配列)」を除く)に対して、{{要出典}}タグを貼ってみようと考えています。

 「検証可能性」に関する解釈が他のルールとごちゃ混ぜになっている現状からすると、到底ルール本筋での運用は無理そうですし、最終的には「公知原典がない案件は全部排除」という結論に至りそうです……

 {{要出典}}タグを全ての記事に貼ることについて、もし問題がある(もしくは貼らないほうがいい記事がある)様でしたら、その旨お知らせいただけますでしょうか。


 ……正直言って、これ以上この案件を抱え込むのは無理っぽいのです。

 もちろん、{{要出典}}タグを貼れば記事が削除される可能性は上がってしまうわけですが、少なくとも自己申告ぐらいはしておきたいなぁ……というのが、今の気持ちでして。


 「原典のない記述は排除するべきだ!」と言っている方ですら、自身が書く記事には十分な原典を明示していなかったりする様子もちらほら見られるぐらいですから……とにかく全体的に、準備も時間も何も足りていないと言うのが現状でして。

 ゆえに、むしろ積極的に{{要出典}}タグを貼るほうが先決だという考えに至りつつあります。

 ソレで削られる記述があるのならば「原典を補完して差し戻す」なり「原典がないから放置する」なりするしかないでしょうし、そういう方法で記述内容が整理されていくのならば、これはある意味仕方がないことなのかもしれません。

 ……そういうわけで、ここをご覧になっている方からのご意見をお伺いしたく思います。

ACT@かえで式の練習方法、改0訂0。

(過去:ACT@かえで式のメモ。)


 ACT(Dvorak配列のAZIK拡張+αな配列)について、「1文字/数秒のレベル&誤字率10%程度の状態を2〜3時間で得る」という無謀な(?)目標を達成することを前提に、とりあえず練習方法を作成して実践してみました。

 #今回はいいポイントが見つかったので、始めて自分で「かえで式」のメリットを享受できた気がします(今までも作るたびに試しているのですが、どうにも上手くいきませんでした)……って、じゃあ今までは何だったのだとツッコまれると厳しいのですが^^;。


 ACT(というかDvorak)の母音部分は非常に規則的に並んでいる(M式のような意図したものではないが、母音部分は折り返し五十音順で並んでいる)ので、ある程度は効率よく(というか覚えることを少なめに・連想記憶で)学習してしまうことが可能だと思います。

 #練習法を考えようとする場合に限り、ホントは連想記憶に頼るべきではないのですが……


 練習するときのポイントは、ただ一つ。

画面を見るのはあんちょこを確認をするその瞬間のみ。他は目を閉じて「キーを指で感じつつ・余裕を持ってじっくりと」思い出しながらキーを打つ

ということで。

 おそらく「どんなメソッドを使おうとも」上記条件さえ満たせれば大丈夫そうな気がします……というか、これを前提にしたメソッドを組めばいいのかもしれない。

 #Uジローさんの「飛鳥をこうやって練習してみました」な話、頭では理解していたけど「体感したのは始めて」なので、自分でもちょっとビックリしています。


 ちなみに、母音練習はだいぶ削りました。

 そのほかにも、メモ段階から結構弄っているような気が……。


 さて、練習順序は……実際にACTを練習して感じた限りでは、母音からはじめる方が良さそう(というか、右手からはじめると違和感がある)ですので、セオリーどおり「母音→清音&濁音&半濁音→特殊拡張」の順で進める方が良さそうです。

 ACTの基本配列図をこの記事の隣に並べて、下にnotepad.exeかwrite.exeを広げて3ペインで練習するといいかもです(キーボードを見ても解らないから弊害はないので、目に優しい下向き目視がお勧めです)。


 では、以下順番に練習テキストを示します。

練習をする時のお約束(練習テキストよりも「お約束」の方が重要です!!)

  • 空白で区切られていない部分は、なるべく「まぶたを閉じたまま、一気に」打鍵しましょう。
    • 「あんちょこ」「問題文」「文字入力枠」を見る時間は、なるべく短く抑えましょう。
    • 目の疲れを最小限に抑えるため、極力目に頼らず「記憶に頼って」打鍵しましょう。
    • 打ち間違えていた場合でも、間違えた文字を修正する必要はありません。
  • ゆっくりでもいいのです。今は覚える時間であり、速さにこだわる必要はありません。

おまけの練習用テキスト:第一ステップ:左手の練習

※練習前に:必ず上記の「お約束」を読み、習得方法の意図を把握してから練習を開始してください。

左手中段】
うえおあい うえおあい 
※納得できるまで繰り返してみることをおすすめします。以下同じ。

【左手上段】
つうていとうたい つうていとうたい
※「T」キーは右手ホーム段中指(Qwerty:K)に割り当てられています。

【左手下段】
うんえんおんあんいん うんえんおんあんいん

おまけの練習用テキスト:第二ステップ:両手の練習

左手中段←右手中段】
ふへほはひ ふへほはひ
つてとたち つてとたち
ぬねのなに ぬねのなに
すせそさし すせそさし
づでどだぢ づでどだぢ

【左手中段←右手上段】
ぐげごがぎ ぐげごがぎ
くけこかき くけこかき
るれろらり るれろらり
ぅぇぉぁぃ ぅぇぉぁぃ
ふふぇふぉふぁふぃ ふふぇふぉふぁふぃ

【左手中段←右手下段】
むめもまみ むめもまみ
わを わを
ヴヴぇヴぉヴぁヴぃ ヴヴぇヴぉヴぁヴぃ
ずぜぞざじ ずぜぞざじ
ぶべぼばび ぶべぼばび

【左手中段←左手上段】
ぷぺぽぱぴ ぷぺぽぱぴ
ゆよや ゆよや

おまけの練習用テキスト:第三ステップ:右手の練習

【右手中段】
ひゅうひょう ひゃく   ひゅうひょう ひゃく
( h[中指yuu] h[小指you] h[薬指y][小指aku] )

ちゅうちょう ちょくちゃく   ちゅうちょう ちょくちゃく
( t[中指yuu] t[小指you] t[人差し指y][薬指oku] t[人差し指y][小指aku] )

にゅうにょう にょくにゃく   にゅうにょう にょくにゃく
( n[中指yuu] n[小指you] n[人差し指y][薬指oku] n[人差し指y][小指aku] )

しゅうしょう しゅつしょくしゃく   しゅうしょう しゅつしょくしゃく
( s[中指yuu] s[小指you]
    s[人差し指y][中指utu] s[人差し指y][薬指oku] s[人差し指y][小指aku] )

【右手上段】
ぎゅうぎょう ぎょくぎゃく   ぎゅうぎょう ぎょくぎゃく
( g[中指yuu] g[小指you] g[薬指y][薬指oku] g[薬指y][小指aku] )

きゅうきょう きょくきゃく   きゅうきょう きょくきゃく
( c[中指yuu] c[小指you] c[人差し指y][薬指oku] c[人差し指y][小指aku] )

りゅうりょう りょくりゃく   りゅうりょう りょくりゃく
( r[中指yuu] r[小指you] r[人差し指y][薬指oku] r[人差し指y][小指aku] )

ふゅーふぉー ふゅーふぉー
( f[中指yuu] f[小指you] )


【右手下段】
みゅーみょう みょくみゃく   みゅーみょう みょくみゃく
( m[中指yuu] m[小指you] m[薬指y][薬指oku] m[薬指y][小指aku] )

うぉー
( w[小指you] )

ヴゅーヴぉー
( v[中指yuu] v[小指you] )

じゅうじょう じゅつじょくじゃく   じゅうじょう じゅつじょくじゃく
( z[中指yuu] z[小指you]
    z[人差し指y][中指utu] z[人差し指y][薬指oku] z[人差し指y][小指aku] )

びゅうびょう びょくびゃく   びゅうびょう びょくびゃく
( b[中指yuu] b[小指you] b[薬指y][薬指oku] b[薬指y][小指aku] )

【おまけ】
です。ます。 です。ます。
( ds. ms. )

 さァ、これで練習すれば、きっと君もACTerになれるさッ!

 #ああ、【-er】ではなくて【-or】か【-ress】の方がよさげかも……?

注意

 「お約束」さえ守っていただければ、多分大丈夫……だと思います。

 「お約束」を守っていただけない場合、このテキストの価値は間違いなくゼロで、絶対に効果はありません。目に頼らず記憶に頼る、ソレがこのメソッドのキモなので(……って、今日気づいたばかりのことを「キモ」とか言っていいのかと^^;)。


 初期練習に1〜2ヶ月(注:いや、冗談ではなく)掛かっている私が、なぜかこの「お約束」どおりにやれば2〜3時間で「かなり間違うけど、それでもだいぶ出来そうだと自信が持てる」所までいけたぐらいです……それぐらい「お約束」が効果をもたらすわけで。

 人間記憶に関わる原理というのは面白いですな。

結局、

 「お約束」がいかに重要だったのかという事に気づいたことが、今日一番の収穫だったりします。

 今日の文面では、いかに「【練習用テキスト】はおまけであって、どうやって練習するかという【練習スタイル】が重要だと言うこと」を表現するか……という所に苦労したぐらいですし^^;。


 うーん……かえで式の練習テキスト提供計画は、根本から見直さないとダメかもしれませんね。

 というか、そうするとタッチタイプ練習ソフト方式での練習ってかなりキツイですな。

 訂正/Backspaceを要する方式は根本的にダメで、誤打ごとにいちいち止まる&ミスを知らせるような仕掛けももちろんダメ……ということか。

 

 ところでこのやり方、基本的には「打鍵中は目を瞑る・一文字ごとの確認をせずにすむようテキストを作る・なるべく目視確認は短時間に抑える・わざわざ訂正しない」ことさえ満たせればいいから、どんな入力方式でも使えそうですね。

 テキスト&あんちょこの情報の提供方法は制限されないから、みのりさんの図形例示方式でも当然問題ない(というか、むしろそっちの方が自然)ですし。

 要は「なるべく短時間で把握できる形式・なるべく指で打鍵しやすい順番のテキストを作る&事前に必ず「お約束」を掲示する&テキストが「おまけ」だとハッキリ明示する」ことさえ満たせば、おそらくは大丈夫なのではないかと思います。


 しかし、何度考えても驚きだよなぁ……誤打はめちゃくちゃ多いけど、とりあえず「タッチタイプできる!」ってゆー事実のみはしっかり残ったわけで。

 「サイトメソッド→タッチタイプ」よりもはるかに早く「いきなりタッチタイプ」出来るようになると言うのは、当然と言えば当然なんだけど、不思議と言えば不思議ですね……。

 もっとも、Dvorakの場合は母音部を連想記憶に頼って記憶している(無連想記憶は子音部のみ)から、無連想配列ではより時間が掛かることは確実だと思います。ただし、練習時間を「非現実的なぐらい長い時間から、現実的な時間へとシフトする」効果はありそう。


 ……あっ、ちなみに【さァ、これで練習すれば、きっと君もACTerになれるさッ!】まではACTで書きましたが、それ以降は飛鳥に戻しています^^;

 いや、色々すぐに書いておきたいことがあったもので。

ちなみに、練習風景は……

 Uジローさんの言いつけ(2〜3時間集中して練習するというところ)を守れず、15分ぐらい練習して飽きるたびに15分ほど休憩する……という、だいぶふざけたことをしていました^^;。

 全体で7時間ぐらい?正味3時間ぐらい(ACT@かえで式のメモ。とこの記事の作成時間を含む)ですが、自分としては十分ありえないぐらいに「だいたいキー位置を覚えている思い出すことが出来る」様になりました。

 ……うーん、私の様に飽きっぽい(集中力が続かない)場合でも、あるいは(当日の範囲内で)断続的な練習であっても、案外問題なくいけるっぽいですね。


 もっとも、正味3時間の練習を経た今現在のレベルは「だいたいキー位置を覚えている思い出すことが出来る」でしかなく(取り消し線が重要)、本気でやるなら今日から完全切り替えで突っ走るのが理想だと思います。でも、この調子ならば本格切り替えしても不安はないですね。

記憶をたどると……

 「目を瞑って打鍵する(シャドータイピング)」はタイパーな方々によるものですよね。

 「細かな訂正をしない・入力途中で文字を表示しない」は昔からそういう練習がありますよね。

 「二つをやりやすくする方法をテキストで提供する」は増田式の領域ですよね。

 うーん……やっぱり車輪を再発明しているだけのような気がしてきました^^;。

ここで一つの疑問が。

 しっかし、なんでこういうことが「学校技術家庭科あたりの教科書」に載っていないのでしょうか?

 サイトメソッドでキーを探すよりも、よほど楽に実用的な利用ができると思うのだけれど……。

 #ああ、つまりはソレを「Wikibooks」に載せてGFDLで提供すればいいのか(違

ふと思ったのだけれど……

(過去:ACT@かえで式の練習方法、改0訂0。)

 あれから7時間ほど後になって思ったのだけれど……

  • 単に「Dvorakが習得用に向いていた」だけなのかもしれない
  • そもそも昔Dvorak英字を飛鳥とともに使っていた時期があった

とか、そういうあたりを考慮していなかったのを忘れていた事に気づきました……ダメじゃん。


 Dvorak英字になかった拗音拡張とかは全部規則的なもの&段越え操作なしだから、これも木村先生のもくろみ通りに「元々覚えやすく仕上がっている」わけで……検証したことにはならない気がしてきました。


 ……さて、ではどういう配列で練習すればいいのやら。

 ぱっと浮かんだのはColemak。

Q W F P G  J L U Y ;
 A R S T D  H N E I O
  Z X C V B  K M , . /

 でもなぁ……Aが小指ってところは結局同じだし、反対側の小指もOだからなぁ。

 同じ理由で、OEAも左端がOってゆーのが使いづらそう。

 今回は和文テキストでしか練習しないから、英文に考慮した配列を使ってきつい思いをしても得することがなさそうだし……うーん。


 あっ、計算だけして使っていないTHD配列があるな。

R M P B C  J Y O U Z
 H T S G W  ; A I N E
  L D V K F  / X , . Q

 ……和文にしか向かない英字配列というのは微妙だけれど、あの配列は「子音側については結局もくろみ通りにいかなかった」「母音側に関しては趣味丸出し」だから、練習用テキストの試作にはちょうど向いているかもしれない。

 後で試してみよう。

2006年07月17日 月曜日 かたてからはじめる。

メモ。

 今日の気づき。

 Wikipedianは「ルールを読んで得た自己流解釈」を元に行動している。

 私もそうなのですが(今脱却できるかどうか検証中)、自分の中に「Wikipediaはこうあるべき・Wikipediaルールはつまりこういう事を言っているのだ」ということを理解するために、いわゆる「Wikipedianによる独自の研究」を行ってしまっているのかもしれない……と、今までルールノートに関わってきて痛切に感じました。

 これでは論争が起きて当然、何のためのルールなのかが解らない。

ACT@かえで式のメモ。

(過去:メモ。@2006年07月14日 金曜日)

まず「か」たてから「え」んえんと「で」きるまで練習する練習方「式」

なのですが、母音からはじめるべきか子音からはじめるべきかは迷いますね。

 もっとも、キー打鍵は指の運動によるもの(頭で考えてどーこーするわけじゃない)のですから、「左手を動かしやすい人は母音から」「右手を動かしやすい人は子音から」練習しないと、覚えられるかどうか不安になるだろうから……「動かしやすい方の手から練習」というままで良さそう。

 とりあえずはACT (キー配列)#ACTの基本配列をあんちょこ代わりに使いつつ。

 で、ACTは人差し指と薬指で拗音化をするという原則があるので、中指からの練習方法はあまりよろしくなさそうな感じがします……しかも、人差し指伸ばす以外には全て拡張が割り当てられています。

 そこで、左手の練習順序は人差し指→中指→薬指→小指→人差し指伸ばすの順にしてみました。右手の練習順序は中指→人差し指→薬指→小指→人差し指伸ばすのままにしています。

右手の練習

※一文字づつ覚えるまで練習→一行すんなり打てるまで練習→次の行へ進む……としてください。

【右手中段】
h[e] h[yuu] h[you] h[y][utu] h[y][oku] h[y][aku]
t[e] t[yuu] t[you] t[y][utu] t[y][oku] t[y][aku]
n[e] n[yuu] n[you] n[y][utu] n[y][oku] n[y][aku]
s[e] s[yuu] s[you] s[y][utu] s[y][oku] s[y][aku]
d[e] d[yuu] d[you] d[y][utu] d[y][oku] d[y][aku]

【右手上段】
g[e] h[yuu] h[you] h[y][utu] h[y][oku] h[y][aku]
c[e] t[yuu] t[you] t[y][utu] t[y][oku] t[y][aku]
r[e] n[yuu] n[you] n[y][utu] n[y][oku] n[y][aku]
l[e] s[yuu] s[you] s[y][utu] s[y][oku] s[y][aku]
f[e] d[yuu] d[you] d[y][utu] d[y][oku] d[y][aku]

【右手中段】
m[e] h[yuu] h[you] h[y][utu] h[y][oku] h[y][aku]
w[e] t[yuu] t[you] t[y][utu] t[y][oku] t[y][aku]
v[e] n[yuu] n[you] n[y][utu] n[y][oku] n[y][aku]
z[e] s[yuu] s[you] s[y][utu] s[y][oku] s[y][aku]
b[e] d[yuu] d[you] d[y][utu] d[y][oku] d[y][aku]

左手の練習

※一文字づつ覚えるまで練習→一行すんなり打てるまで練習→次の行へ進む……としてください。

【左手中段】
e[t]e u[t]u o[t]o a[t]a i[t]i

【左手上段】
e[t][ei] u[t][ou] o[t][uu] a[t][ai]

【左手中段】
e[t][enn] u[t][unn] o[t][onn] a[t][ann]

というわけで

 とりあえず練習中。上手くいくのかしら……。

えらく間違っていました。

 というわけで、手順を修正。

右手の練習

※一文字づつ覚えるまで練習→一行すんなり打てるまで練習→次の行へ進む……としてください。

【右手中段】
h[e] h[yuu] h[you]                     h[y][aku]
t[e] t[yuu] t[you]           t[y][oku] t[y][aku]
n[e] n[yuu] n[you]           n[y][oku] n[y][aku]
s[e] s[yuu] s[you] s[y][utu] s[y][oku] s[y][aku]
d[e] d[yuu] d[you]                              

【右手上段】
g[e] g[yuu] g[you]           g[y][oku] g[y][aku]
c[e] c[yuu] c[you]           c[y][oku] c[y][aku]
r[e] r[yuu] r[you]           r[y][oku] r[y][aku]
l[e]                                            
f[e] f[yuu] f[you]                              

【右手中段】
m[e] m[yuu] m[you]           m[y][oku] m[y][aku]
w[e]        w[you]                              
v[e] v[yuu] v[you]                              
z[e] z[yuu] z[you] z[y][utu] z[y][oku] z[y][aku]
b[e] b[yuu] b[you]           b[y][oku] b[y][aku]

左手の練習

※一文字づつ覚えるまで練習→一行すんなり打てるまで練習→次の行へ進む……としてください。

【左手中段】
e[t]e u[t]u o[t]o a[t]a i[t]i

【左手上段】
e[t][ei] u[t][ou] o[t][uu] a[t][ai]
e[t][ei] u[t][uu] o[t][ou] a[t][ai]

【左手中段】
e[t][enn] u[t][unn] o[t][onn] a[t][ann] i[t][inn]

もう少しやってみます。

 とはいえ、ここの文章は未だ飛鳥に戻して打っていたりするわけですが……orz

あんちょこを画面隅に置いて打鍵中……

 コメントをいただいてリンクを修正しました。記事にした後からリンクチェックすればよかった……orz

 コメントにも書きましたが、交互打鍵がすごく苦手になっていることに気づきました。左手がさっぱり言うことを聞かないというか。

 試しにQwertyローマ字でやってみると普通に叩けるので、運動機能そのものの問題というわけではなさそうです。

 個人的には……「ノートPCのキーボードで小指に「A」とか「う」などを割り当ててあると辛い」という感じです……って、始めから解ってるじゃないかソレorz。

やっぱり左手から練習しないとダメかも。

 ……まるで非拡張部分をすんなり打てない(拡張部分練習+清音練習としてしか機能していない)ので、今は急遽、M式の太鼓打ち五十音練習方式を真似して、こんな練習を追加しています。

 とにかく「打てる感じを掴む&母音が折り返し五十音順に並んでいることを上手く生かす」方が良いのかも。

ふへほはひ ふへほはひ
つてとたち つてとたち
ぬねのなに ぬねのなに
すせそさし すせそさし
づでどだぢ づでどだぢ

ぐげごがぎ ぐげごがぎ
くけこかき くけこかき
るれろらり るれろらり
ぅぇぉぁぃ ぅぇぉぁぃ
ふふぇふぉふぁふぃ ふふぇふぉふぁふぃ

むめもまみ むめもまみ
わを わを
ヴヴぇヴぉヴぁヴぃ ヴヴぇヴぉヴぁヴぃ
ずぜぞざじ ずぜぞざじ
ぶべぼばび ぶべぼばび

ぷぺぽぱぴ ぷぺぽぱぴ
ゆよや ゆよや

 まだまだ練習中……。

画面(&あんちょこ)を見ながら打鍵練習するとろくなことがないことが判明。

 キーを確認する間だけはチラッと画面を確認しますが、それ以外はなるべく目を瞑ったままで打鍵しています(目を瞑って考えている時間の風がはるかに長い状況)。

 ……って、おかしなことを見つけた。子音(→拗音拡張)→連母音拡張の対応関係がuu/ou逆だった……Wikipedia側が間違いorz、修正してきました。

「外来語専用母音キー」を用いる、という発想。(まとまっていないのでメモのみ……)

 kouyさんの記事「けいならべって何だ?」へのトラックバック経由で拝見した「行段系カナ配列 eszett X-001(仮)」、外来音用の母音キーを専用に設けるという手法で「ぢ/でぃ」分別を行う興味深い設計。

 旧来より「濁音付き母音」キーを使う配列(G-code、Phoenix、mykey)はあったけど、「外来語専用母音」キーという発想は見たことがないし、何より面白いと思う。特に外来語と和語の取り違えで悩んでいる人にとっては、この解決方法は注目に値すると思います。

 行段系の母音拡張というと「撥音拡張(ann/inn/unn/enn/onn)」「連母音拡張(ai/uu/ei/ou)」「や行母音拡張(ya/yu/yo)」「濁音母音拡張」あたりがあって……となると、今回の拡張手法は「外来音母音拡張」なのかも。

tastieraさんから頂いたコメントより。

 (「母音拡張」ではなくて)「母音字拡張」ということで。この表現には「あっ、なるほど!」と思いました。


 「母音字」という表現で捉えてみると、母音字拡張キーを5キー増やすというスタイルのみではなく、たとえば「母音字シフト」キーを小指辺りに1個のみ置いて、「子音→母音字シフトキー→母音=外来語音」というシフト方法も可能になりそうですね。

 たとえば、こんな感じにするとか。

  • 「ぢ」=【D】【I】
  • 「でぃ」=【D】【外】【I】
  • 「ほ」=【H】【O】
  • 「ひょ」=【H】【拗】【O】 or 【H】【YO】
  • 「ふぉ」=【H】【外】【O】

 子音側/母音側/SandSに【外】キーを配置する or 子音隣接キーの後置で母音字シフトをするとか、色々な手法が考えられそうです。

(2006年7月22日0:40:54追記)なぜ「うえおあい」なのか?

 「あいうえお」などのようにすると、Dvorakでは「I」→「U」を高速に打鍵しなければなりません。

 で、練習をする上で同指連打は可能な限り避けたい(拗音節・シフト側文字の運指学習効果と同じで、妙な学習経路を確立しやすい)ので、それを避けるために「い」と「う」の間に空白を入れることにし、読者が一切意識せずとも強制的に区切られるようにしました。

 #見方を変えれば、これもアフォーダンスや制約の一種。


 ゆえに、Dvorakでは「うえおあい」なのです。

2006年07月16日 日曜日 そうじをするだけか。

メモ。

 ketttさんの分かち書きデータを頂いてきて、n-gramに掛けてソートしてみた……けど、特に発見無し。

 ……いや、そもそも「表計算ソフトソート」という作業方法に問題がありそうだな。

 前にかな連なり頻度表を作ったことがあったけど、ああやって「統計を取ってしまう」と、肝心のコーパスが見えないから、あまり意味がないし……。

 n-gramに掛けた後でKWICすればいいのかも?……うーん、HDD内にKWICツールが残っていないのは不思議なんだけど、誰かが確か、フリーなKWICツールを紹介していたような記憶が……。

まだまだもめています……Wikipedia‐ノート:検証可能性。

 でも、だいぶハッキリしてきました

 とりあえず、

までは確認。

 論議の内容を真に受けてると面食らうだけなので、あくまでもルールと付き合わせて「確認」しないといけない点には注意。


 残る問題は「根っことなるサイト/文献が公知済みではない場合の取り扱い」について。

 これが「自主公表された情報源:公式サイト」が適用される記事では「自主公表された情報源を(一対一で対応する記事に限っては)信頼できる情報源と見なすことができる」という理屈であれば、飛鳥の場合は

に分けて述することで要件を満たすことができ、かつ「ブログ伊豆別館」へのリンクは(ブログトップに案内があるので、そのまま)貼ることができる……という事になるはず。伊豆本館へのリンクは「公知文献」がなければ貼ることができない(もしくは、ブログ伊豆本館@WaybackArchiveへリンクを貼ってもらえば大丈夫)。


 公知文献をつける場合は、これらの「自主公表された情報源:公式サイト」を補完するために従として使用するべき。主として使用するとこの要件を外れてしまい、自主公表部分を排除しなければならなくなるので(ってゆーか、飛鳥に関して主の文献を書くのは相当大変だと思うけど……)。


 ……つまり、キー配列関係のサイトについては「配列名」で記事を作ることはできず、「サイト名」で記事を作る必要があるのか?……現行記事は改名対応が必要かも。

 出だしを「○○配列とは日本語入力の〜」にするのはもちろんダメで(主体は配列ではなくサイトなので)、「○○○(サイト名)は、○○配列という日本語入力〜(中略)〜サイトである。」になる。冒頭以外はサイトと対応関係が明らかでさえあれば、それで大丈夫。

 

 ……と、あわてて対応してもろくなことがないので、とりあえずは静観。

第2弾の清掃作業完了。

 朝10時から今まで、たまに休憩を取りつつ自室隣の通称「資材置き場」を片付け続けていました……。

 その部屋は元々、大きめのスピーカ(Diatone/DS-77Z+DiatoneDK-77X)を置いてリスニングルームっぽく使っていたのですが、ヘッドフォン依存期間が長すぎて、すっかりとごちゃごちゃな状態になっていました。


 第1弾清掃はずいぶんと前に「書籍の売却」という形で行ったのですが、そこからだいぶ放置したままになっていました。

 今日は久しぶりの3連休なか日ということで、張り切って第2弾清掃を行いました。

 ……可燃ごみ袋を6枚、容リごみ袋を2枚、不燃ゴミ袋を1枚使うという大掃除になってしまい、かなり疲れています……orz

 #おまけに、こんな夜更けになってからダイソン掃除機を使ったもので、あの甲高い騒音がさらにうるさく聞こえる始末……orz


 それにしても、しばらく前に捨てていたと思っていた「空と海を越えて」のVHSテープを再び発掘(^^;)したり、英辞郎の本

100万語収録のスーパー英和・和英辞典「英辞郎」

100万語収録のスーパー英和・和英辞典「英辞郎」

を発掘したり(データHDDにあるけど、本が行方不明だった)と、色々なものが見つかりました……。

 #そういえば「空と海を越えて」はDVDなり高規格VDで発売されたりは……しないのだろうか。紛失直前の時点ですでにスキャンミス寸前(部分的にテープが伸びてピッチが逝かれているのだと思う)だったから、怖くて再生機にかけられないし。


 さて、明日は残っている部分(清掃中に自室へと移動してしまった分とか)の片づけをしなければならないわけで……いつになったら完了するのやら。

2006年07月15日 土曜日 しゅっぱんしそびれ。

メモ

 e−NOVELSに『作家と電脳書斎 美しい日本語、素敵なパソコン』があった。

 でもこれ、公知って言うのかな……しかも「飛鳥」という言葉は含まれていないし、原典はWaybackMachine経由でしかページを参照できない(しかも毎回文字コードをSJISにしないといけない?)し……微妙だ。


 Rayさんの伊豆本館をWaybackArchive経由で眺めていたら、QWERTY@飛鳥味というものを見つけた。

 それと、久しぶりにRayさんが2chにコメントしていた。アクションがあってからでないと「心配してた〜」とか言えない気がするもので、今日のコメントを見てちょっと安心しました。

なんてこった、信じられない!旧版だったのかよ。

 日本語Wikipediaにあった「理解しがたい内容だったWikipedia:検証可能性」が、実は旧版だった事が判明(……って、Wikiシステムを使っているから当然ですね……ついさっきまで気づきませんでしたorz)。


 英語版の議論は日本語版での論議と妙に方向性が違うように見えて「??????」となったので(もちろん内容はわかりません)、英語版の「en:Wikipedia:Verifiability」を機械翻訳にかけてみました。


 ……明らかに理路整然としたルールに変わってますよ^^;。

 これで(誤訳さえなければ)配列系の記事は(Webソースとする場合であっても)存続確定になると思う。もちろん飛鳥は書き直しになるわけですが。

飛鳥の開発過程を整理(メモ)

 リンク先は全て伊豆本館の内容をWaybackArchivesが保存しているもの。

 Firefoxでは文字化けするので、文字コードを「Shift-JIS」にしてご覧ください(Alt→V→Cで選択肢が出ます)。

  • はじめに

理想の日本語入力を求めて

飛鳥の表紙(「ゆめ」へのリンクを含む)


配列を作る理由:序章(名称決定まで。23:51 00/10/30 〜20:12 00/11/26)

初期配列図など(零式1〜35+、「キスも好き配列」は零式35。23:51 00/10/30 〜7:02 00/11/24)

飛鳥9(飛鳥8〜13+、Lは「すかあ」)

Last(Last〜Last12、Lは「すかあ」、数字段はLast1まで「1234567890」でLast2以降が「3215467809」。)

Last(Last〜Last12、Lは「すかあ」、数字段はLast1まで「1234567890」でLast2以降が「3215467809」。)

last12&finish1〜finish4

飛鳥21世紀1〜55(Lは「すかる」〜「すかく」へと入れ替わっていたり、数字段は飛鳥21c11まで「1234567890」で飛鳥21c12以降が「3215467809」。)

飛鳥21世紀55〜85

飛鳥21世紀85〜120

飛鳥21世紀121〜123

飛鳥21世紀124〜138(飛鳥21-138では、左手ホーム段アンシフトが「じてしうぎ」……「う」は人差し指にあった。)

飛鳥21世紀139〜160(飛鳥21-139では、左手ホーム段アンシフトが「じしうてぎ」……「う」が中指に来たのはここから。)

飛鳥21世紀161〜180

ということは……

名前の由来

参考文献の2打鍵目、2005年、347番にて、次の2点が由来とされている。

* 「飛鳥」命名の由来は、かつての配列案にて「L」のスイッチに偶然「す(su)か(ka)あ(a)」の3文字が集まっていた事による。それ以前には名前が決まっていなかった。

(from 飛鳥配列 - Wikipedia )

ここはWaybackArchiveの記録をつけて「20世紀版の飛鳥では」として良いのか。


 大嘘を書いていた。ここは訂正だな。

公開開始日時

* 1999年頃から開発が始まった。

(from 飛鳥配列 - Wikipedia )

 計算するときには日付が解らなかったので、2000年12月31から数えて「約2000日」と書いていたわけで……どうしてここで1999年なんてボケをかましたのかは謎。

 飛鳥の基となる「零式」の公開が2000/10/30だから、それをそのまま転記で。


 ついでに飛鳥の「正確な」開発期間も判明。

配列完成日時

* 約2000日に及ぶ開発期間を経た2006年4月25日18時56分6秒に記事「飛鳥開発終了&最終版公開」が公開、「飛鳥配列」の開発終了が宣言された。

(from 飛鳥配列 - Wikipedia )

 飛鳥の基となる「零式」の公開が2000/10/30、開発終了が2006年4月25日18時56分6秒なので……日数ベースで計算して2003日、零式公開の時間帯によっては2002日とする必要があるかもしれないが、結局のところ「約2000日」というよりは「2002日2003日」と書くほうが良さそう。


 さて、WaybackArchiveにあるといつ消えるか解らないから……どうしよう。

 このまま検証可能性を満たすのはちと難しいかも……どこかにミラーサイトでもあればいいのだけれど。

2006年07月14日 金曜日 いんようするくせを。

メモ。

 飛鳥配列が論文・雑誌で取り上げられたことは本当にないのか?というお話を頂く。

 風(日本語IME)の論文で【「飛鳥(あすか)」の様な特殊読みへの対応方法については未定】という文は見つけたけど、それはどう考えても関係ないですし……うーーーーーーーーん……。

( http://www.oyayubi-user.gr.jp/OYA-DENNOU.pdf p7 by Rayさんな話は関係ない様な気がするし……)


 ロマかな全般@かえで式、「あ・う・お」段はキャンセル

 ー番最初の右手連習「いうお」は「いゆよ」に変えて、他も「やいゆえよ」の5母音のみで構成する。

 練習順序は完全左右分離にして、

まず「か」たてから「え」んえんと「で」きるまで練習する練習方「式」

にする。左右分離配列の場合、連習しない方の手は中段中指のみ使う。

 「小書き文字は(たとえ打ちづらくても)発音速度に引きずられて早く打たれる」特性を生かす。Yを抜けば清音になる……という説明が有効かどうかは怪しいけれども。

ご迷惑をおかけしました……「記事」飛鳥配列は、記述とソースの対応関係について説明することが出来そうにありません。

 最後の最後、悪あがきをしてみようと対応関係を調査してみました……が、「纏めることだけ」を考えていて「ソース記述の対応」について考慮していなかったことが災いしてしまう結果となりました。

 ……変に纏めようとせず、ストレートに対応関係を書いておけばよかったといまさらながらに後悔していますorz


 他のキー配列記事に関しては、今からでもまったく遅くはないと思いますので、公式サイトなりまとめWikiなりによって「原典となる文章」を明示いただければ、それで大丈夫だと思います。

 #とりあえず、原典と記事の対応関係が容易に把握できれば「Wikipedia:検証可能性#自主公表された情報源:公式サイト」の条件に合致するので、それで大丈夫だと思います。


 うーん……飛鳥カナ配列について「Wikipedia:検証可能性#自主公表された情報源:公式サイト」に適合しつつ「トレーサビリティ確立された状態」で記事を書けるかどうかについて考えてみたのですが、ちょっと現状の私には無理そうです。

 #それができるのならば、何度も日記に「下書き記事」を書く必要などなかったわけでして。


 とりあえず、本件に関しては白旗を揚げるしかありませんね……いや、(まとめ記事を書き始めた時点で)元々そうなる運命だったのかもしれませんけれども。

ビックリしたっ!

(元ネタ: http://pc7.2ch.net/test/read.cgi/pc/1107616390/544-546 )

 渡辺定久さんの「カナタイピストにおける指の運動特性について」が2chで引用参照されてる!

 ……って感動したばかりなのに、その後に私の主観を引用している方がいるわけですがorz

 #あそこだけ引用しても、論議の足しになりませんよ〜


 もっとも、「調べてから書く」とか「実験してから書く」というのは案外と重要(→車輪を再発明せずにすむことが多い)なので、全体的にはいい傾向かな、と思いました。

 #……もちろん、自分に対する反省の意も込めつつ。


もうひとつ驚いた。

(元ネタ: http://pc7.2ch.net/test/read.cgi/pc/1136856710/674 )

 674さんに対しては「査読頂きありがとうございます!」と言いたいです。

 http://d.hatena.ne.jp/maple_magician/20060708/1152367614

で白状したまま放置していた(パニック気味でそれどころではなかったという気もorz)件について、今日付けで指摘いただいています。

 だいぶ日数が離れているので、日記を見て気づいたわけではなさそうですし……。


 似たようなことがあった場合、依頼系ページに提出頂くのみではなく、そのまま編集により除去いただくこともできます(Wikipediaにログインしていなくても編集可能です)。

 おかしな部分を編集モードで除去して、投稿ボタン近くの要約欄に「独自の研究と思われる部分を除去。復帰する場合にはソースを明示のこと」という感じで書いてから投稿していただければ、それで大丈夫です。


 で、驚いたのはそれだけでなくて「(おそらくは飛鳥を)エルゴノミクスキーボード」で使っている方がいるということ……飛鳥はエルゴノミクスキーボード上でも「適切」なのだと知って、驚くと共に安心しました。

 

 1年以上も使っているくせに、自分はまだまだ飛鳥のことを知らないのだな……と。

2006年07月13日 木曜日 はくしかすることに。

メモ。

 いろいろ考えたけど、飛鳥配列-Wikipediaは「文献が出るまで白紙化」する方向で。即時削除対象に。

 文献を元に書くとしても、今の記述と整合性をとるのは難しいし、そもすそもWikipediaに記述を残す「必要性」と「メリット」がないんだよな……

 まったく関係ない分野の削除依頼で、記事の現状を「先行例」として使われたくはないのですよ。

結局

 今ある「自主公表された情報源:公式サイト」はいつ消されてもおかしくない(というか信用できない)のですよ。

…ということは

 ノートに注記を書いて「原典」タグを貼ればいいのか?…うーん。

やっぱり

 安全側にたおす方が良さそう。

ってことは

 「秀逸な記事の選考」側にも検証可能性適合指令が必要、と。

しかし

 いつまでもこれに人日を割く暇があるわけではないから、早目に切りあげたい……

結論

「自主公表された情報源:公式サイト」をあてにせず検証可能性チェック、白紙化になるので即時削除で。作業は明日に。

論文経由法について調査せねば。

査読付である必要はなく(ここが重要)、「公知」と見なせる方法で発表できればOK。

とにかく

 飛鳥は嘘ではないし悪くもない。悪いのは掲載手順であり、私の責。

2006年07月12日 水曜日 りふぁれんすいらい。

Wikipediaに対するひとつの疑問。

 調べて書くのが原則のWikipediaに、なぜ図書館機能の一つと同じ「Wikipedia:レファレンス・ワーク依頼 - Wikipedia」(文献照会参考調査依頼)が無いのだろうか。これがあれば大部分の記事が救えるのに……。

 ルールを作るよりも、ツールを作る方が先だと思う。現状はどうも、やることの順番が逆な気がするんだよな……

結局

 「Wikipedia:井戸端#「Wikipedia:レファレンス・ワーク依頼」の提案」をポスト。

 Wikipedia‐ノート:検証可能性#幾つかの問題点最後尾では「whaT Then whY」へのリンクを貼ったのですが、アレが嫌味の類などと誤解されないことを祈るしかないですね……。

舞台裏では

 書いたコメントを8kbほど、投稿前に捨てました。

 始めは「ルールに則った全記事の即時保護方法(反証のために書いた話が、書きあがってから気づいたら「合法荒らし」の手順解説と同一になっていたorz)」とか「単なる嫌味にしか見えない文面」とか、そーゆー下らないものしか書けなかったのですよorz

 #そうして夜は更けてゆく……って、ホントに何やってるんですか私は。

2006年07月11日 火曜日 かんちょくのつぎを。

メモ。

 黄砂の方法ではダメ。音連想+位置連想の2段階になってしまう。

 いっそのこと、右シフトと左鍵盤の使用を取りやめて秋月式に漢字ならべて、12字づつお経のように覚える……?

 今日は23時には寝ます……今日一日鼻炎がひどくて、普段よりも余計に体力を使ってしまったもので……。


 黄砂配列、音連想+位置連想の2段階になってしまう。

 音連想2打鍵+位置連想1打鍵という方式が悪いとは言わないけど、漢字を使うのならば「意味の似た字をグループにしてしまう」方が、打鍵数を節約できるし位置連想2打鍵でも実用になる。

 ……って、中国の漢字じゃ理解できないしorz

 和文漢字用として、漢触こーどをばらして組みなおす方が良さそう。

 電卓の様に右手だけで文字けん盤を叩くことにして、文字けん盤は12けんに制限する。右手シフト(同手シフト)は親指シフトのかな入力と混同するので排除する。始めがスペースシフト固定+文字キー12けんの同時打鍵→次が無シフト(無シフト面かなに続きやすい漢字)・左シフト(左シフト面かなに続きやすい漢字)・スペースシフト(漢字熟語に使われやすい漢字)+12けんの同時打鍵だから……12×3×12=432字。

 ……と、やるかどうかは解らないので、とりあえずメモのみ。


 参考文献欄を「文献」と「Web資料」に分けて記載する。

 査読つき文献のみで書かれている記事は自主申告で☆☆☆。

 通常文献が混じっている記事は自主申告で☆☆。

 Web文献が混ざっている記事は自主申告で☆。

 文献がそもそも使われていない文が混じっている場合は「参考文献募集中」ってラベルを貼ればいいんじゃないかな……って、テキトーすぎるかorz

 

2006年07月10日 月曜日 せんだいのほうげん。

メモ。

 仙台弁の「ラムちゃん語」を結果から資料のつみ重ねに置きかえれば、検証可能性について説明しやすいかもしれない。

「飛鳥配列 +ウソ記事」ですか……orz

(参考:Google:飛鳥配列 +ウソ記事)

 ほとんどがRSSがらみなので、そのうち落ち着くとは思いますが。

 それ以前に「ウソ記事」という言葉の響きに驚かされてみたり。

 というか、Wikipediaを宣伝の場として使っていると思われていたこと自体にガッカリしているわけですが……orz

 そう思っているなら削除依頼に出さず、該当しそうな範囲を一切合切日記に書くようなこともせずに黙っていますよ。

 どんな想いで削除依頼に出したのかを理解してください!とか言うつもりは毛頭ありませんが、始めからありもしない考えがあるものと想定してかんぐられてしまうと、非常に悲しいのですよ。

 やっぱり、論文……書かなきゃダメなのかなぁ……orz

 #つーか、高卒の私に情報処理学会への入会資格なんてあるのかしら……orz


 で、そのつながりで拝見したこちらのページ。

 http://d.hatena.ne.jp/essa/20030516/p2

 Wikiシステムにおいては検証可能性を要求しないものが多いので、指摘されている問題はどうしても出てくると思います。

 日本語入力用キー配列のリンク集では「文章の記述を禁止」という極論でそれを防いでいますし、NICOLA初心者にささげるWikiテーマを極限まで狭めてそれを防いでいたりします……って、それは本題とは無関係ですな。


 翻って、Wikipediaの場合は……essaさんが指摘されていた内容については「Wikipedia:検証可能性」によってその正確性を担保されることになるので、恐らくは自動的に良い状態へと向かっていくことになるはずです。

 「査読されていない文献に基づく記述」を完全になくすことはできない(Wikipedia:検証可能性が「例外」を認めている)ものの、どちらにせよ「そもそも文献に基づいていない記述」は自動的に排除されることになるだろうと思われます。

 もちろん、時間は掛かると思います……それでも、今はまだ「記述の基となったURLすらない記述が大量に混ざっている」Wikipediaが、「せめて全ての記述が何らかの資料/URLなどに基づいている」Wikipediaになる意味は、非常に大きいと思います。まずは「とりあえず資料/URLに基づいて書く」という段階をクリアしないと、その先の「信頼のおける資料に基づいて書く」という段階には絶対に至れないわけですし。


 似たような問題が「査読依頼」にもあります。あちらは「名前に偽りあり」で、今はまだ厳密な意味での「査読依頼」として機能しておらず、感想その他も書けるようになっています。

 これも制度が認知されるまでの暫定的な処置で、そのうち「査読依頼にポストするべきか、あるいは他の依頼ページにポストするべきかを、見るだけで誰にでも判別できる状態にする」必要があるだろうと考えています。いきなりやるのはどう考えても無理ですので(実際、急ぎすぎて最近失敗してしまったばかりですし)、こちらもゆっくりとやっていくしかないでしょう……と、割と悠長に構えていたりします。

 Wikipediaには専門の査読士が居ないので、普通のWikipedianが査読を兼ねなければならないという事情もあります。

 Wikipediaの記事は、未だに多くが参考文献をろくに示されていない(あってもページ名が示されていない)ので、公立図書館(最終的には国会図書館)で文献にあたるのが非常に困難です。せめてページ数まで明示されていれば「国立国会図書館郵送複写サービス」経由で該当ページのコピーを入手できるのですが……もっと「査読検証しやすい方法を確立する」ための手法を提供するべきかと感じています。


 査読による検証可能性向上への試みとしては、すでにACT (キー配列)該当記事のノートにあるような試みを、削除依頼と前後して自主的に始めています。

 記事を厚くする基礎と言う意味では、安岡先生最近精力的に参考文献の追加を行っていらっしゃいますし……こういった取り組みがどこまで浸透するかは不明ながら、できるところからやっていくという姿勢は、今までどおりということで。

 #何もしないでへこたれている訳にはいかないのです。

2006年07月09日 日曜日 ろんぶんをさがして。

メモ。 

 ハードディスクの容量が約10倍になる技術をSeagateが開発

 かつて5インチベイからHDDが消え去ったように、そのうち3.5インチベイからもHDDが消え去る時代が来るのかも。1インチHDDに120GBのデータが詰め込める時代は、もうすぐそこに。


 「Wikipedia:検証可能性」について、もう一つ気づいたことが。

 「書き込む人×書き込む回数」が多い記事ほど検証可能性の立証は難しくなり、注目されてない記事は逆に「言葉のトレーサビリティが保たれている(白黒の判断を付けやすい)」という状況ゆえに、「俗っぽくない記事」の方がより危険といえる。

 たとえば……参考文献無しの巨大記事「仙台市」(個人的にはいい記事だと思う……長すぎるけど)を始めとして、該当範囲は恐ろしく広い。

 初めから「Wikipedia:検証可能性」があれば、全てうまくいっていたはず……もったいない話だと思う。

 「Wikipedia:検証可能性」が「根拠のない記事の排除」を目的としていて「これで【妙な記事だけ】が消え去るだろう」と考えていたのならば、その考え方は根底から間違っていると思う。消える記事に【妙な記事】は含まれず、【根拠を示していない記事】が消え去るのだから。

とりあえず「ACT - Wikipedia」の改訂を完了。

(過去:ACT - Wikipediaの「基本配列」を整理、「省打鍵配列」を作成。)

(関連:ACT_(キー配列) - Wikipedia)

 初版作成から412(!)日を経て、ようやく記事らしい体裁になった……のかなぁ^^;結構心配だったり。

 特に心配なのが「ACTの省略打ち配列」部分でして、アレって秋月かな方式で纏めてしまってよかったのだろうか……とかそういうあたりですね。

 もう一つは、ACTによって生じた制限(子音キー重ねによる撥音の問題)と、ACTの入力規則をごちゃ混ぜにして書いてよかったのだろうかというあたり。とはいえ、ここは分離して書くとかえってわけが解らなくなりそう(実装する上では分けて書いた方が良いかもしれないものの、使う上では別れている必然性がない)なので……うーん、やっぱり分けるほうがいいのかも?ちょっと判定しづらいです。


 一応、他の配列にからむ表現は極力抑えてみました(文献にごく少量言及があるのですが、なるべく意図をそのまま生かしてみました。余計なことは含めていません)。

 うーん、どうしよう……査読依頼に出してみようかなぁ。でも、AZIKと違ってオンラインのみで文献をGetできるというわけではないし、表現中心orWeb公式ページを基にした査読になるだろうから、どこまで突っ込んで査読していただけるかどうかは解らないか。


 とりあえず、ACTについてはひとまず完了……でいいのかな?

 さて、次はどうしようか。個人的には「花」に取り組んでみたいところで。

 今までかな配列に首を突っ込んでいた時間が長い割には、中指シフトの元になった「花」についてテンで知らないことばかりなわけですから。

結局

 査読依頼に提出してきました。

 Wikipedia:査読依頼/ACT (キー配列) 20060709

 もしかすると、木村先生のところに「査読するから参考文献を……」という話が行くかもしれません。


 できれば、この「実際に文献を手にとって査読する」というスタイルを、きちんと確立させたいんですよね。

 もともとWikipediaでは専門の査読士をつけるということが原理的にできないので、翻って「文献と記事を見比べる」という行為が、どうしても必要なので……文献の入手先や入手方法を(なるべくオンラインのみで完結できる方法から優先して)紹介していますが、それが機能しなければまるで意味がないですし。

 うまく行くかどうか、査読期間中は見守っていきたいところです。


 さて、次は花を……の前に、一旦寝ます。

論文PDFが壊れていた……orz

 情報処理学会電子図書館から、次の文献をダウンロード購入しました。

IPSJ-HI89026003-PDF 自由打鍵実験による打鍵時間分析

IPSJ-HI89026002-PDF 中指シフト仮名文字配列「花」

IPSJ-HI86009002-PDF 超多段シフト和文キーボード

IPSJ-JNL3007006-PDF 超多段シフト和文鍵盤

IPSJ-HI84018001-PDF 日本語入力用ローマ字キー配列最適化

IPSJ-JNL2806013-PDF 日本語入力用新キー配列とその操作性評価

 ……ところが、「超多段シフト和文鍵盤」の2ページ目が破損していて、内容を読み取ることができない状態だったりします。

 うーん……まずは「花」について書くからいいとしても、出来るだけ早急に直していただきたいところです。

「花」の論文をちらっと見た感じでは……

 「自由打鍵実験による打鍵時間分析」はだいぶ推論が混じっていたような気が……それはいいとして、あまり「月配列」に直接的に役立つ話ではないような気がします。

 一方で「中指シフト仮名文字配列「花」」は、色々な視点があって面白いですね。こちらを見て興味を持った方が「自由打鍵実験による打鍵時間分析」を見る……という具合でよいかと思います。


 「中指シフト仮名文字配列「花」」で面白かったのは、「習熟の容易さと配列の効率についての考え方」ですね。

 それと、(ローマ字配列についてはSKY論文を未読なので解らないのですが)かな系配列としては「はじめて段ずれがある通常けん盤を用いて配列設計用のデータを取った」と言って支障がなさそうです。少なくとも、新JISNICOLAは碁盤目状けん盤を用いて最終設計を行っていますから(あっ、新JISJISかな時点では段ズレけん盤を用いていましたか……微妙だなぁ、どちらが先とは容易に言えないのか)。


 一つ疑問に思ったのが、なぜシフトキー位置の再設定にまでこだわって書かれた論文で「濁点と半濁点は一文字として数える(かなの数を90弱ではなく63=JIS同等とした)」方法を用いてしまったのか……他の要素をことごとく初期状態へと戻してから再設計しているだけに、その点だけが妙に気になってしまいました。

 #そういえば、カギカッコの再配置が設計段階で除外されている理由は「基となった頻度表(坂村健先生BTRONけん盤論文にある、ビジネス文から抽出したもの)で低頻度だったから」だそうです……私の日記では(ずいぶんと狭い範囲だな^^;)だいぶよく使うのですが……うーん、基礎となるデータ次第で色々変わるんだろうなぁ。


 かな頻度表にはBTRON論文ビジネス文頻度をそのまま使用し、打鍵時間データは「自由打鍵実験による打鍵時間分析」の(文字を頼りにせず自由に打鍵させた)自由打鍵データを基にしている……と、花の設計はそこから始まっているようです。

「自由打鍵実験による打鍵時間分析」は「打鍵所要時間」だけではなく「指が負担するべき指使用頻度」の為にも使われた。

 「中指シフト仮名文字配列「花」」では、今ちょうど話題になっている「どの指にどれぐらいの負担を強いるべきなのか」ということについても、「自由打鍵実験による打鍵時間分析」の結果を用いています。

 より正確には、「自由に打鍵した結果」であるから「打鍵所要時間を図ることができる」のみならず「疲労によって無意識の指使用制限が働くから、結果として指の使用頻度も測定できる」という具合になっているようです。


 「自由打鍵実験による打鍵時間分析」でランダム打鍵をした結果、人差し指・薬指・小指の使用率がそれぞれ14〜16%あたりであるのに対し、小指だけが4%台という極端な差を示していました。


 (論文に書かれている)シフト位置問題についてはとりあえず置いておくとして、この「指の使用頻度を【長時間の自由打鍵】により決定する」という方法論は面白いと感じました。

 かなに引きずられてはいるものの、Rayさんがやっていた「評価打鍵」と仕掛けが同じだと言うこともあり、この方法で指に負わせるべき負荷を決定させると言うのは、十分納得できる話かな……と。

 #打鍵時間のみを基に設計する場合「人差し指に極端な負荷が掛かる配列が出来上がってしまう」ことについても、論文では言及されています。両人差し指の頻度合計が65%(英文配列)という配列が公開されていたことも記されていて、花配列はそれを防ぐために指の使用頻度を別の指標に求めたということのようで。

花が目指した理想の配列とは。

 そのままコピペするのはアレなので、論文中のグラフから概要を手書きしてみました……

f:id:maple_magician:20060709204813p:image

 評価軸が2つあるのでベクトル化計算している……とか何とか。数学がからっきし苦手なので、いまいち意図を理解できませんでしたorz

 でも、言葉であれこれ書くよりもグラフの方が解りやすいような気はします。

 #だからといって、すぐに「どうやれば計算できるのか」を思いつかないあたりはアレなのですが……orz


 それと、自由打鍵から得た目標指負荷グラフ(ほぼ花配列の仕上がり負荷と同じ)から、数字を無理やり読み取ってみました(正確なパーセンテージは掲示されていなかったのです)。

左小指 4.5%

左薬指 13.5%

左中指 13.5%

左人差し指 15.5%

右人差し指 17.5%

右中指 15.5%

右薬指 14.5%

右小指 4.5%

※グラフから値を読んだが、筆者の経験的知見による補正がされているので、それを差し戻した。

 小指の使用率が異様に低いのは、たぶん「自由打鍵だから」なのだと思う。テキトーにやっても押せる他の指と違って、小指と親指って「意識しないと使わない」ような感じもするし……

 指負荷の特徴としては、親指シフトに割りと近いように思う。というか、両小指から合計9%を抜いて、右手人差し指〜薬指に3%ずつ加算した値にきちんと符合する。


 ……と、こんな感じで「花配列」の記事も書かずに文献を読みふけっていました。だいじょーぶなんですかこんな事で^^;

2006年07月08日 土曜日 りゆうがないとだめ。

とりあえず「削除」なのか「存続」なのか、ハッキリしてください!

(参考:Wikipedia:削除依頼/飛鳥配列)

(参考:Wikipedia‐ノート:検証可能性#本人を情報源にする場合)

(過去:Wikipedia:検証可能性関連。)

(参考:Wikipedia:検証可能性#自主公表された情報源:公式サイト)


 正攻法で「やっぱり論文を書いて、きちんと査読に当たって砕けて……」という方向であれこれ調べているうちに、Wikipedia側の記述に穴が開いていることに気づいてしまいました(ううっ、すごく嫌なパターンだなぁ……気づくべきじゃないでしょorz)。

 おそらくは合議で適当な方向に修正されるであろうと期待しています……が、これを見つける前にジェノサイドが開始されていたら……と思うと、正直言って冷や汗ものかも。

 #別の理由でジェノサイドが可能だということに気づいた上に、よりにもよってそれを書いてしまったという問題はありますが……アレは元々避けようがない気が。


 うーん……帰りが遅かった上に本件検証等々で4時間近くを浪費。結局、記事ACTの下書きにすら入れませんでした。最悪。

ACT - Wikipediaの「基本配列」を整理、「省打鍵配列」を作成。

(過去:ACTの記事構成(メモ))

 だいぶ時間が掛かってしまいました……とりあえず、ACT_(キー配列) - Wikipediaのうち、キー配列表の部分だけを手直ししてきました。

 元々3枚あって冗長だった基本配列部分は、紀要文献を参考に圧縮して1枚にしました。

 省打鍵配列の部分は、旧版の秋月かな配列と同じように「縦に3キーのプレフィックスシフトが並んでいる」状態で表記してみました。

 本来ならば漢直配列表の様に「各キーごとにシフト面を2次元的に表記する」方が直感的に仕上がるのかもしれませんが、HTMLブラウザに表示するときにどこで改行されるかわからないので、被害を最小限度に抑えるべく「横方向については別表へと切り離す」方向で対処してみました。

 表だけでは見づらいし、説明をグダグダ足すと解りづらくなるので……そのあたりは表ごとに【打鍵例】をつけてみました。


 ……さて、ようやく本文に取り組めそうです。

こんな自分がすごく嫌です。

(参考:Wikipedia:削除依頼/飛鳥配列 - 版間の差分)

 この件に絡んで延々と悩んでいるのですが、もしかして今のWikipedianが共通認識として持っている意図は「有名なものは良い、無名なものはダメ」なのかな……と感じ始めています。

 ……いや、私自身もそう思っていました。

 ところが、Wikipediaの方針文書を読んでいくと、どう考えてもその基準では説明できないんですよ。

 私が読んで理解した結果を端的に表すと、「Wikipedia事実を創造する場所ではない。」という言葉以外に、うまくWikipediaの方針を表現できない気がするのです。


 その考え方でいくと、飛鳥配列 - Wikipediaからは次の文を排除する必要があることになります。

# 配列考案者自身がごく一般的な日本語キーボードを用い、長時間の評価試験をしつつ無理な指運びを排除するという手法を繰り返すことにより、結果的としてはエルゴノミクス(ergonomics)対応を行っている配列でもある。

# 従って、いわゆるエルゴノミクス対応キーボードを用いる必要は無く、一般的な日本語キーボードを用いる方が、利用方法としては適切である。

(from http://ja.wikipedia.org/wiki/%E9%A3%9B%E9%B3%A5%E9%85%8D%E5%88%97 )

 これは「まとめ・独自の見解」なので(Rayさんはエルゴノミクス対応という表現を使っていないはず)、「Wikipedia事実を創造する場所ではない。」というルールには引っかかってくることになるはずです。


こんな自分のどこがいやかと言うと

 Wikipedianの暗黙知よりも、Wikipedianの方針を優先させてしまうあたりとか……。

 ……って、暗黙知が間違っているかもしれないから微妙なのですが。でも個人的には(Wikipediaにおいて)すごく嫌な立ち回り方をしていると思います。

結局

 Rayさんが情報理論文を一本書けば、全て丸く収まるんですよね……orz

2006年07月07日 金曜日 あくとのきじせいり。

メモ。

 月配列の新規性は「組み合わせかた」に依存しているそのもの。シンプルに書いても十分伝わる内容で、基本性能は新JISと花が担保になっているから、うまく書けばAZIK/ACTよりも証明しやすい可能性がある。同じ評価方法・引用中心で。あるいは、AZIK/ACT/花の論文はいくつかが情報処理学会にあるので、情報処理学会経由で入手できる論文+JIS C 6236(JIS X 6004)のみを用いて論文を組み立てれば、情報処理学会に入っている人が検証する上で非常に都合がいい。新規性をアピールするならば、ローマ字入力のみとの比較ではなく、Qweローマ字/AZIK/ACT/花/新JISと一揃いに比較する方が良いかと。ローマ字系とかな系の得手不得手・中指シフトと外方シフトの得手不得手に言及する(長所・短所ではなく)とか。

 ……飛鳥については、まだ考えなし。


 とりあえず、月配列の「論文」を作成してみては……?と、そんなことを考えていたり。

 「メディアに取り上げてもらう」のと違って「勝手に印象操作されず、書くべきことをストレートに書ける」から、かえってこの方が配列関連には向いていると思う。

 もちろん、査読でハネられる可能性はあるけど……やってみる価値はあると思う。

 #但し執筆は2ch以外で(著作権がらみに少しばかり不安があるので、「wiki」「掲示板」「はてなグループ」あたりを利用する方が安全だと思う)。

ACTの記事構成(メモ)

ほぼ論文の構成をベタ写し。

  • ACT成立の背景
  • DSK配列を和文入力に用いる上での不満点、いくつかの解決方法。
    • 増田さんの提案、Cキーをカ行に。
    • Aki:zさんの提案、拗音化キーにH/Nを。
  • 名前「ACT」の由来
  • 実装方法
  • ACTの入力規則
      • カ行の子音キーはC。
      • 「っ」はLか’を使う。
      • 「ん」を単独で打つ場合はNN
      • 他の小書き文字はShiftキー+1ストローク目のキー
      • ai/uu/ei/ouは左手母音キーの上、子音を伴う場合にのみ機能する。
      • ann/inn/unn/enn/onnは左手母音キーの下、単独打鍵でも機能する。
      • 左手側の拗音化キーは右手ホーム段薬指。
      • 「段移動したついでに」押せる操作がある。
        • 子音キーに続けて右手同段の中指を打つと「■yuu」
        • 子音キーに続けて右手同段の小指を打つと「■you
        • 右手側の中指・薬指・小指に続けて右手同段の人差し指を打つと拗音化。
        • 右手側の人差し指に続けて右手同段の薬指を打つと拗音化。
          • 拗音化後に右手の薬指をつづけると、反対側の手にある母音Oと更にKUが付き「■yOKU」となる。
          • 拗音化後に右手の小指をつづけると、反対側の手にある母音Aと更にKUが付き「■yAKU」となる。
          • 拗音化後に右手の中指をつづけると、同手中指ホームにある子音Tの前後にUが付き「■yUTU」となる。
          • 残りの子音キー同士の組み合わせ空きにも、頻出文字列を割り当てている。
  • ACT基本キー対応表
    • 一段目に英字、二段目に一打目、三段目に二打目、四段目に三打目を書く。
    • 一段目に一打目、二段目に二打目、三段目に三打目、四段目に元の英字配列を書く。
  • シミュレーションによる結果
    • ……は省略する方が良さそう?
    • あるいは、ACT 1〜4を例示する。
  • 考察

 ……これでいいのかどうかは考え中。

 少なくとも、かつて作ったキー配列表は見づらいので……何とかせねば。


頻出文字列用キーテーブル案メモ

fgcrl

dhtns

bmwvz

1打目の音に引きずられる。

1打目人指伸に色づけ、二打目となるキーに上から人指伸上段・人指伸中段・人指伸下段キー打鍵後に打鍵した場合のカナをプリントする。

・・・・・・じゃだめか。

二打目の人指伸ばすキー三段すべてに色づけ、1打目となるキーに上から人指伸上段・人指伸中段・人指伸下段キー打鍵「前」に打鍵した場合のカナをプリントする……つまり、かな表記を押した後に色づきキーの指定段をたたけばカナがでる。

かなプリント→色づけキー該当段でストロークを表記。

二打目の人指伸に色づけされている場合、1打目鍵盤としては次のように例示する。

   この列が三段にわたって色づけされる。枠内は三行。
   ↓↓
ぷり ふり ×  ×    ×  ×  
×  ×  ×  かた   ×  ×  
×  ×  ×  かんがえ ×  ×  


   ×  ×  とり  なり   さり
   ので ほど という など   され
   ×  ×  たび  なければ ※SN:しなければ


   ×  ×  ×  ×  ×  
   ×  まで ×  ×  ×  
   ×  まで ×  ×   ×  

※↑の配列図は未チェック。たぶん間違いがあると思う……。

2006年07月06日 木曜日 もだぷつにたよるか。

メモ。 

 人力作成配列の評価方法……に、モダプツ法は使えるのだろうか。

 というか、これを持ち出すと絶対に「モダプツ法はロールオーバー打鍵を扱えないし、同時打鍵系配列に有利な結果が出て当然だろ!」というツッコミが入ることは間違いないんだよなぁ……。

 打鍵速度は必ず平準であると見なして、打鍵アクション数を片手ずつ見ればいいのかも?あっ、そうすると今度は飛鳥の「対手連続シフト」を扱えないし……やっぱMODAPTSじゃダメかorz

漢字直接入力の論文、探してます……と言うつもりが。

(参考:http://taffy632.blog24.fc2.com/blog-entry-358.html#comment330)

 安岡さんによる追記で、一気に節「参考文献」が登場しています


 とすると、ここに各入力方式の文献(……は探さなければならないのかorz)と、「常用者のための日本文入力法の基礎的研究について」が概要向けに用意されればしっくり来るのかも……?

 さすがに漢直をうまく説明することはできそうにないので、しばらくは様子見するつもりでいます(イイノカソレデ^^;)。


 全体的に見ると、【漢字直接入力 - Wikipedia】は「紙の辞書を持たずに漢字かな交じり文を手書きするのと同じ性質のもの」→「古くは辞書を持てない機材のために作られた入力法である」→「分類・無連想→連想」→「参考文献」→「関連記事」となっています。

 うまく時代を追って「活字盤からの植字的な要素」→「巨大けん盤による電子植字」→「最小辞書によるパターン漢字変換方式」→「単文節かな漢字変換を併用できる漢字直接入力の登場(≒漢直Win)」とかいう風に並ぶといいのではないかな、と。


 もう一つ気になるのが「連想式漢字直接入力」と「無連想式漢字直接入力」という子記事ができていること……そして、連想式漢字直接入力にあるこんな文言。

補足

連想式漢字直接入力は、親指シフト(現NICOLA)が登場するまで、一番速く入力できる入力方法とされており、当時のワープロコンテストでも上位を占めていた。実務では住所や氏名の入力に利用されることが多いため、頻出漢字の連想コードさえ覚えれば、ある程度のスピードで入力することが可能。連想式漢字直接入力に熟練したもの同士では、語句の漢字がわからないときなどに、連想入力コードで伝達しあうなど独自の文化も生み出している。

( from http://ja.wikipedia.org/wiki/%E9%80%A3%E6%83%B3%E5%BC%8F%E6%BC%A2%E5%AD%97%E7%9B%B4%E6%8E%A5%E5%85%A5%E5%8A%9B )

 うーん……純粋漢直と連想漢直もどき(注:ワープロ速記と言う方が通りがいいかも。辞書登録をフルに使って漢字もかな文字列も省打鍵化している方式)を一緒に並べて比較しても、意味がないんじゃないかと思うんですよね……漢直での学習コストと、ワープロ速記での学習コストは質や量ではなく方向性が違うわけで。

 ……って、そういうことを書きたかったわけではなくて。

 この話、どこか(雑誌/専門誌etc)に載っていたりしないのでしょうか。一件参考資料があるだけでグッと話の真実味が増すだけに、現状ではちょっともったいないんですよね。


もし問題なさそうであれば……

 漢字直接入力 - Wikipedia にも「風_(日本語入力システム)」の参考文献リストを追記するほうがいいのかも。

 #やるべきかどうかは解らないので、とりあえず保留中です。


経緯が足りてなかった。

  1. 活字盤からの植字
  2. 巨大けん盤による電子植字
  3. 最小辞書によるパターン漢字変換方式
  4. 部首合成による漢字の字形検索
  5. 単文節かな漢字変換を併用できる漢字直接入力の登場(≒漢直Win)

2006年07月05日 水曜日 かんせいしたのかな。

メモ。

 W-ZERO3のBeta1/Beta2に続き、矢継早にRC1が登場。

 http://japan.internet.com/allnet/20060704/4.html

 http://www.itmedia.co.jp/news/articles/0607/04/news089.html

 これのワイドスクリーン版が出てほしいんですけど……まだかなぁ。


2006年7月5日19:21:07の経過報告

 ただいま参考文献の「引用情報」を整理中。

 整理対象は「AZIK」「ACT」「風」「花」

 木村先生から資料を頂いた「AZIK/ACT」については、Wikipedia記事のノート部に参考文献リストを記録完了。本文記述はまだ。

 現在は、冨樫さんからお教えいただいた「風/花」の参考文献リストノート部へと記述すべく整理中。

 もう少し掛かるかも……。


 ……で、関係ないところで「空と海をこえて - Wikipedia」というアイキャッチがあり困る^^;。いや、調べものを優先せねば。

Wikipediaでの文章記述に必要な「文献」リストを作成。

 木村先生から頂いた「AZIK/ACT」関連文献の情報と、冨樫さんから頂いた「風/花」関連文献の情報を、各記事のノート記述しました。

 ええと……AZIKを使った経験がある方は、とりあえず、ノート:AZIK#利用可能な参考文献についてにある文献をダウンロードしてご覧ください。情報処理学会電子図書館はユーザ登録は無料で、提示しているAZIKの文献はPDF(ダウンロード)時のみ無料という太っ腹な扱い(ペーパー(論文単位)は印刷物渡しなので、ドキュメントの費用に関わらず費用が発生する)なので、ご心配なく。

 ……で、ダウンロードした文献を参考にしつつ「AZIK - Wikipedia」の内容を整理・拡充できそうだと感じましたら、ぜひ整理・加筆してみてください。


 記述するべきポイントは「互換性の確保を優先していること」であったり「AZIK on Dvorakへの布石」であったりと、色々見る人によって異なってくると思います。

 記事としてのAZIKシナリオは、文献と同じく「時代を追って記述する」方式をとる場合、概ねこういう内容になりそうな気がします。

  1. AZIK以外の何を試し、何に不満を抱いたか(→「SKY配列」へと繋がる)
  2. その不満を解消するために、どういう方針を立てたのか
  3. どのような入力方式のアイデアを参考にして、どのような方針を新たに導入した配列を作成したのか
  4. AZIK独自のアイデアとして、どういう方法を盛り込んだのか
    1. かな入力に近いアイデアの取り込みについて
    2. 遠いキーを使わず済むようにするためにどういう対策を採ったのか
  5. AZIKローマ字入力との違いはなにか。気をつけるべきことは何か
  6. Dvorak配列に着目した理由は何か
  7. さまざまな配列を用いた打鍵評価の概要
    1. AZIKDvorakの相性が良いことについて
  8. ローマ字定義テーブルによる限定的な実装と評価について
  9. 特殊拡張と連想記憶の関係
  10. 最終的に、筆者は何を確信したのか(→「ACT_(キー配列)」へと繋がる)。

 もちろん、始めに配列図を持ってくるとか、時系列順ではなく説明しやすいところから書くとか、色々人によってポリシーはあると思います。


 とりあえず、今日は前段階作業のみで結構疲れてしまったので^^;、実作業に取り掛かれるかどうかは微妙ですね……。


 #私の実作業については、ひとまず(AZIKの文献と違って容易にアクセスできる場所に文献がないらしい)ACTから始める予定です。それと、ACTについての文献を希望される方がおりましたら、木村先生のAZIK/ACTホームページをご覧頂き、直接先生宛に連絡されるのが確実かと思います。

2006年07月04日 火曜日 めでみてさがすこと。

メモ。

MODAPTS法と「1MODにこだわった」ACT&飛鳥……なのか?。

 飛鳥の場合は打鍵ごとにMODを計って「キー操作ごとのMOD分布をグラフにする」といいのかも。


 査読済みの参考文献があれば、削除そのものを防ぐことは可能。後は編集対応が効くので。まずはそこから。

 秋月かな、あんちょこ使用・シールなしでテスト中。

 シールは次のようにする。

けこかきくおあいうえ
れろらりるそさしすせ

てとたちつわ゛▼o
めもまみむ よやゆ

ねのなにぬんっ
へほはひふをー

 WindowsVista、えらくHDDにアクセスしていて遅いなぁ……と思ったら、コミットチャージが610MBになっていた^^;

 (推奨値そのままの)512MBしかメモリをつんでいないから、それはHDDアクセスが多くて当たり前だなorz

 仕方がないので、DDR400のメモリを積むべきPCにDDR266のメモリを増設してみました。CPUのFSBと非同期になって、かつメモリのFSBそのものが半分近くに落ちているので、「せっかくメモリを2枚差しにしていても速度的なメリットがまったくない」という状態にあります……とはいえ、HDDへのアクセスが減った分だけまだ快適かな……という感じです。

私は必ずQwerty英字けん盤を覚えなければなりませんか?

 ……日に数文字打つかどうか、というレベルならば、

  • ひらがなで読みを打って「変換」する。
  • 英字は目視検索で探す。

のどちらかで大丈夫だと思うよ。


 ちなみに、私の中学校時代は後者の方法をとっていました。

 今でこそ、けん盤名を打ったりロマかな変換テーブルを書いたりするときに「英字」を書くことはあるけど、ワープロを使っていた時代には英字を打つ機械自体がほとんどなかったし、Windows時代になって今時こうやってBlogを書いていてもほとんど使わないですし。

 #まさかDOS時代の呪縛がここまで続くとは思っていませんでしたけど^^;。


 そうそう、新しいWindowsVistaでは、「エクスプローラ」のパス欄が変わります。

 今までの

C:\Documents and Settings\oyaq\スタート メニュー

などという円記号区切りのパスはそのまま表示されず、

C: > Documents and Settings > oyaq > スタート メニュー

という感じの表記に変わります(で、名前をクリックすれば直接そのパスへとChangeDirectoryできる……というインターフェースになる)。

 パス欄の右端にある「▼」プルダウンヒストリを開けば従来のパス記法が出現します(もちろん、従来のパスをこの欄にコピペすることもできます)が、従来のパス記法を隠蔽してしまおうという方針はハッキリと見て取れるのが興味深いところで。


 MS-IME/JPにも、MS-Pinyin-IMEの「Double-Pinyin」的な入力方法がサポートされれば、もう少しローマ字綴りに束縛されない方向に行くと面白いんだけどなー……と、ただそれだけの話で。

2006年07月03日 月曜日 ぐるぐるるーぷする。

時の流れを忘れさせる時計 (2006-06-28)

http://pya.cc/pyaimg/pimg.php?imgid=29546

 延々視聴していると妙に記憶に残ってしまう^^;とても困ったさんなFlash時計

 #いつも思うんだけど、著作権は大丈夫なのかしら……。

Wikipedia:検証可能性関連。

(未来:メモ。@2006年07月07日 金曜日)

 うわーやばいなぁ、この方針があると「全面改訂もしくは削除しなければならない記事」が山の様に出てくるのですが……どうしよう。


 とりあえずリストアップしますので、参考文献の提示と全面書き換えが可能かどうか・削除依頼に出すべきかどうかご意見をお伺いしたく思います。

 コメントの基準は、良否それぞれ次の基準にのみ従っています。

Wikipedia:検証可能性」に合致する「ピアレビュー(査読)を経た情報」もしくは「広く信頼されている発行元を経由し公開された情報(ソフトウェアであればVector窓の杜あたりが該当する?)」のみを基にし、その他の記述存在しない記事かどうか

 以下、リスト

(※以下、「キー配列 」からリンクされているページを順にチェック)

    • タイプライター (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • テレタイプ端末 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • コンピュータ (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • キーボード (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • アルファベット (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 仮名 (文字) (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 英字 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • QWERTY配列 (書かれた「批判」と「再反論」と「諸説」は全て「文献に書かれている」ことなのか?)
    • ドイツ語 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • チェコ語 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • フランス語 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • JIS配列 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 中国語←きちんと参考文献がある。とりあえず取り消し線で例示
    • 漢字 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 繁体字 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 倉頡輸入法 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 朝鮮語 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • ハングル (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 親指シフト (ノートページで「検証可能性」についてポスト済み)
    • ファンクションキー (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • Dvorak配列 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • American Standard Code for Information Interchange (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 文字コード (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 飛鳥配列 (削除依頼に提出済み)
    • 月配列 (参考文献……ないですよね……うーん。)
    • 姫踊子草かな配列 (参考文献……ないですよね……うーん。)
    • かな入力 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • JIS配列 (「CEC仕様教育パソコン教育キーボード」について文献提示が必要/「シフト方式」「特徴」はいらない気がしてきた……)
    • 中指ニコラ (※問い合わせ中)
    • 配列 (※問い合わせ中)
    • 子音 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 母音 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • ローマ字 (そもそも参考文献が示されていない=文献に依る記述とすることができない)
    • 英語←きちんと参考文献がある。とりあえず取り消し線で例示
    • AZIK (参考文献……ないですよね……うーん。情報処理学会論文あり。無問題)
    • DvorakJP (参考文献……ないですよね……うーん。Linux Conferenceのライトニングトークで使用感が披露されたらしいのですが、肝心のページが404 Not Found になっていますorz。)
    • ACT_(キー配列) (「まだ」文献を頼りにしてはいない……が、2003年3月の情報処理学会全国大会で発表していて、発表原稿の別刷りを請求可能とのこと。つまり、それをよりどころにした文に限れば掲載可)
    • チーズタイピング (参考文献……ないですよね……うーん。)
    • ローナ (参考文献……ないですよね……うーん。)
    • Km式ローマ字配列 (参考文献……ないですよね……うーん。)
    • SKY配列 (主配列情報処理学会論文誌から……これを参考に執筆すれば大丈夫。亜種配列のうち文献を例示できないものはコメントアウトが必要)
    • チョイ (参考文献はあるのだろうか?チョイ入力の本があれば大丈夫だと思うけど……)
    • タッチ16 (参考文献はあるのだろうか?論文の掲示を希望)
    • 和ならべ (参考文献……ないですよね……うーん。)
    • 漢字直接入力 (参考文献はあるのだろうか?論文の掲示を希望)
    • ポケベル打ち (参考文献はあるのだろうか?論文の掲示を希望)
    • Linux (参考文献はあるのだろうか?)
    • X Window System (参考文献はあるのだろうか?)
    • Macintosh (参考文献はあるのだろうか?)
    • かな漢字変換 (参考文献はあるのだろうか?)
    • スキャンコード (参考文献はあるのだろうか?)
    • ローマ字かな変換 (参考文献はあるのだろうか?)
    • ローマ字入力 (参考文献はあるのだろうか?)
    • かな入力 (参考文献はあるのだろうか?)

 日本語入力に関する事情を知らない人から指摘されて「グダグダな状態で削除される」などというみっともない真似は絶対に避けたいので、できるところから順に・片っ端から整理して行こうと考えています。

 で、キー配列関連については「情報処理学会論文誌あたりに載ったものから順に」逐一復帰させていきたいと考えています。

 #というか、情報処理学会に入会するべきかどうかでかなり悩んでみたり……いや、論文を書く能力はなしい、力技で査読を通過できるわけでもないとは思っていますがorz


とりあえず。

 (別刷りを入手できれば、という条件付ではありますが)「ACT_(キー配列)」の再構築を試みてみる予定です。

2006年7月3日5:50:07時点での現状

 「風・花」作者さんに投じたはずのメールは帰ってきていません……って、真夜中の3時に投函した案件が2時間で戻ってくるなんてありえないですし。

 「中指ニコラ」作者さんに投じたはずのメールは「550 User unknown」で戻ってきましたorz

 「ACT_(キー配列)」作者さん(actbemuさん)に、別刷りについてのメールを書き送信しました。

秋月かな配列改4案4・W-ZERO3の変則キーに対応、カナ並びはシンプルなままで。

 W-ZERO3では中段と下段が一つずつ右にずれています……要は「(濁点シフトの)Lが最右端にある」のですが、これで「LY」とか「LU」を打つと、容易に指が死ねるという致命的欠陥がありました。

 で、それをカイゼンするには頻度の低い「小シフト(L)」と「濁音シフト(J)」を入れ替えるのが手っ取り早いので(いいのかそれで)、それをやってみることにしました。

 この頻度表を元に、少しばかり入れ替えてみました。

左は母音を「えおあいう」で統一。
右は母音を「おあいうえ」で統一。

無シフト面
けこかきく おあいうえ
てとたちつ わ゛★小
ねのなにぬ んっ

★シフト面
れろらりる そさしすせ
めもまみむ ×よやゆ
へほはひふ をー

゛シフト面
げごがぎぐ ぞざじずぜ
でどだぢづ
べぼばびぶ

小シフト面
××××× ぉぁぃぅぇ
××××っ ×ょゃゅ
ぺぽぱぴぷ

(※小シフト面に「ッ」を追加。)

 暗いところでも使えるようにするとなると、シール対応のみでの目視検索には問題がありすぎるので、そのあたりに多少考慮してみました。

 「きくちつ」が全て左手人差し指に集まっていたりする点は微妙ですが……他に良い折り返し方法を思いつかなかったもので。


で、早速姫踊子草の定義を書いてみた。

visible=1←この行は常に先頭に置き、かつ削除しないでください。
' 
' 
' 配列名:秋月かな配列改4案4.hmo_kana
' シフト方式:右手ホーム段キーによるプレシフト
' 参照先:http://d.hatena.ne.jp/maple_magician/20060703/1151852429
' 
' 変換有責者:かえで(yfi) yfi@eurus.dti.ne.jp
' 
' 
' 
StrokeMode=1
TypeModeDefault=14
' 
' 
' 無シフト面
' けこかきく おあいうえ
' てとたちつ わ小★゛
' ねのなにぬ んっ、。
=
qwertyuiop	け$こ$か$き$く$お$あ$い$う$え
asdfgh	て$と$た$ち$つ$わ
zxcvbnm,.	ね$の$な$に$ぬ$ん$っ$、$。
' 
' ★シフト面
' れろらりる そさしすせ
' めもまみむ ×よやゆ
' へほはひふ をー
=k
qwertyuiop	れ$ろ$ら$り$る$そ$さ$し$す$せ
asdfgjkl	め$も$ま$み$む$よ$や$ゆ
zxcvbnm	へ$ほ$は$ひ$ふ$を$ー
' 
' ゛シフト面
' げごがぎぐ ぞざじずぜ
' でどだぢづ
' べぼばびぶ
=j
qwertyuiop	げ$ご$が$ぎ$ぐ$ぞ$ざ$じ$ず$ぜ
asdfg	で$ど$だ$ぢ$づ
zxcvb	べ$ぼ$ば$び$ぶ
' 
' 小シフト面
' ××××× ぉぁぃぅぇ
' ××××っ ×ょゃゅ
' ぺぽぱぴぷ
' (※小シフト面に「ッ」を追加。)

' 
=l
yuiop	ぉ$ぁ$ぃ$ぅ$ぇ
gjkl	っ$ょ$ゃ$ゅ
zxcvb	ぺ$ぽ$ぱ$ぴ$ぷ


2006年8月20日15:53:51追記

 W-ZERO3で使える改4案4の定義を公開し忘れていたので、これは本日公開しました。

 ファイルをミニSDカードのルートフォルダに解凍すると、ルートフォルダ上には「_key」で始まるフォルダが多数出現します。

 このミニSDカードをW-ZERO3に刺してからTascalRegEditなどのレジストリエディタを起動し、「AKIDUK44」レジストリをW-ZERO3に読み込ませます。

 最後にリセットボタンを押して再起動してください。

 ローマ字入力のレジストリはJIS X 4063に近い定義として「LX4063」(LはXと見なす)と「JISX4063」(LはRと見なす)を用意してありますので、どちらかを同じ手順で読ませれば復帰できます。

 MS-IMEオリジナルの定義は同梱できないので、完全復帰をする必要がある場合は予めレジストリの[HKEY_CURRENT_USER\Software\Microsoft\IMEJP\3.1\RomaDef\MS-IME]

をバックアップしておく必要があります。

 簡易練習用のテキストを追加しました。PDFのp.14にあります。

2006年07月02日 日曜日 めいりおはぐだぐだ。

メモ。

 メイリオ自体はただのごくごく一般的なTrueTypeフォント。WindowsX(以下略

 #そういえば、なぜWindowsXP向けには提供しないことになったのだろうか……

 ところで、ひらがなの「め」が妙に重心が低くデザインされているのはなぜなのでしょうか。「めぼしい」とか「めろめろ」ならまだしも「だめだめ」とか書くと本当にダメダメに見えてしまいます……orz

 #というか、「た・だ」が大きすぎるのか。

 「おえかき」のベースラインが他より高かったり、「ごてごて」が妙にぶれていたり、妙に腰高な「と」に濁点が付いた「ど」のデザインが「どうにもいけ好かない」んですよね……フォント中に「同じ高さで引かれている線」があって、コレが原因なのかも。WindowsCleartype処理でキレイに出やすい線高を優先したらしいものの、並べてみると妙にばらついて見えるのは気がかり。

 #逆に言うと、「WindowsCleartype処理できれいに見えるように作成したフォントメイリオ」ってことなのかも。

ATOK.com 日本語ドリル

 Kouyさんのところでやっていらした「日本語ドリル」、試しにやってみました。

 点数は71点で「仮名遣いが弱点」、答えあわせの結果は「○○×○○ ○○○×× ○○○○○ ×○○○○」でした。

 でもなぁ……問い9は他例示表記で間違うなんてありえないし、問い10なんてもっとありえない。意地悪な問題だなぁ……orz

なぜ遺伝的アルゴリズムは「遠くのキー」を好むのか。

 ketttさんの記事より。

 遺伝的アルゴリズム手法を用いる場合であっても、ほかの手法と同じく「サンプルによって評価結果が異なってくる」という話題です。

 遠いキーを積極的に採用しようとする理由は……案外単純に、「近くのキーを2打鍵するよりも、遠くのキーを1打鍵するほうが累積打鍵時間は短く済むから」なのかも。


 新JISかなでの「シフトVS非シフト打鍵時間比」は文献によれば1.4(カーブの先は最終的に1.6近傍になると思う)なので、シフトキー打鍵を含む「2打鍵確定」な文字については、実際の打鍵時間よりも短めに見積もる(機械的に2/3圧縮する)などすれば、遠くのアンシフト面キーが高評価となってしまう現象を回避できるかもしれません。

 もちろんコレは「打鍵間隔を均一にしてダダダダダッと打鍵する」人にとってはまったく有効ではない考え方なのですが、現実的な打鍵負担を考えると、「シフト→文字」を2打鍵分の時間として加重するのはちょっと重すぎるのではないかと感じています。


 普通は「もっとも負担の重いキー入力(=シフト打鍵)」によって入力速度が制限されがちなので、結局「アンシフト側は余裕を持って入力・シフト側はせわしなく入力」として入力時間は平均化されてしまうような気がします。

 うーん……身近な例でいくと「きょう」と打鍵する場合にQwertyローマ字で「KYOU」と打鍵する例を思い浮かべてみてください。一つ一つのキーを独立して打っていく(打鍵測定結果のトレースと同じ)のではなくて、「Kを打って、その余力でYを一緒に打つ」とか、「手をYに上げたついでにOを打ちつつ掌を支えて、さらについでにUを打つ」とか、そういうシーンが多々繰り返されているはずです。

 遺伝的アルゴリズムの手法そのものにはおそらく問題がなくて、「キーの負担をどう定義するか」という指針の問題かな……と感じています。


 新JISではシフト側を(当初もくろみどおり)1.2倍あたりで設計していたはずですが、実際に新JISを制定してから打鍵テストを繰り返して「結局1.4倍近くになってしまった(しかもシフト・アンシフトカーブにはまだ少し上昇傾向が残っていた)」という事情があることからして、

シフトキー+シフト側文字キーの打鍵時間は補正(2/3とか)してから積算しても良いのでは?

と、とりあえずそういう提案をしてみたいのです(どちらにせよ、測定値をそのまま積算した場合の「約2倍」よりは短いわけですから)。

 その結果として打鍵範囲が狭くなるかどうかはまた別の話(たぶん、少々狭く収まるはず)ですが、「恣意的にやって狭くしました」では飛鳥の様に説明に難儀するのと対照的に、「実験結果を元に補正したら、結果として打鍵範囲が狭くなりました」であれば検証もしやすく、その方がすっきりとするのではないかな……と。


 #今日http://www.ipsj.or.jp/08editt/journal/shippitsu/ronbun-j.pdf を読んで頭が痛くなったばかりなので^^;、視点がずれているかもしれません……その場合はご容赦願います。

タッチタイプ練習教材には「音声」が重要。

(参考: http://homepage3.nifty.com/keyboard/index.htm )

 文字を追いかけるのがとても苦手な私としては、十分に納得できる内容だったり。

 #タッチタイプソフトでも、大抵文字の読み取りに時間が掛かりすぎることがネックになっていますorz


 とはいえ、音声教材ですか……俺のダミ声で「かえで式」を喋っても効果が無いだろうし^^;、果たしてどうすればいいのやら。


 ……って、こんなこと書いてる場合じゃなかった、秋月かなを何とかせねば。

秋月かな配列改4案3・かなの並びをシンプルに。

 始めに……清濁ごったまぜでの日記内かな出現頻度、但し「濁点シフト・半濁点+小文字シフト」キーそのものは集計せず。

清濁合計

24273 い

23064 か

21776 し

21608 て

18888 と

18778 う

17391 ん

15548 た

14923 つ

12950 は

11359 な

11349 す

10702 の

10417 き

9626 に

9422 よ

8709 、

8664 く

8147 こ

8055 ま

7242 る

7192 も

6543 。

6262 れ

5847 り

5576 ー

5556 お

5412 け

5264 あ

5049 ゆ

4995 を

4872 ひ

4781 ら

4679 さ

4366 ふ

3740 「

3691 」

3644 そ

3506 せ

3396 ち

3224 や

3026 ほ

2984 え

2920 …

2723 め

2683 み

2508 わ

2099 ろ

2089 へ

1166 ね

1107 む

808

311 !

243 ?

95 ぬ

37 )

37 (

 この頻度表を元に、少しばかり入れ替えてみました。

左は母音を「えおあいう」で統一。
右は母音を「おあいうえ」で統一。

無シフト面
けこかきく おあいうえ
てとたちつ わ小★゛
ねのなにぬ んっ

★シフト面
れろらりる そさしすせ
めもまみむ ×よやゆ
へほはひふ をー

゛シフト面
げごがぎぐ ぞざじずぜ
でどだぢづ
べぼばびぶ

小シフト面
××××× ぉぁぃぅぇ
××××× ×ょゃゅ
ぺぽぱぴぷ

 暗いところでも使えるようにするとなると、シール対応のみでの目視検索には問題がありすぎるので、そのあたりに多少考慮してみました。

 「きくちつ」が全て左手人差し指に集まっていたりする点は微妙ですが……他に良い折り返し方法を思いつかなかったもので。


で、早速姫踊子草の定義を書いてみた。

visible=1←この行は常に先頭に置き、かつ削除しないでください。

'

'

' 配列名:秋月かな配列改4案3.hmo_kana

' シフト方式:右手ホーム段キーによるプレシフト

' 参照先:http://d.hatena.ne.jp/maple_magician/20060702/1151852429

'

' 変換有責者:かえで(yfi) yfi@eurus.dti.ne.jp

'

'

'

StrokeMode=1

TypeModeDefault=14

'

'

' 無シフト

' けこかきく おあいうえ

' てとたちつ わ小★゛

' ねのなにぬ んっ、。

=

qwertyuiop け$こ$か$き$く$お$あ$い$う$え

asdfgh て$と$た$ち$つ$わ

zxcvbnm,. ね$の$な$に$ぬ$ん$っ$、$。

'

' ★シフト

' れろらりる そさしすせ

' めもまみむ ×よやゆ

' へほはひふ をー

=k

qwertyuiop れ$ろ$ら$り$る$そ$さ$し$す$せ

asdfgjkl め$も$ま$み$む$よ$や$ゆ

zxcvbnm へ$ほ$は$ひ$ふ$を$ー

'

' ゛シフト

' げごがぎぐ ぞざじずぜ

' でどだぢづ

' べぼばびぶ

=l

qwertyuiop げ$ご$が$ぎ$ぐ$ぞ$ざ$じ$ず$ぜ

asdfg で$ど$だ$ぢ$づ

zxcvb べ$ぼ$ば$び$ぶ

'

' 小シフト

' ××××× ぉぁぃぅぇ

' ××××× ×ょゃゅ

' ぺぽぱぴぷ

'

'

=j

yuiop ぉ$ぁ$ぃ$ぅ$ぇ

jkl ょ$ゃ$ゅ

zxcvb ぺ$ぽ$ぱ$ぴ$ぷ


 今は実際にこの定義で打っていますが、さすがに変なシフト操作が入ったりして辛いです……「ですが/ますが」が【lakole/kdkole】だったり、「そうする」が【kyokokt】だったりして、なんか妙なんですよね……。

2006年07月01日 土曜日 びすたんとおやゆび。

メモ。

 何げに「Anthy 月配列」という検索ワードをたまに見かける。

 満月版と帝月版は定義出来るとして……幽月版のポストスペースが行けるかどうかは未チェック。

 手作業でも定義出来るけど、ファイルで提供されているほうが楽だよね……


 そういえば、VistaBeta2ではインストール中に「戻る」ボタンがないシーンが多いように思うけど……アレはなぜだろう。

 それと、選択するべきボタンが、最下部ボタンではなく中央部点線で枠が示される(RC1でははボタンインターフェースで表現される?)ものがあるけど、押すべきボタンの位置は「大体同じところに表示」しないと、使いづらくてしょうがないんですよね……一部のWindowsインストーラにも似たような「コンピュータが描かれたボタン」とかがあるけど、これは悪癖としか言いようがない気も。統一すればもっと解りやすくなるはずなのに。


 みのりさんの漢直動画が鈴見咲さんの記事経由でシャドールームに掲載されている。


 メイリオ(Meiryo)、当たり前だけど半濁点が区別しづらすぎる……。コレはさすがにダメダメなので、1件目のポストかな……って、個人的趣味を押し付けていいのかどうか^^;

Wikipedia:検証可能性が本格運用を開始。

 キー配列関連については、いくつかWikipediaから除去しなくてはならないときが来るかもしれません……予めご承知おきいただきたく。

 とりあえず、「飛鳥配列 - Wikipedia」については「検証可能性がない」としてreject依頼してきます(「キー配列」に書いておくことも同じくだめなのかなぁ……そのあたりも含めて聞いてきます)。

Windows Vista Beta 2での動作を検証中。

 ……と、その前に。

 「Alt+かな」問題は、誤操作に関するもののみ見事に解決されている。

 Alt+かなを押すと、【「○○入力」に変更しようとしています。変更しますか?】というダイアログが。

 翻って、IMEツールバーの「KANA」表記はさらに見づらくなっているんだよなー。


IMEもしくはツール単独での動作について。

  • 「風」……鈴見咲さんによる確認済み。
  • 漢直Win」……検証方法が不明なので、デフォルトのTコード設定で「QWERUIOP」の4キーをデタラメに叩き続けてみたが、特に問題なく文字入力できる模様(部首合成についてはロジック不明のためテストせず、でも合成そのものはできているっぽい)。
  • 「姫踊子草」……インストールできない。

MS-IME2007経由でOpenOffice.org上の文字入力を行ってみた場合。

  • 「やまぶき」……かなロックモードで、右親指・左親指・小指シフト共に正しく動作する。
  • 親指ひゅんQ」……かなロックモードで、右親指・左親指・小指シフト(同時打鍵ではなく普通シフトなの?)共に正しく動作する。
  • 「もや指」……JISかなしか出ず、動作しない。
  • 「菱」……かなロックモードで、SandSな新JIS(JISX6004)が正しく動作する。
  • 「繭姫(majuhime13007_072.exe)」……打って出た文字が全て上書きされてしまい、1字しか入力できない。
    • ノートパッド(Notepad.exe)で試すと、そもそもキー入れ替えが効かない……と思って気づいた。「設定窓口/繭姫」の「IME」タブで、「次の漢字変換では常にQWERTY並びのまま出力する」に書かれている文字を切り取って(この枠は空欄にする)、切り取った文字列を「次の漢字変換ではSCS_SETSTRが利用可能であっても使わない」に貼り付ければ、【一応】使えるのか。
    • ひとまず、設定変更(文字直接投入を使わない)で乗り切ることは可能……ただし、出せない文字が出るので、そのあたりはちょっと微妙かも。

ATOK2005経由でOpenOffice.org上の文字入力を行ってみた場合。

  • 「やまぶき」……かなロックモードで、右親指・左親指・小指シフト共に正しく動作する。
  • 親指ひゅんQ」……JISかなしか出ず、動作しない。
  • 「もや指」……JISかなしか出ず、動作しない。
  • 「菱」……かなロックモードで、SandSな新JIS(JISX6004)が正しく動作する。
  • 「繭姫(majuhime13007_072.exe)」……もともと「次の漢字変換ではSCS_SETSTRが利用可能であっても使わない」(=文字直接投入はできない)設計なので、こちらはIMEタブを元に戻して使えばOK。