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 | このブログの読者になる | 更新情報をチェックする