2019年06月04日

想像力

どっちの「豆おかき」がおいしそう?

三春と豆おかき

もっと細長いのがあればよかったんですが、マツキヨで見付けた「豆おかき」が今まで見てきた中で最も似ていました!

Enjoy The Difference !

似てるけど違う。違うけど似てる。ネコの足に求められる機能や目的と、お煎餅に求められるそれは、当然ながら異なります。そもそもの前提が異なれば、結論が違ってくるのは当たり前の話。「あちらを立てればこちらが立たず」なのが世の常ですから、何を選んで何を捨てるかの判断もまた、人それぞれ異なります。

前提やら嗜好やら判断やらの違いが積み重なって、「それ」は現在の姿かたちになっています。違いが生じた原因を考えたり、似ている理由に思いを馳せたりして想像力を働かせることは、私にとっては楽しい作業です。違っているからこそ面白いし、多様性は豊かさの証、創造の源だと信じます。

巷に蔓延する「〜なのは明白なのに、なぜ採用しないのか理解できない」といった、想像力の欠片も感じられない論法のオンパレードに、いささか辟易してきました。真正面から反論するのは、ただただ無駄としか思えず。

ネコの足とお煎餅、あなたに必要なのはどちらでしょうか。見た目は似てるかもしれませんが全く別物ですから、くれぐれもお間違えなきように。迂闊に手を出すと咬みつかれますよ(笑)。

posted by 141F at 02:25| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年09月15日

親指を止めるな!

薙刀配列との分岐点がまた一つ、見えてきました。大岡さんの先日の稿に言及します。

【薙刀式】人はどこで配列検討を考えるのか
大岡俊彦の作品置き場
2018-09-12

分かりやすさを優先して、長めに引用します。

で、諸々省略して現在に至る。
そもそもの動機が小指が嫌だったので、
BSとカーソルとエンターとシフトが真ん中にあるものを探したけど、
なかったのでカタナ式を作った。
まずこの最初の部分は、
今でも薙刀式に受け継がれている。

ところが他の沢山の配列を見ても、
そういう発想の奴がないんだよね。
自作キーボードでも同様で、
カーソルが右下なのがとても多い。
真ん中にした方が楽なのになあ。
ホームポジション崩れないし。

僕にとって文字を打つことは、
ひらがなを打ち、変換し、文節決めて、漢字を決める、
までを指すのだが、
どうも世の中の配列さんたちは、
ひらがなを打つまでしか最適化しようとしてない印象を受ける。

予想だけれど、
みんな何十万字を書くことが目的ではないのではないだろうか。

強調は引用者が行いました。

私が「文字を打つ」時は、

  1. (親指シフトで)ひらがなを打ち、
  2. (親指で)変換し、
  3. (親指で)文節決めて、
  4. (親指で)漢字を決める

と、すべての工程に親指が関わっていて、ホームポジションは崩れません。PC98 に ASkeyboard を繋いでいた時代から、遅くとも1992年からずっとこの親指中心のスタイルで入力⇒変換⇒確定しているので、変換から確定までの工程にはストレスを感じていません。つまり、私にはここを改善する動機がありません。文節長を変える時はカーソルキーを使いますが、滅多に起きることではないので、「右下のカーソルキーで例外的に対応する」で十分と判断しています。

そしてこの2番から4番までの項目は IME キー設定のカスタマイズで実現していて、蜂蜜小梅配列では規定外=一切関知しません。

そんな人間=私=が作ったからこそ、蜂蜜小梅配列は「ひらがなを打つことを最適化する」ことを主眼に据えて、人差し指にもカナと記号を吟味して配置しています。素早く動かせる人差し指や強い中指に機能キーを配置するなんて、キーを無駄遣いしているとしか思えません。ついでに言えば、親指が担うキーがスペースキー一つしかない英語キーボードは、日本語の入力装置に値しないというのが率直な感想です。

若干の補足@2018-09-15
  1. 「全確定」が割り当てられている[Enter]キーが遠く離れているのが嫌だから、[Enter]キーが近い英語キーボードを使う。
  2. 「全確定」が割り当てられている[Enter]キーを小指で押すのが嫌だから、[Enter]キーを中指や人差し指に複写する。
  3. 「全確定」を[Enter]キーで行うのが面倒くさいから、「全確定」を親指キーに割り当てて確定する。

私は「Enter キーを楽に押したい」のではなく、「確定という作業を楽に行いたい」だけなので、3番を選びます。同様に、「カーソルキーをホームポジションを崩さずに打ちたい」のではなく、「注目文節を右の文節に移動したい」だけなので、「注目文節右」を親指キーに割り当てています。

IMEのキー設定を「VJE」にする

これだけで、カナ入力後のキー設定が

[変換]キー
変換/次候補
[スペース]キー
変換/次候補
[無変換]キー
全確定

に変わります。たしか OASYS も、[変換]キーで変換/次候補して、[無変換]キーで確定するのは同じだったはず。親指で確定するのは楽チンでやめられません。

三人合わせて

  • 親指キーの嵩上げ
  • IME の設定変更
  • カナ入力のリマップ

この3者がそろってはじめて、蜂蜜小梅配列と呼ぶべきなのかもしれませんね。うーむ。

関連記事

スペースキーを左親指キーにしている人。
2012-02-08
「親指シフト系新配列の作者」という立場。
2009-06-16
親指キーの履歴。
2007-07-22
キーボードを新調した。
2006-02-28
どの指で変換を確定するか
2006-02-15
やっぱり松が好きっ! 楽しいワープロ便利帖 松Ver.5
酒井 昭伸/K3ユーザーズグループ編
技術評論社
1991年12月
ラベル:蜂蜜小梅配列
posted by 141F at 02:27| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年08月23日

蜂蜜小梅配列が左右交互打鍵を優先した理由

蜂蜜小梅配列が左右交互打鍵を優先した理由について、あちこち断片的に書き散らかしてきた覚えしかないので、今さらながらまとめてみます。

その理由を端的に表すならば、同手シフトを使うから交互打鍵を優先した、となります。

シフト方式に「都度シフトの親指2シフト」を選んだ日本語配列の必然として、バタバタした打鍵になってしまう「同じ手の同手シフトの連続」は何としても避けたい課題です。この宿命に真っ向から取り組んで交互打鍵率と無シフト率を最大化し、「同じ手の同手シフトの連続」を Nicola 配列比で 1/5 に抑えたのが、他ならぬ Tron 配列でした。しかし、裏返しの代償も少なくなく、物理配列として専用キーボードが必須となり、論理配列がいささかトリッキーになってしまったのは、返す返すも残念でした。

左右比率=1:1でカナをランダムに並べた日本語配列の交互打鍵率は、限りなく50%に近付くと思われます。そんな状態から始まった小梅配列の作成は、絡まりまくる運指に辟易して、交互打鍵率を高めることを是と定めます。こうしたカオスから生まれたのが、「正式版」と呼んだ小梅配列 1.2x 版でした。

1.3.x 版以降の小梅配列⇒蜂蜜小梅配列では、飛鳥配列と新JIS配列に倣って、利き手ではない左手の打鍵が連続することを忌避しました。Nicola 配列や飛鳥カナ配列との比較で、文末にこそ日本語配列の個性が強烈に発揮されていることを確認しました。

また、ハイブリッド同時打鍵を採用した蜂蜜小梅配列では、同手シフトが絡むアルペジオ打鍵が左右交互打鍵よりも遅いことを発見しました。何度も繰り返した「こうめはいれつ」の打鍵に、こんな症状が現れました。

「うめ」よりも「いれ」の打鍵が遅い。
同手シフトを含む交互打鍵[M][A左] よりも、同手シフトを含むアルペジオ打鍵(右手⇒右手) [K][J右]が遅い。

結果として、同手シフトを使う日本語配列では左右交互打鍵を優先した方が、速い/疲れない/間違えにくい入力につながります。同手シフトを少しでも減らしたくて、清音シフト、濁音シフト、反転シフトを一通り試して、結果として標準シフトに戻した、なんてこともやってましたね。

そして、蜂蜜小梅配列が同手シフトを許容する「都度シフトの親指2シフト」を採用したのは、多少遅くてもいいから分かりやすいルールにしたい、打ちやすい運指にしたいと判断したからに他なりません。

以上を踏まえて、久しぶりにクルマに例えた話をしましょうか。

蜂蜜小梅配列が目指したのは、高価だったり、高度な技能が必要だったり、何かと儀式が求められる高性能スポーツカーではありません。手頃な価格で買えて、吊るしのままで普段遣いができて、反復練習不要で、街乗りしているだけでも楽しい、デミオ・ディーゼルやスイフト・スポーツ、ポロGTIみたいな、FFコンパクトスポーツです。

クローズドコースでタイムアタックしたり、耐久レースで長編を執筆したりするのは、配列アスリート専用の日本語配列にお任せします。蜂蜜小梅配列はベースが生活志向のFF車なので、絶対的なスピードやタイムでは敵いませんし、競技に出場するとしても市販車無改造クラスへのエントリーとなります(笑)。もちろん、FF車なりの速く走るための仕掛け=左右交互打鍵=は備えてあります。カーナビを標準装備しているので、知らない拗音で指が迷うこともありません。動力性能以外においても、環境性や安全性といった時代の要請に、できうる限り応えてきたつもりです。昭和の名車をありがたがるのは、旧車会の方々だけでよろしいかと存じます。

蜂蜜小梅配列はそんな、普通のキーボードで使えて日常生活に寄り添う、21世紀基準の親指シフトです。同手シフトを是としたことも、交互打鍵を優先したことも、すべてに理由があります。

関連記事

同時打鍵と打鍵速度
2012-05-31
同手シフトはどの指で発生しているのか
2012-05-01
右人差指の前後の打鍵を分解する。
2009-02-12
同じ手の同手シフトの連続。
2008-08-31
10万字サンプルで「文末」を紐解く。
2008-02-24
Re:小梅配列は「素直な配列」
2007-11-12
SD版は同手シフトがもっと少なかった。
2007-02-18
濁音シフトと清音シフト。
2007-02-18
ラベル:蜂蜜小梅配列
posted by 141F at 02:05| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年08月12日

【真逆の関係】蜂蜜小梅配列と薙刀配列(続)

ああ、そうでした。違うのは脳内発声でしたね。

私自身は脳内発声せずにキーボードで入力する感覚が理解できませんが、脳内発声の有無が【真逆の関係】を生み出したとしても、まったく不思議ではないと考えます。馬の背を降り分けた一滴一滴が、此方は大河となって太平洋へ流れ出で、彼方は滔々と日本海に注ぎ込む、みたいな。

ですから、「指がしゃべる」感覚に対する大岡さんの 2018-08-10 付の言及に、概ね異論ありません。

【親指シフト】指がしゃべる考、再び
大岡俊彦の作品置き場
2018-08-10

自宅でPCに相対する時は、下の画像からお分かりのように、私は音楽をずっと流して楽しんでいます。ブラウジングしたり、見ながら何かを考えるぐらいなら、どんな曲が流れていても気になりませんが、書く時だけ「日本語で歌う唄」はNGです。とにかく邪魔! こういうのも脳内発声があるが故の弊害ですかね。

机上のキーボード環境

そして、私が親指2シフトの蜂蜜小梅配列で入力している上の画像のキーボードと、下に引用する大岡さんが親指1シフトの薙刀配列で使っている改造しまくりのキーボードとの、「親指キー」の違いにご注目ください。

大岡俊彦の作品置き場 > 【キーボード】もはや半分自作キーボードか

親指キーを嵩上げしているのは同じでも、親指2シフトの蜂蜜小梅配列は滑らない素材の「点」を使うのに対して、親指1シフトの薙刀配列は滑らかな素材の「線」で嵩上げしています。親指を「親指のホームポジション」から動かさない親指2シフトと、親指を左右自在に動かす親指1シフトは、これも日本語配列として似て非なるものと言えそうです。

関連記事

【真逆の関係】蜂蜜小梅配列と薙刀配列
2018-08-11
posted by 141F at 02:56| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年08月11日

【真逆の関係】蜂蜜小梅配列と薙刀配列

薙刀配列が面白すぎる!

蜂蜜小梅配列の作成者=私=から見た薙刀配列の世界は何もかもがあべこべで、まるで「鏡の国の日本語配列」です。よくぞここまで、ことごとく正反対の日本語配列が生まれてきたものだと感心するしかありません。

現時点での最新版 V8(US対応バージョン)のポインタを記します。効能書きを改めてご一読ください。

【薙刀式最新】v8(US対応バージョン)
大岡俊彦の作品置き場
2018-07-05

蜂蜜小梅配列と薙刀配列はどこがどのように違っているのか、思いつく限りの相違点をリストアップしてみました。

蜂蜜小梅配列 比較項目 薙刀配列
カナ系
親指キー同時2シフト
+文字キー同時シフト
< 基本形 > カナ系
文字キー同時シフト
+親指キー同時1シフト
親指キー同時シフト(同手シフト) < 文字入力のシフト > 親指キー同時シフト(他手シフト)
親指キー同時シフト(他手シフト) < 濁音のシフト > 文字キー同時シフト(他手シフト)
文字キー同時シフト(他手シフト) < 半濁音のシフト > 文字キー同時シフト(他手シフト)
蜂蜜マトリックス(他手シフトのみ) < 拗音(外来音)の入力 > 対象カナ同時打鍵
※ 同手シフト・3キー同時打鍵あり
左右交互打鍵 < 優先したもの > アルペジオ打鍵
利き手ではない左手の打鍵の連続 < 排除したもの > 薬指・小指・小指伸の打鍵
[P][Y][B] < 嫌った物理キー > [T][Y][:][@][Q]
左手人差し指 < 最優先で保護したい指 > 左手薬指
素早さを活かしたカナ入力優先 < 人差し指の使い方 > 句読点、濁音、半濁音、カーソル等を配置
小指・無シフト < 句読点の配置 > 人差し指・シフト側
使わない < 連続シフト > 使う
普通のキーボードで使うことを想定 < キーボード > 専用キーボードを推奨
最小限の定義(ユーザに任せる) < 機能キー > 積極的に定義
ない < 入力速度・長文入力に対する
配列作者のこだわり >
あり
[空白]単独打鍵で確定
※ 蜂蜜小梅配列の規定外
< かな漢字変換後の確定操作 > [V]×[M]同時打鍵で[Enter]

基本形こそ親指キー同時シフトの「2シフト」と「1シフト」で近似しているものの、他の項目は「半濁音のシフト」が一致する以外はことごとく正反対になっています。彼我の差はいったいどこから生まれたのか、本当に不思議です。

仕事で使うか使わないかの違いが大きなファクターの一つではないかと疑っていますが、こればかりは仮説をどんなに積み上げても立証できない気がします。

理由をもう一つ掲げるとすれば、私の配列作りは兎にも角にも[P]キーを嫌ったことが発端でした。薙刀配列とは親指キー2シフト⇔親指キー1シフトとシフト方式が異なるので、嫌う物理キーも違ってきます。だから、成果物たる日本語配列も別物になる、と。これも鶏が先か卵が先か、という話かもしれませんが。

え? なになに? ローマ字入力から親指シフトにするか迷ってるって? ボーっと生きてんじゃねえよ!

posted by 141F at 00:47| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年05月02日

蜂蜜マトリックスを最初に覚えましょう

蜂蜜小梅配列のウェブサイトに、少しく加筆しました。

「ルールが複雑すぎて、とても覚えられる気がしない」と感じている、そこの貴方。まさか拗音 104 組を全部マスターするつもりじゃないでしょうね? そんなこと、やらなくていいんです。

蜂蜜マトリックスは 3行×5列、規則正しい15鍵です。連想記憶を武器として使いこなすために、この簡単なルールを最初に覚えてください。カナに手を出すのはその次でOK。ディスプレイ脇にカンペを貼るのもいいと思います。

蜂蜜マトリックスは3段×5列の格子フィルタ

カナを覚える時は、

  • 「L」キーを押したら「し」が入力される
  • 「し」を出すときは「L」キーを押す

といった物理キーを意識した、いわば補助輪付きの状態からスタートします。それがいつしか「し」のキーを押したら「し」が入力される、仮想キーを打鍵する意識に変わり、やがて無意識下の打鍵として指に固定されます。

蜂蜜マトリックスも同じです。[D]と[L]を同時打鍵したら「しょ」という物理キーを意識した動作から、「ょ」と「し」で「しょ」という感じでキーの仮想化が進み、指が「しょ」を覚えていきます。連想記憶を繰り返すうちに、運動記憶として定着していくのです。

同様に「ぎゃぎょぎゅ」や「ちゃちょちゅちぇ」等のわりと使う拗音も、「ゅ」と「ち」で「ちゅ」などと咄嗟に思い出しながら入力していくうちに、指にじわじわ染み込んでいきます。

滅多に使わない、あるいは使ったことがない【指が覚えていない拗音】でも、「ぁ」と「つ」で「つぁ」、「ぅ」と「と」で「とぅ」とその場で類推しながら打鍵できるので、指が止まったりしつつも、「ツァラトゥストラ」と入力できます。

この「咄嗟に思い出しながら」入力したり、「その場で類推しながら」打鍵できるところ、すなわち連想記憶を入力補助として最大限に活用するのが、「覚えやすい/忘れにくい/思い出しやすい」蜂蜜マトリックスのユニークな特長です。

たとえ指が「ぬぉ」を知らなくても何とかなる。あるいは、「し」がどのキーか知っていれば、「しゃしょしゅしぇしぃ」(と「じゃじょじゅじぇじぃ」)が連想できる。そして、自分が使う拗音だけが指に自動的に記憶されていく。それが蜂蜜マトリックスという仕掛けなのです。

まず初めに、蜂蜜マトリックスを指のコンシェルジュとする。そこから貴方の蜂蜜小梅配列が始まります。蜂蜜マトリックスは 3行×5列、規則正しい15鍵です。

2018-05-03 加筆訂正しました。

posted by 141F at 01:49| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年03月19日

同時打鍵の打鍵負担率を可視化する

私はこんな説明をしてきました。

さらに同時打鍵系が厄介なのは、たとえば Nicola では、実質打鍵数 28 キー分の負荷を、名目打鍵数の 17 ストロークで負担しなければならないこと。

実質打鍵数の計算は連続シフトを考慮していませんが、飛鳥カナ配列が名目打鍵数101,156ストロークを入力する時間で、実質打鍵数151,837キー分の押下負荷を担わなければならないことは、連続シフトの有無に関わらず同じです。

分かる人はこんな説明でも分かってくれるからいいとして、分からない人は何のことやらさっぱりだろうと、書いた当初からずっとモヤモヤしてきました。今さらですが、補足説明を試みます。可視化するターゲットは さっぽろでちーむにごうりゅうした。 をちょっと変えた、さっぽろでちーむにごうりゅうする。 の17字。

関連記事

利き手と左右別の打鍵頻度の関係を再考する
2014-11-10
「同時打鍵」は魔法の呪文ではない。
2011-02-12

札幌でチームに合流する。

まずは同時打鍵しない qwerty ローマ字入力から紐解きます。表の縦軸は strokes を単位とした時間を、横軸は keys を単位とした負担を表します。

qwerty ローマ字配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
s S 1
A 1
p P 1
P 1
O 1
r R 1
O 1
d D 1
E 1
t T 1
I 1
- 1
m M 1
U 1
n N 1
I 1
g G 1
O 1
U 1
r R 1
y Y 1
りゅ U 1
U 1
s S 1
U 1
r R 1
U 1
1
28 10 18 28
  • 実質打鍵数 28 keys / 名目打鍵数 28 strokes = 打鍵負担率 1.00
  • 実質打鍵数 28 keys / 入力文字数 17字 = 打鍵効率 1.65
  • 交互打鍵数 13 strokes / 名目打鍵数 28 strokes = 交互打鍵率 0.46

同時打鍵が発生しないので、28ストロークを打鍵する時間で28キーを負担しています。除した数値=打鍵負担率は 28/28=1 となります。

Nicola 配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
T 1
2
L 2
C 2
D 2
U 1
X 2
2
U 2
R 2
A 1
E 2
F 2
A 1
C 1
I 2
Q 1
17 5 11 6 6 28
  • 実質打鍵数 28 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.65
  • 実質打鍵数 28 keys / 入力文字数 17字 = 打鍵効率 1.65
  • 交互打鍵数 8 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.47

元祖親指シフトは、17ストロークを打鍵する時間で28キーを負担しています。打鍵負担率、打鍵効率とも同時打鍵系ではワースト。16:12で左手の打鍵が多く、左手側で6連打が発生しています。

新下駄配列
strokes 左手側 右手側 Keys
シフト 文字 文字 シフト
S L 2
G 1
S 2
V L 2
1
T 1
Q 1
V K 2
W 1
W K 2
J 1
りゅ Q O 2
J 1
Z 1
V 1
1
16 1 11 5 5 22
  • 実質打鍵数 22 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.38
  • 実質打鍵数 22 keys / 入力文字数 17字 = 打鍵効率 1.29
  • 交互打鍵数 3 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.19

打鍵負担率、打鍵効率ともベスト。12:10で左手側がやや多く、左手5連打が1回、左手4連打が1回発生しています。

蜂蜜小梅配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
F 2
N 1
D 2
V 1
E 2
2
H 1
H 2
O 1
A 2
M 1
りゅ W L 2
M 1
1
F 1
Q 1
16 3 6 10 4 23
  • 実質打鍵数 23 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.44
  • 実質打鍵数 23 keys / 入力文字数 17字 = 打鍵効率 1.35
  • 交互打鍵数 5 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.31

「ぽ」を[Z右]で入力しても、左:右=9:14で、左手3連打が1回発生することに変わりありません。打鍵効率は次点。

飛鳥かな配列 123
strokes 左手側 右手側 Keys
シフト 文字 文字 シフト
/ 1
M 1
P 1
2
2
X 1
W 1
N 2
C 1
@ 2
D 1
V 1
1
D 1
K 2
J 2
2
17 4 6 11 3 24
  • 実質打鍵数 24 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.41
  • 実質打鍵数 24 keys / 入力文字数 17字 = 打鍵効率 1.41
  • 交互打鍵数 8 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.47

打鍵負担率は次点。シフト側で[▼]と表した箇所では連続シフトが効いていますが、シフトキーを押しっぱなしにできても、実質打鍵数2の状態が続くのは変わらず、打鍵負担率を改善する効果はありません。左:右=10:14。

Tron 配列
strokes 左手側 右手側 Keys
シフト 文字 文字 シフト
V 1
/ 1
T 2
2
P 2
F 2
J 2
K 2
O 2
C 1
E 2
K 1
X 1
D 2
K 1
N 1
W 1
1
18 2 8 10 7 27
  • 実質打鍵数 27 keys / 名目打鍵数 18 strokes = 打鍵負担率 1.50
  • 実質打鍵数 27 keys / 入力文字数 17字 = 打鍵効率 1.59
  • 交互打鍵数 11 strokes / 名目打鍵数 18 strokes = 交互打鍵率 0.61

オリジナル Tron 配列は同時打鍵ではないらしいので、この文例も親指キー押しっぱなしで入力しようと思えばできるはず。ですが、右親指キー押しっぱなしで[.][P]の運指なんて、[P]嫌いの私には拷問としか思えません。左:右=10:17。

薙刀配列 v4
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
U 2
G 1
Z L 2
A 2
E J 2
G 2
1
R 2
D 2
V J 2
L 1
りゅ E 2
L 1
O 1
I 1
N 2
16 2 9 7 8 26
  • 実質打鍵数 26 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.63
  • 実質打鍵数 26 keys / 入力文字数 17字 = 打鍵効率 1.53
  • 交互打鍵数 3 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.19

最大3キー同時打鍵で親指1シフトという薙刀配列の、できたて v4 を採り上げます。 親指キー同時シフトは他手シフト、という前提で計算しています。叢雲配列に似てるのかと思いきやシフトの使い方が正反対で、無理やりに例えれば Tron + 下駄 + 蜂蜜小梅 1.4.2+00 という感じですかね。左:右=11:15で、 連続シフトが1回、 左手側で親指キーを含めた6連打が1回、3連打が1回発生しています。

これで十分だと思いますが、

もう一つ、「これで十分だと思いますが、」で打鍵負担率を可視化します。各配列が工夫を凝らした「これ」「おもい」「ますが、」の運指をお楽しみください。

qwerty ローマ字配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
k K 1
O 1
r R 1
E 1
d D 1
E 1
j J 1
じゅ U 1
U 1
b B 1
U 1
n N 1
N 1
d D 1
A 1
t T 1
O 1
O 1
m M 1
O 1
I 1
m M 1
A 1
s S 1
U 1
g G 1
A 1
1
28 12 16 28
  • 実質打鍵数 28 keys / 名目打鍵数 28 strokes = 打鍵負担率 1.00
  • 実質打鍵数 28 keys / 入力文字数 17字 = 打鍵効率 1.64
  • 交互打鍵数 10 strokes / 名目打鍵数 28 strokes = 交互打鍵率 0.36

左手側で4連打が発生しています。

Nicola 配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
R 1
T 2
D 2
S 2
D 2
A 1
V 2
1
E 2
J 1
J 2
G 2
L 1
O 2
C 1
W 2
@ 1
17 3 11 6 7 27
  • 実質打鍵数 27 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.59
  • 実質打鍵数 27 keys / 入力文字数 17字 = 打鍵効率 1.59
  • 交互打鍵数 7 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.41

左:右=14:11 でやはり左が多く、左手側で7連打が発生しています。

文字キーの運指だけ拾います。

これ
RT
ますが
OCW

くそみたいな運指も含めて qwerty ローマ字配列と五十歩百歩。溜め息しか出ません。

新下駄配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
I 1
D K 2
1
じゅ W O 2
J 1
/ 1
F 1
S M 2
S 1
D L 2
F K 2
K 1
X 1
Z 1
O 1
R 1
16 1 9 7 4 21
  • 実質打鍵数 21 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.31
  • 実質打鍵数 21 keys / 入力文字数 17字 = 打鍵効率 1.24
  • 交互打鍵数 4 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.25

実質打鍵数21はさすが。左:右=10:11でほぼ拮抗。左手側で5連打が発生しています。

蜂蜜小梅配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
A 1
J 2
D 2
じゅ X L 2
M 1
C 2
J 1
S 2
1
U 1
D 2
K 1
C 1
1
D 2
@ 1
16 2 7 9 5 23
  • 実質打鍵数 23 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.44
  • 実質打鍵数 23 keys / 入力文字数 17字 = 打鍵効率 1.35
  • 交互打鍵数 12 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.75

左:右=9:14。打鍵効率は次点。こういう平面図で俯瞰すると、蜂蜜小梅配列と Tron 配列は本当によく似ています。

飛鳥かな配列 123
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
L 2
E 2
2
Z 1
1
D 1
B 1
J 1
A 2
I 1
S 2
2
K 1
L 2
K 2
D 2
2
17 6 7 10 4 27
  • 実質打鍵数 27 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.59
  • 実質打鍵数 27 keys / 入力文字数 17字 = 打鍵効率 1.59
  • 交互打鍵数 12 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.71

左:右=13:14。連続シフトが5回発生しています。「が」が左手側に押しやられてしまったのは、やっぱり美しくない。

Tron 配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
E 1
P 1
F 2
L 2
D 2
K 1
G 2
1
A 2
S 1
H 2
G 1
J 1
Z 1
N 1
D 2
1
17 2 9 8 5 24
  • 実質打鍵数 24 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.41
  • 実質打鍵数 24 keys / 入力文字数 17字 = 打鍵効率 1.41
  • 交互打鍵数 15 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.88

左:右=11:13。打鍵負担率は次点。

薙刀配列 v4
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
V 1
S 1
E J 2
じゅ R J, 3
L 1
F 3 2
1
F N 2
D 1
M 2
K 2
K 1
F 2
O 1
F J 2
V 2
16 5 4 8 8 6 27 26
  • 実質打鍵数 27 26 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.69 1.63
  • 実質打鍵数 27 26 keys / 入力文字数 17字 = 打鍵効率 1.59 1.53
  • 交互打鍵数 3 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.19

左:右=13:14 12:14。打鍵負担率はワースト。左手4連打が1回、連続シフトが1回発生しています。

「ぶ」の[親F.]はまだしも、「じゅ」の[RJ,]って、とっさに打鍵できます?

親指同時シフトを省略した[F.]で「ぶ」が入力できるとご教授いただきました。数値を訂正しました。

まとめ

ワーストケースとベストケース、わずか2つの文例ですが、各配列の強烈な個性が見えてきますね。手前味噌にもなりますが、飛鳥、新下駄、蜂蜜小梅の3配列は、どんな局面でも安定した性能を発揮できているように思えます。

本稿では打鍵負担率という指標を新たに用いましたが、既出の同時打鍵率や無シフト率とほぼ同じものです。下記に違いを記しておきます。

打鍵負担率
実質打鍵数 / 名目打鍵数
同時打鍵率
実質打鍵数 / 名目打鍵数 − 1
無シフト率(実質打鍵数ベース)=単打率
1 − (実質打鍵数 / 名目打鍵数 − 1)

3キー以上の同時打鍵では計算式が異なります。

参考までに、10万字サンプルにおける同時打鍵率を再掲します。薙刀配列はまだ計算してません。


打鍵効率 (keys/字) 同時打鍵率
Nicola 配列 1.422 42.2%
Tron 2005-1011 1.251 25.1%
飛鳥カナ配列 1.501 50.1%
蜂蜜小梅配列(タイプ・アシスト利用なし) 1.317 35.1%
蜂蜜小梅配列(タイプ・アシスト利用あり) 1.303 33.6%
新下駄配列 1.262 29.5%
Qwertyローマ字配列 1.747 0.0%
最大3キーの同時打鍵って、どっかで見たことがある

そして薙刀配列は、今までの "俺様配列" とは異なる文脈・違う尺度で作られた日本語配列のように感じます。

薙刀配列が採用した「最大3キー同時打鍵の両手清濁拗同置」は、シフトの掛け方こそ異なりますが、蜂蜜小梅配列が生まれるきっかけとなったアイディア そのものです。しかし、言うは易く行うは難し。

蜂蜜マトリックスを捨てて当初の蜂蜜小梅配列に戻してくれと頼まれても、現在の私は即座に却下します。そもそもが物理キーではなく論理キーで日本語を入力しているのですから、拗音入力時だけ盤面をマトリックスに切り替えても、「し」と「ょ」の同時打鍵で「しょ」を入力する感覚は変わりません。だったら私は、指遣いが圧倒的に楽な蜂蜜マトリックスを選びます。

メリットの裏にはデメリットが必ずあります。叩き込んだ目の前の釘は、反対側に飛び出します。パーフェクトな人間なんて存在しないのと同様、パーフェクトな日本語配列もまた存在しません。譲れない性能と消し去りたい欠点の狭間に、工夫と妥協の結果として、蜂蜜小梅配列もまたあります。

蜂蜜小梅配列が叩き込んだ目の前の釘は、反対側に飛び出て薙刀配列になった。そんな気さえしてくるのは、春霞のせいでしょうか。

posted by 141F at 01:09| Comment(2) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年02月22日

脳内発声あり

親指シフトはカナ入力じゃないのかよ。ってなツッコミはさておき。

親指シフトです。既述の通り、脳内発声バリバリです。打鍵速度は脳内発声に律せられます。高校の数 III で理系人生に終止符を打ちましたが何か。

脳内発声なしで思考するってどういう状態? と、しばらく途方に暮れましたが、例えば出掛ける前に道順や乗り換えを探っている時は、路線図や断片的な風景なんかを思い浮かべていて、言葉には頼っていません。(論理的に)思考している時も、ちょっと歯切れが悪くなりますが、脳内発声していないように思います。

言葉として出力する時は、例外なく「脳内発声あり」です。qwerty ローマ字だと「かんんにんんぐ」みたいに脳内発声しまくりで、頭が疲れます。

脳内発声の有無によって、適した日本語配列が異なるという論旨は理解できますが、その分け方が違うように思えます。直感的に。親指シフトはカナ入力じゃないのかよ、と。

ラベル:親指シフト
posted by 141F at 01:59| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年02月18日

小梅配列+蜂蜜マトリックス≠蜂蜜小梅配列

一滴から始まった違和感がいつしか拭い切れなくなってきたので、冬季オリンピックが始まったタイミングで決着をつけます。蜂蜜小梅配列と小梅配列の関係性を再確認します。

一般的には「親指シフトの小梅配列」と、「拗音拡張を追加した蜂蜜小梅配列」てな感じで認識されているものと思われますが、それだけではないんです。あるいは、蜂蜜小梅配列のほか、シンプルな小梅配列もある――などと説明される場合もありますが、ちょっと待てと言いたい。

2つの日本語配列の関係性を紐解くならば、どちらも俺の、俺による、俺のための俺様配列=同じもの=です。性能や成熟度といったパラメータこそ異なりますが、蜂蜜小梅配列が「小梅配列との上位互換性」を捨てた瞬間から、2者の時間軸は継承・連続していることをまずは強調しておきます。

蜂蜜小梅配列のカナと記号が、キー別・シフト別にどの時点で確定したか、最終更新時期=最終確定時期をまとめた下図をご覧ください。赤く塗られた「5」の部分が、蜂蜜小梅配列を名乗った 2.0.0版 ⇒ 2.5.6 版の時期に進化した部分です。全部で33エリアありました。[D×K]の「を」を含めると35エリアが、小梅配列から蜂蜜マトリックス以外で成長しているのです。

キー毎に時計回りで無シフト、右シフト、左シフトを表記しています。例えば「N」キーでは、無シフト「っ」が実用版時点に確定、同様に右シフト「み」が投了版時点、左シフト「ぇ」は 最終版時点に確定しています。

蜂蜜小梅配列のカナと記号の最終更新時期""

蜂蜜小梅配列に脱皮する最終フェーズで何をやっていたかというと、

  • 日本語配列としての安全性を高める
  • 低頻度カナ対策を充実させる
  • 記号の配置を見直す
  • 無シフト率を高める

といった課題に、思考実験の積み重ねで対応していました。

我が輩はカエルである

関係性をオタマジャクシとカエルにたとえてみましょうか。2者は見た目も名前も異なりますが、どちらも同じ生き物(幼体と成体)なのはご存知の通り。親指シフトという沼で暮らしていた小梅配列に、いつしか蜂蜜マトリックスという手足が生えて、さらに35カ所が変態してカエルとなった蜂蜜小梅配列は、陸をピョンピョンと自由に飛び跳ねています。

未熟なオタマジャクシを他人様に推奨するというオプションは、少なくとも作成者の私にはありえません。

「だけでも」から始めよ

蜂蜜小梅配列で「だけでも」は[S右][W左][E右][D左]。

タイプアシストを使うと[WE][SD]。

これを覚える「だけでも」全然違います!

ラベル:蜂蜜小梅配列
posted by 141F at 00:24| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年11月10日

「かえうち」を導入した(4)

お待たせしました。「かえうち」用の蜂蜜小梅配列カスタマイズファイルを公開します。

蜂蜜小梅配列「かえうち」カスタマイズファイル@141F ver.

当初、シフトの掛かり方に難ありの状態です と記しましたが、シフトが期待通りに掛からなかったのは、「かえうち」の同時打鍵ロジックそのものに原因がありました。

2種類の打鍵方式

画像化して、見たままのスタイルで引用します。

蜂蜜小梅配列のハイブリッド同時打鍵は、上記引用の「ながら押し」に該当します。

  • 先に[★]キーを打鍵して、次に[☆]キーを打鍵する
  • 先に[☆]キーを打鍵して、次に[★]キーを打鍵する

上記パターン各々に別の機能を割り当てられるのは何だか便利そうですが、「同時打鍵」したい私にとってこれ以上の迷惑はありません。キーボード入力における「同時打鍵」は、厳密に言えばキーを「同時に打鍵している」のではありません。

  • [★]⇒[☆]の打鍵
  • [☆]⇒[★]の打鍵

どちらも等しく「同時打鍵」です!

私の場合は[文字]キーが先になる[親指]キー同時打鍵がわりと多いみたいで、[親指]キーに[文字]キーを同時打鍵したパターンしか定義していなかったので、見事にシフトが掛からなくなっていました(注)。

[★]⇒[☆]の定義だけして、[☆]⇒[★]と打鍵していたら、シフトが掛かるはずもなく。

ということで、

「ながら押し」ではなく「同時押し」に設定するには

いささか冗長ですが、マニュアル通りに双方向で定義することで、シフトが確実に掛かるようになりました。

本日の不具合(再掲)

  • 濁点「゛」、半濁点「゜」の単独入力ができない⇒「う゛」なんていう表現がキーボードだけでは難しい。
  • 各種括弧を使い分けて定義しても、期待通りに入力できない。
  • かえうちパートナーを起動していると、カギ括弧ペア「」の入力が「』に化ける。
  • ctrl-k+s 等の2ストロークキーコマンド(^ks と表記)が実行不能。

これらはすべて「仕様」とします。このうち、1番目は「かえうち」の仕様、3番目はかえうちパートナー for Windows の既知の不具合とマニュアルに記載がありました。4番目の2ストロークキーコマンドは、ctrlキーを押したまま[K][S]と順に押すことで無事に実行できました。

かえうちでの蜂蜜小梅配列の使い方

  • [ひらがな]キーでオン
  • [半角/全角]キーでオフ

かえうちを使ってみて

ストアアプリでも蜂蜜小梅配列で入力できてしまうのって、とっても不思議な面持ちになりますね。ただし、「かえうち」を使えば万事解決してオールハッピーかといえば、さにあらず。現状で最大の不満は、なしてすぐ off になる?

ブラウザを見てエディタに戻ると勝手に off になる。ブラウザでフォーカスを隣のタブに移すと勝手に off になる。それどころか、検索窓に入力して検索した瞬間、勝手に off になる。なして? なして? なして?

明示的に off にしない限り、ずっと on のままでいられる設定って、どこかにないのでしょうか。

最後に、素晴らしい未来をご提供いただき、本当に感謝しています。ありがとうございました>うぇぶしまさん。

posted by 141F at 01:43| Comment(1) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年11月08日

「かえうち」を導入した(3)

本日の進展。

  • 記号の類を実装した。
  • 小指シフト面を実装した。
  • ctrl-c や ctrl-v 、shift+space 等のキーボードオペレーションが支障なく行えるようになった。

本日の不具合。

  • 濁点「゛」、半濁点「゜」の単独入力ができない⇒「う゛」なんていう表現がキーボードだけでは難しい。
  • 各種括弧を使い分けて定義しても、期待通りに入力できない。
  • かえうちパートナーを起動していると、カギ括弧ペア「」の入力が「』に化ける。
  • ctrl-k+s 等の2ストロークキーコマンド(^ks と表記)が実行不能。

これらの不具合については、最悪の場合「仕様」扱いでこのままリリースするかもしれません。悪しからずご了承ください。

posted by 141F at 02:46| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年11月07日

「かえうち」を導入した(2)

今夜は「かえうち」で入力しています。

シフトが掛からない原因が、どうやら特定できたようです。とりあえずの対策を施したので、あとは試し打ちでバグをつぶしがてら、微調整を加えていきます。

記号がまだ完全に実装できていないので、そこはきちんと対応します。それから、ctrl-c や ctrl-v、shift+space 等のキーボードオペレーションに副作用が出ているので、もう少し勉強しないとダメみたい。

posted by 141F at 00:41| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年11月05日

「かえうち」を導入した

諸々の懸案がひと段落して、かえうち をようやく開封しました。Windows 10 home (64bit) へのドライバインストールでいささかハマりましたが、とりあえずハードウェア的には無事に動いています。

私の環境では USB 3.0 ポートでのみ正しく動作するようです。

かえうち動作中

導入の目的はもちろん蜂蜜小梅配列の実装ですが、今のところ期待通りにカスタマイズできていません。「こうめはいれつ」と入力しようとしても、「こうめはいい《変換》」となってしまったりして、シフトの掛かり方に難ありの状態です。

右往左往しているうちに、ken_m さんが「かえうち」フォーラムに 蜂蜜小梅配列のカスタマイズファイル を投稿してくださいました。ありがとうございます。ただし、この投稿のも試してみましたが、私のところではどうにもダメでした。

回避できる設定を求めて、しばらく試行錯誤してみます。

posted by 141F at 23:08| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年04月15日

蜂蜜小梅配列 配列定義一覧を公開します

お待たせしました。リクエストを頂戴していた、蜂蜜マトリックスを含む配列定義一覧を、pdf形式で公開します。

蜂蜜小梅配列 配列定義一覧(pdf形式)
左シフト/右シフト で表記
蜂蜜小梅配列 配列定義一覧(pdf形式)
同手シフト/他手シフト で表記

こんな感じでよろしかったでしょうか。ご感想、ご要望、その他諸々はコメントまたはメールで承ります。

ラベル:蜂蜜小梅配列
posted by 141F at 01:58| Comment(0) | TrackBack(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年04月09日

日本語配列選びを結婚にたとえてみる

会話が成り立つ人が出てくるとホッとしますね。真摯なご指摘に感謝します。

610 :名無しさん:2017/04/07(金) 02:18:54.43 0.net
蜂蜜小梅の作者のブログを見たら作者もこのスレ見てたんだな
そしてやっぱり同じレスに突っ込みを入れてるのか
ただ、>>492>>536>>603のようなレス(多分同じ奴の自演レス)が>>606が指摘するようにとんちんかんなのは間違いないけど、蜂蜜小梅の問題点を指摘してる親指Blogのコメントも無視すべきではないよ
親指Blogの指摘を「お前にあわなかっただけだね」で済ませてるけど、蜂蜜マトリクスを入れたために習得のハードルが上がったのも事実なんだから
「お手軽版の小梅配列」「完全版の蜂蜜小梅配列」の2段階で配列提案をした方がよほど現実的
こう書くと「ならお前にあった私家版にすればいいだろ」と言われそうだけど、それができないからみんなあーでもないこーでもないといってるわけでね
NICOLAや他の派生版の作者もそうだけど、高学歴者や理系人間特有の「技術・能力のないアホは知ったこっちゃない」という態度に終始しすぎ

去る者は追わず。こと配列選びにおいて、薔薇色の明日を安売りしたり、意味もなく引き留めたりするのは、その人の幸せな暮らしを邪魔するだけ。どの日本語配列を使うか、どんなパートナーと日常生活を共にするかを決めるのは、他の誰でもない、あなたです。

一緒に暮らすパートナーにいったい何を求めるのか。性格かルックスか。会話は弾むか。性癖は合うか。経済力はあるか。行動力に付き合えるか。共通する趣味は何だろう。親兄弟親戚はどんな感じ。DVの心配はないか等々、選ぶ基準は多々あります。全てがパーフェクト、理想的なパートナーに出会えることはおそらくなくて、何かを優先すると他の何かで妥協を強いられるのが現実はないかと。

付き合ってもいない相手に一方的に付きまとって、思い込みで叩くストーカーも時として現れますが、自律性・多様性を否定するその姿は哀れとしか言いようがありません。

蜂蜜小梅配列が咲く場所

日本語配列も、行段系・カナ系・漢直という大きな括りから始って、選択肢がいっぱいあります。どれを選んだらいいかホントに迷いますよね。

私はといえば、長年連れ添った Nicola 配列を見限って、飛鳥カナ配列を少しかじって吐き出して、それならいっそ今どきの親指シフトを作ってしまえ!と軽い気持ちで手を出したのが、小梅配列のそもそもの始まりでした。それからいろいろあった末にたどり着いたのが、日本語を日本語のリズムで入力する、リアルな「日本語をおしゃべりするキーボード」蜂蜜小梅配列です。

私自身は、文章を読むときと同じくキーボードを使って入力するときも、「脳内発声あり」タイプです。しかもその発声はあまり冗舌ではないので、入力スピードはお世辞にも速いとは言えません。でも、だからこそ発音と入力が一致すると気持ちいい。蜂蜜小梅配列には、そんな私の性癖が色濃く反映されています。

カナ系であること、カナの打鍵範囲が比較的コンパクトなこと、入力ルールが比較的シンプルなことは、速い/間違いが少ない/疲れない入力を目指すうえでプラスになる一方、同時打鍵を多用すること、特に同手シフトを許容することと連想記憶に頼るところはマイナスポイントになります。

省打鍵が狙いのタイプアシストを使う時は、申し訳ありませんが発音と入力が一致しません。一致しないその1モーラだけ私の指は立ち止まって、脳内発声が追いつくのを待っています。

そんなこんなで多少のエクスキューズを含みつつ、蜂蜜小梅配列はここに咲いています。

で、つまるところ、どんなパートナーと暮らしたいって?

あなたが使いたいのは、どんな日本語配列ですか。あなたが付き合いたいのは、どんなパートナーでしょう。

覚えやすい親指シフトがお望みならば、昭和のアイドルが未だに微笑んでいます(苦笑)。

スピードをひたすら追求したいなら、蜂蜜小梅配列を選ぶべきではありません。

日本語を日本語のリズムで入力したい。でも、複雑な入力ルールは覚えたくない。蜂蜜小梅配列は、こうしたニーズにピンポイントで寄り添います。蜂蜜マトリックスは私にとって救世主だったから、私はこんな書き方をしていますが、一方でそれを苦行と感じる人もまたいるわけです。蜂蜜小梅配列との邂逅が満たされない日々になったとしたら、それはあなたの配列選びが失敗したということ。違和感を糧とし、自己分析を道標にして、肌が合うパートナーを求めて次の旅にとっとと出るがよろしい。

メリットの裏にはデメリットが必ずあります。叩き込んだ目の前の釘は、反対側に飛び出します。パーフェクトな人間なんて存在しないのと同様、パーフェクトな日本語配列もまた存在しません。譲れない性能と消し去りたい欠点の狭間に、工夫と妥協の結果として、蜂蜜小梅配列もまたあります。

あなたが使いたいのは、どんな日本語配列ですか。あなたが付き合いたいのは、どんなパートナーでしょう。譲れない一線はどこですか。どんなアバタなら、エクボとして許してくれますか。あなたがパートナーに求めれば求めるほど、パートナーもまたあなたに代償を求めます。

そこで配列作者ができること

何度も同じことばかりで恐縮ですが、だからこそ配列作者がやるべきことは、

  • コンセプトを明確にすること
  • 的確に実装すること
  • 正しくプレゼンテーションすること

の3点だけです。皆々様の幸せなマリアージュをご祈念申し上げます。

posted by 141F at 02:40| Comment(0) | TrackBack(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年04月07日

化石対応してみるテスト

ガッチガチに凝り固まった化石頭は、もしかして、もしかして、こういう風に書かないと理解できない??

蜂蜜小梅配列

基本定義と「を」のみ記す。〓 は未定義。

無シフト
1 2 3 4 5 | 6 7 8 9 0 − ^ ¥
 。 な て せ そ | ・ お の に 「」 、 ()
  こ た か | い し と BS ESC
   ゆ ほ ま ろ 〜 | っ う す ら へ _
同手シフト【裏】
? / 〜 「 」 | [ ] ( ) { } 〜 〓
 ぺ け よ ― … | ゐ ひ き つ 「  () {
  め や も | く り わ ね }
   ゅ ゃ ふ ょ ぉ | み あ え ち ぬ ?
他手シフト【逆】
! ” # $ % | & ’ < > + = ‘  |
 ぱ げ で ぜ ぞ | ゑ び ぎ づ  」 ゛ ゜
  ご だ が | ぐ じ ど ぴ *
   ぽ ぼ ぶ ぷ ゎ | ぇ ヴ ず ぢ べ !
小指シフト
! ” # $ % | & ’ < > ^ = ‘ |
 Q W E R T | Y U I O P @ [
  A S D | K L ; : ]
   Z X C V B | N M , . / _
文字キー同時シフト
  • [D]×[K]=「を」
眺める角度の違い

蜂蜜小梅配列がいつも見せているのは、【右シフト】面と【左シフト】面です。

【右シフト】面
「親指右シフト」キーと同時打鍵時に入力されるカナ・記号
【左シフト】面
「親指左シフト」キーと同時打鍵時に入力されるカナ・記号

【同手シフト】面・【他手シフト】面とは眺める角度が異なるだけで、本質的には同じものです。

posted by 141F at 01:18| Comment(1) | TrackBack(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年04月05日

ツンデレ返し

Nicola スレってホントに面白いですね。

603 :名無しさん:2017/04/04(火) 18:41:29.80 0.net
>>492のように蜂蜜小梅なんてNICOLAよりも覚えにくいし、キーボードを選ぶという短所は引き継いでいるんだから、
NICOLAよりも劣る。
他の派生型(のほとんど)のいいところは、キーボードを選ばないという点。
ものによってはエミュレーターが不要で既存のIMEのローマ字設定を変えるだけというものもある。

蜂蜜小梅配列のことが気になって気になって仕方がないくせに、論理や因果は二の次にして、思い込みだけでディスりまくる。ったく、どんだけツンデレなんだよ。そろそろ、自分が恋に落ちてることに気づいてもいいんじゃないかな(大笑い)。できない理由を並べる暇があったら(以下略)

KV

597 :名無しさん:2017/04/01(土) 22:43:32.41 0.net
ローマ字入力と比べれば、NICOLAで小指が痛くなるというのはごくわずかでしょ。
そりゃ、不満点はあるけど、慣れればなんでもなくなる。

キーボード入力が原因で指が痛くなるっていうのは、絶対にダメです。そんなことに慣れちゃいけない。

小梅配列の開発過程では紆余曲折があって、相応に痛い思いをしてきました。現在は蜂蜜小梅配列で入力する限りにおいては、どの指も痛くなりません。痛くならないってことが、安心して入力できるということが、どれだけありがたいことか。こと安全面においては、妥協しなくてホントによかった。どうしても越えられない壁があった小梅配列に見切りをつけて、蜂蜜小梅配列の開発に全面的にシフトした 2.0.0 版当時の判断は正しかったと、つくづく思います。

「許すな KV」キャンペーンでも始めようかしら。やめよう、keyboard violence !!

Y

581 :名無しさん:2017/03/31(金) 00:51:24.94 0.net
>>579
そのへん蜂蜜小梅がYに「・ゑゐ」を置いてるのは考えられてるっぽいね
拗音の規則性もまぁ覚えやすいんではないの

「てゅ」「でゅ」は確かに忘れそうだな…
用例「デュエル」「フォンデュ」「デュマ」くらいしかぱっと思い浮かばんけど
582 :名無しさん:2017/03/31(金) 06:54:29.48 0.net
>>581
「ゑゐ」なんかに割り当てている段階で、かなり痛いマイ配列だな
584 :名無しさん:2017/04/01(土) 02:45:34.41 0.net
>>582
俺、今まで「ゑゐ」なんか使ったことないんだけど。。。
作者さんは何か特殊な仕事をしている人なのかな?

「ヰセキ農機」「ヱビスビール」なんていう固有名詞ぐらいしか、「ゐ」「ゑ」の使い道が思いつきません。約物扱いと呼ばれれば、確かにその通りです。

  • [Y]キーは(カナ入力に)使わねえ!

というメッセージを読み取っていただければ幸いです。

Nicola スレにとって

蜂蜜小梅配列が目の上のタンコブになっていることが、よく分かりますね(爆笑)。まだまだ目が離せません。

posted by 141F at 02:14| Comment(0) | TrackBack(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年03月09日

日本語のリズムで日本語を入力する

前稿 無シフトにどのカナを置くか を少し補足します。拗音と撥音、促音、そして長音が入り混じったカナを入力した時に、発音と打鍵が一致するかどうか、表で分かりやすく比較します。

モーラ数=名目打鍵数だった場合、発音と打鍵が一致したと表します。また、表を見やすくするため、「打鍵するキー」の1打目は「し」を、3打目または4打目は「と」を入力するキーに固定して表記します。

発音と打鍵の一致比較表

蜂蜜小梅配列
かな 用例 構成 モーラ数
morae
打鍵するキー 名目打鍵数
strokes
実質打鍵数
keys
発音と打鍵の一致
morae = strokes
1打目 2打目 3打目
しと 使途 直音のみ 2 2 2 一致
しんと 信徒 撥音 3 3 3 一致
しっと 嫉妬 促音 3 3 3 一致
しーと シート 長音 3 3 3 一致
しゅと 首都 拗音 2 S+L 2 3 一致
しゅうと 州都 拗音 3 S+L 3 4 一致
しゅんと〓 春闘 拗音 + 撥音 3 S+L 3 4 一致
しゅっと〓 出頭 拗音 + 促音 3 S+L 3 4 一致
しゅーと シュート 拗音 + 長音 3 S+L 3 4 一致

発音と打鍵が一致するように設計してあるので、当然の結果です。表中で2打目のキーがすべて右手人差し指になっているところが、もしかしたら蜂蜜小梅配列を語る上での一番の肝かもしれません。

Nicola 配列
かな 用例 構成 モーラ数
morae
打鍵するキー 名目打鍵数
strokes
実質打鍵数
keys
発音と打鍵の一致
morae = strokes
1打目 2打目 3打目 4打目
しと 使途 直音のみ 2 2 2 一致
しんと 信徒 撥音 3 3 3 一致
しっと 嫉妬 促音 3 右親指+; 3 4 一致
しーと シート 長音 3 左親指+X 3 4 一致
しゅと 首都 拗音 2 左親指+F 3 4 不一致
しゅうと 州都 拗音 3 左親指+F 4 5 不一致
しゅんと〓 春闘 拗音 + 撥音 3 左親指+F 4 5 不一致
しゅっと〓 出頭 拗音 + 促音 3 左親指+F 右親指+; 4 6 不一致
しゅーと シュート 拗音 + 長音 3 左親指+F 左親指+X 4 6 不一致

実質打鍵数が多くなることも含めて、「日本語をおしゃべりするキーボード」という性能に達していなかったことが、この表からも一目瞭然ですね。

個人的には、左手の打鍵が連続する「しゅう」や「しゅー」の 3-gram(収集やジュージュー等)を、左手の指を折り曲げて窮屈に入力していたことを、懐かしく思い出しました。

Nicola 拗音拡張
かな 用例 構成 モーラ数
morae
打鍵するキー 名目打鍵数
strokes
実質打鍵数
keys
発音と打鍵の一致
morae = strokes
1打目 2打目 3打目
しと 使途 直音のみ 2 2 2 一致
しんと 信徒 撥音 3 3 3 一致
しっと 嫉妬 促音 3 S+@ 2 3 不一致
しーと シート 長音 3 左親指+X 3 4 一致
しゅと 首都 拗音 2 S+M 2 3 一致
しゅうと 州都 拗音 3 S+M 3 4 一致
しゅんと〓 春闘 拗音 + 撥音 3 S+M 3 4 一致
しゅっと〓 出頭 拗音 + 促音 3 S+M 右親指+; 3 5 一致
しゅーと シュート 拗音 + 長音 3 S+M 左親指+X 3 5 一致

ウェブサイトの記述を「だろう運転」で解釈しているので、打鍵するキーが間違ってないか、かなり心配です。間違いを見つけたら、コメントでもメールでも構いませんので、はっきりと教えてください。

上の表が正しいという前提で語るならば、拗音入力はオリジナル配列に比べて改善されましたが、促音拡張まで欲張ったことが裏目に出て、発音と打鍵が一致しなかったり、捨て仮名「っ」の打鍵方法がまちまちだったりするのがちょっと残念。

蛇足ながら、コメント欄で Nicola 原理主義者に咬みつかれているのに今頃気付いて、気の毒と思いつつも大笑いしてしまいました。申し訳ありません。

でも、LED を知ってしまったら、もう白熱灯には戻れません。産業遺産を愛でるのは愉快だと知っていますが、普段遣いの日用品とは異なるからこそ興味深く思えるのです。そして何より、改良を否定する行為は万死に値すると信じます。どれだけ罪を重ねたらこんな無間地獄に落ちてしまうのか、ホントに不思議でたまりません>Nicola 原理主義者の皆様。

「拗音だけ」と呼ばれて

拗音、撥音、促音、長音、そして連濁も含めた日本語の特性を咀嚼して、21世紀基準の日本語配列=蜂蜜小梅配列は、日本語を日本語のリズムで入力します。

関連記事

無シフトにどのカナを置くか
2017-03-01
posted by 141F at 02:26| Comment(0) | TrackBack(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年03月01日

無シフトにどのカナを置くか

事実無根の垂れ流しは、さすがに見逃せません。少し間が開いてしまいましたが、Nicola スレのこの発言に言及します。

なぜ蜂蜜小梅がNICOLAよりも覚えにくいのか。
NICOLAは清音をクロスシフトすると濁音になるという規則の例外はない。
だから「は」を覚えれば「ば」を覚えたも同じ。
蜂蜜小梅は、清音を濁音化するのに、ストレートシフト化する場合もあれば、
ストレートシフトをクロスシフトにする場合もある。
蜂蜜小梅のウリは拗音ワンアクション化なのだが(撥音は未対応)、
例のライフラボの人が考えたNICOLA拗音拡張だとNICOLAの上位互換で拗音も撥音(っ)も対応している。

蜂蜜小梅配列は清濁拗同置の日本語配列です。したがって、

清音をクロスシフトすると濁音になるという規則の例外はない。だから「は」を覚えれば「ば」を覚えたも同じ。

という因果関係は、蜂蜜小梅配列でも成立します。

蜂蜜小梅は、清音を濁音化するのに、ストレートシフト化する場合もあれば、ストレートシフトをクロスシフトにする場合もある。

蜂蜜小梅配列の濁音は全て他手シフト(クロスシフト)です。同手シフト(ストレートシフト)で濁音を入力することはありません。この手の post-truth は、マジで勘弁して。

Tron ルールは覚えにくい?

本稿では、清濁同置に関する下記原則を、それぞれ Nicola ルール、Tron ルールと呼称します。

Nicola ルール
濁音を持つ清音は、濁音と同じキーの無シフトに置く
濁音は他手シフトに置く
Tron ルール
濁音を持つ清音とその濁音は、同じキーに置く
濁音は他手シフトに置く

周知の通り、蜂蜜小梅配列は Tron 配列の清濁同置ルールを パクって 踏襲しています。都度シフトの親指シフト配列では、シフトが連続してバタバタした打鍵になることはできるだけ避けたい課題です。つまり、無シフト率が高いことは「是」。論理配列比較 Nicola vs Tron を書いた私が、無シフト率を上げやすい Tron ルールを選ぶのは必定でした。

で、Tron ルールは Nicola ルールよりも覚えにくい? 今さらそんなことを聞かれても、正直なところ、「は? 何言ってんの?」としか答えようがありません。

蜂蜜小梅配列の「じ」と「ぢ」を例にとると、清音の「し」は[L]キー無シフト、「ち」は[.]キー同手シフトと、清音側のシフト状態は異なりますが、

  • 「じ」は「し」の他手シフト
  • 「ぢ」は「ち」の他手シフト

と、全く同じ意識で(仮想キーを)打鍵できます。

逆に、「し」は「じ」の清音だから[L]キー無シフトを打鍵しようと考えたり、「ち」は「ぢ」の清音だから[.]キーの、、あれ? どっちのシフトだっけ? と迷ったりなんてことは、どちらも全くありません。

小梅配列の開発過程を振り返っても、Tron ルールは覚えにくい・思い出しにくいから Nicola ルールに戻そう、なんて考えたことは一切ありません。長年付き合った Nicola 配列と小梅配列とで、覚えやすさに差があると感じたことも皆無です。Tron 配列や小梅配列・蜂蜜小梅配列のユーザが「Tron ルールは覚えにくい」と嘆いたりするのを、寡聞にして一度も見たことがありません。

むしろ問いたい。

  • 濁音を持つ清音は、濁音と同じキーの無シフトに置く

という Nicola ルールは、何か役に立っているのでしょうか。

Nicola ルールは何のためにある?

まずは清濁同置の親指シフトを採用した各配列の無シフト率を、例によって 10万字サンプル を用いて紐解きます。対象としたのはカナと句読点及び長音の合計 101,156 字で、「。、ー」以外の記号や英数字は割愛しています。蜂蜜小梅配列はタイプ・アシストを使わない条件で計算しています。

上下ホーム段別の無シフト率

Nicola 配列 Tron 2005-1011 蜂蜜小梅配列
無シフトの
打鍵数
名目打鍵数
比 101,156
実質打鍵数
比 143,825
無シフトの
打鍵数
名目打鍵数
比 101,156
実質打鍵数
比 126,509
無シフトの
打鍵数
名目打鍵数
比 98,619
実質打鍵数
比 133,254
上段 20,940 21.2% 14.6% 19,177 19.4% 15.2% 19,386 19.7% 14.5%
ホーム段 31,899 32.3% 22.2% 35,716 36.2% 28.2% 31,851 32.3% 23.9%
下段 5,648 5.7% 3.9% 19,906 20.2% 15.7% 13,401 13.6% 10.1%
合計 58,487 59.3% 40.7% 74,799 75.8% 59.1% 64,638 65.5% 48.5%

蜂蜜小梅配列のトータルの無シフト率は、Nicola 配列と Tron 配列の中間ぐらい。段毎の詳細を見ると、蜂蜜小梅配列の無シフト率が Nicola 配列を上回っているのは下段だけで、上段とホーム段はほぼ拮抗していることが分かります。Tron 配列が比類ない圧倒的な無シフト率を誇るのに対して、同じ Tron ルールを採用した蜂蜜小梅配列が中庸と呼ぶしかないスペックにとどまったのには、もちろん理由があります。

無シフトに置いたカナ、置かなかったカナ

無シフトに置いたカナを、具体的に比較します。

【濁音を持つ清音】
かきくけこさしすせそたちつてとはひふへほ
全20字
【他の清音・捨て仮名・記号】
あいうえおなにぬねのまみむめもやゆよらりるれろわをん「ぁ」「ぃ」「ぅ」「ぇ」「ぉ」「っ」「ゃ」「ゅ」「ょ」、。ー,.・〜「」
全44字

【濁音を持つ清音】と【他の清音・捨て仮名・記号】、つまりは濁音・半濁音以外の合わせて64字を、清濁同置の各配列は無シフトという特等地にどう配字したのか、一覧表にまとめました。


無シフトに置いた【他の清音・捨て仮名・記号】 無シフトに置かなかった【濁音を持つ清音】
Nicola 配列 。ら,、ういん.めね 10/44 0/20
Tron 配列 らる「ょ」のあれもをいうんまりにな、。「っ」 18/44 けせそちひふへほ 8/20
蜂蜜小梅配列 。な・おのに「」、るーんいゆまろ〜「っ」うら 19/44 きくけさちつひふ 8/20

Nicola 配列の配字規則は、先の Nicola ルールのほかに特筆すべきは、下段を嫌ったことぐらいですかね。対する Tron 配列は、同じ手の同手シフトの連続を排除するために、無シフト率と交互打鍵率を徹底して高めたことが分かっています。

蜂蜜小梅配列が無シフトに仕掛けたこと

そして、蜂蜜小梅配列はというと、

  • 左手の打鍵が連続するのを避けるため、交互打鍵率を高めて左手連打率を最低限にした
  • 遠いキーほどシフトを減らした
  • 文末優先で「。なてせおのに、たるはんいしとまろうすらへ」を無シフトに置いた
  • 撥音対策として「ん」を無シフトに置いた
  • 促音対策として「っ」を無シフトに置いた
  • 長音対策として「ー」を無シフトに置いた
  • 右利き専用配列として、安全対策を徹底した

等々いろんなことを、飛鳥カナ配列の Ray 先生に倣ったことも含めて、無シフトに施しています。小梅配列と呼んでいた時代は、拗音対策として「ゃ」「ゅ」「ょ」を左手下段の無シフトに置いていましたが、拗音拡張を施した蜂蜜小梅配列へと脱皮する過程で放棄しました。様々な対策を講じた結果としての、実質打鍵数比 48.5% という蜂蜜小梅配列の無シフト率に、私は満足しています。

Nicola ルールに従えば、【濁音を持つ清音】以外のカナ・記号を無シフトに配字できる自由度は10字分しかないわけで、きつい制約はデメリットでしかないと判断します。下段嫌いと併せて、何のメリットも生まない Nicola ルールに拘泥するのはひたすら無益です。

今にして思えばですが、Nicola ルールは清濁同置の親指シフト誕生時ならではの、屋上屋を架す規則だったと言えます。無駄かどうかもやってみなければ分からない、原始配列ならではの苦労がしのばれます。

無シフトに置いた促音と長音、撥音

促音と長音、そして撥音を無シフトに置いた理由についても宣伝しておきます。下記の例示はそれぞれ何モーラか、実際に声に出して確かめてみてください。

しき(四季)
直音のみ
し + き:2モーラ
しょき(初期)
拗音を含む
しょ + き:2モーラ
しっき(漆器)
促音を含む
し + っ + き:3モーラ
しんき(新規)
撥音を含む
し + ん + き:3モーラ
しょうき(正気)
拗音を含む
しょ + う + き:3モーラ
しょっき(食器)
拗音と促音を含む
しょ + っ + き:3モーラ
しーと(シート)
長音を含む
し + ー + と:3モーラ
しょーと(ショート)
拗音と長音を含む
しょ + ー + と:3モーラ

促音「っ」と長音「ー」、そして撥音「ん」も、それ自体は1モーラを消費します。拗音の直後に促音、長音、撥音が続くことも珍しくありません。だから蜂蜜小梅配列は、促音と長音、撥音についてはシフトを併用する拡張扱いとせず、最も素早く動かせる右手人差指の無シフトに置いています。シンプルな入力ルールで、正気と食器、ショートを同じ打鍵感で扱えるのが、21世紀基準の日本語配列=蜂蜜小梅配列です。

蜂蜜小梅のウリは拗音ワンアクション化なのだが(撥音は未対応)、例のライフラボの人が考えたNICOLA拗音拡張だとNICOLAの上位互換で拗音も撥音(っ)も対応している。

繰り返しになりますが、数が多すぎる拗音は拡張したシフト入力を行いますが、促音と長音、撥音は拡張入力に頼ることなく最優先で待遇しています。蜂蜜小梅配列は、日本語を日本語のリズムで入力します。

無間地獄

原始配列を神格化して、未だにそれが最先端だと信じ込もうとする無理こそが、無限ループに陥った「親指シフトの失敗」だということに、どうして気付かないんでしょうか。

関連記事

左手は親指シフトの同時打鍵も下手みたいだ。
2009-09-10
右人差指の前後の打鍵を分解する。
2009-02-12
同じ手の同手シフトの連続。
2008-08-31
小梅配列の4.4%
2008-08-25
10万字サンプルで「文末」を紐解く。
2008-02-24
論理配列比較 Nicola vs Tron
1995-02-27〜2006-03-05
posted by 141F at 01:42| Comment(0) | TrackBack(1) | oyayubi | このブログの読者になる | 更新情報をチェックする

2016年02月25日

蜂蜜小梅配列の右手小指

親指Blog さんの、閑話:蜂蜜小梅の現状 と題された記事に回答します。

 あと、蜂蜜小梅でも右小指は疲れる。ローマ字のその4にもかいたが、やはりENTERを小指で打つのが問題かもしれない。(まあENTERを薬指で打っても小指にダメージが行っている気がするのだが。)

 そもそも句読点が小指の受け持ちというのがちょっと納得いかない。Pの打鍵を避ける蜂蜜小梅なら、小指への負担軽減ももう少し考えて欲しかった所だ。私はPの打鍵にそれほど抵抗がないので「ね」をPの単独打鍵に割り当てている。蜂蜜小梅では本来の「ね」の位置は右シフト+「:」なので、右シフトをミスタッチすると「BS」になってしまうのが凄く嫌なのだ。小指の使い方はもう少しオリジナルの配列に修正したほうが、自分にはあっているかもしれない。

小梅配列〜蜂蜜小梅配列で句読点を小指に置いた理由は、これまで何度も説明してきました。ポイントは以下の2点。

  • 句読点の入力キーを Nicola 配列互換とした。
  • 打ちやすいキーにカナを集中的に配置した。「記号は二の次」で辺境キーへ。

句読点はそこそこ頻度が高いので、小指に置く他のカナを吟味して、指別の打鍵頻度「中指>人差し指>薬指>小指」を厳守しています。結果として、右手小指の打鍵頻度は Nicola 配列とほぼ横並びになっています。

左右指別の打鍵頻度グラフ(親指キー含む)

[:]キーのシフト側

「Backspace」キーのシフト側へカナを配置したのは、《蜂蜜小梅配列の発明》と自負していますが、フォロワーがなかなか現れません(苦笑)。「ぴ」の置き場所にとことん困って、苦し紛れに見つけ出した《新大陸》が [:]キーのシフト側でした。当然ながら、[P]キーよりも打ちやすい、と私自身は判断しています。

カギ括弧は「論理」キー、角括弧は[物理]キー(qwerty基準)と書き分けています。

「思わねえ」「狙った」「練り物」「インターネット」「ネピア」などと、「ね」を入力したつもりが「Backspace」になって困ったことは、皆無とは言いませんが、ほとんど記憶にありません。

[:]キーのシフト側より[P]キーの方が打ちやすいと感じるならば、打ちやすいキーにカナを優先配置するのが合理的だと私も思います。

[Enter]キーを何に使う?

それにしても、《右手小指だけが疲れる》と自覚できるほど、[Enter]キーって使います? 端的に言うと、《変換の確定》を[Enter]キーで行うことに何故こだわるのか、私には理解できません。

入力から変換・確定に至る一連の動作を、私は次のようにカスタマイズしています。

  • 「親指」キーは[スペース][変換]
  • 「右親指」キーで《変換/次候補》
  • [無変換]キーで《注目文節右》
  • 「左親指」キーで《全確定》

ご覧の通り、変換は右親指、確定は左親指! Nicola ユーザだった頃からずっと、重心低いです。編集作業などは別にして、日本語を入力する局面に限れば、改行以外で[Enter]キーを打鍵することはまずありません。

こういうスタンスなので、[Enter]キーが近いからと英語キーボードにこだわったり、[I]キーや[E]キーとかの特等地に(カナを押しのけてまで)機能キーを配置したりするのが、残念に思えてしょうがない。

蜂蜜小梅配列は、《スペースキーで確定する人》が作成したハイブリッド同時打鍵の日本語配列です。覚えておいて損はありません(笑)。

関連記事

「ぴ」と記号の一部を見直した。
2012-02-13
没ネタ三題。
2012-01-12
右手小指の前後の打鍵を分解する。
2009-02-15
※小梅配列時代の解析記事です
Qと@の句読点。
2006-12-29
届かぬP
2006-03-21
Nicola 三種の神器
2006-03-19
どの指で変換を確定するか
2006-02-15
ラベル:蜂蜜小梅配列
posted by 141F at 03:17| Comment(4) | TrackBack(0) | oyayubi | このブログの読者になる | 更新情報をチェックする