約 1,138,077 件
https://w.atwiki.jp/poppy/pages/30.html
ええと数字ばかりで目がちかちかする方も多いでしょうから、文学的な説明を試みて見ましょう。（「君、それは文学だよ」の意味かもしれません…。） ああ…意地でもこの配列で入力しています。意地でも練習のための練習はしていません。尤も、作っている間に頭には入っていますけれども。さすがに一週間ではまだまだ。 まず前提…の前に私の配列遍歴 JISかな 最初はこれでした。ヘミングウェイ式で。 NICOLA これで満足できる方は多いと思います。何と言っても手が覚えやすいです。 ローマ字 便利です。脳内コストとか感じません。でも手が痛くなります。 試用 花 飛鳥 前提 新しい入力方式の習得コストはさほど高いわけではありません。一つの入力方式しか経験されていない方は、習得時の経験からこれを大変なことであるとお考えになるでしょう。しかし、この最初に払った労力のうち少なくない部分は、タイピングという運動形態の習得コストではないでしょうか。 入力方式の多数派が仮名入力からローマ字入力へ移行したのは、このことと無縁ではないでしょう。打鍵範囲が広いものを習得するには、新たな指の動かし方を習得する必要があるからです。苦労して広い打鍵範囲を習得したら幸せになれるのかというと、それをしていない私にはなんとも言えません。 そんな苦労しないで幸せになれる方法を考えよう、と思ったわけです。 習得コストも考慮に入れて、なおかつその悪影響を極小化すべし。 基本方針＝打鍵範囲の極小化に拠り打鍵効率と疲労の低減を図る。 打鍵範囲で選択するならば行段系が普通ですが、打鍵効率で考えるとどうしても不利です。省打鍵のために拡張を図ると打鍵が分散しますし、習得コストが増えてしまいます。規則的に配置すれば頭にはすぐに入りますけれども、習得する＝指が勝手に動くようになるのはまた別の話ですから。その割に打鍵数は減らないのです。アルペジオの気持ちよさを捨てるのも勿体無い。却下。 仮名配列となるとシフト方式が問題になりますね。親指２シフトはどうか。これ有力なんですけれど難があります。 親指キーの確保。物理的な問題もありますけれど、無変換＞BS、変換＞ENTER兼（通常の）シフトと言う割付を何年も使っています。同時打鍵用にBSやENTERはやはり問題があります。 ストレートシフトがそもそも嫌。打ち良いのは右手で言うとIOJKL;くらい。私には下段は打てたものでない。まあ「爪の長さ｣の影響が大きいと思いますから、一般論ではありませんよ。親指キーが一段下にある専用キーボードなら話は違ってきますし。 ………と考えていたのだけど、気を付けて見ると左手は，結構ストレートシフトで打っている。打ち良い位置限定ですけれど。右親指の自然な位置が割れ目だからだろうか。まああんまり考える必要もなくて、手が勝手に打ち良い方でシフトしてくれるらしい。むしろ「次に打たないほうの手」でシフトするのが楽ということかもしれない。（英文タイプではSPACEをそのように打っています。）……… 一般論に戻りますが、親指がキーを打ちやすい位置にいるためには手が動きづらい。逆に言うと、同じ打鍵範囲を広く感じさせる方法だということになります。これは基本方針に反するのです。 さて親指は１シフトと決まったわけですが、新JISをセンターシフトで実装したものがまさにそれです。清音は１ストロークなので見た目は美しいのですけれども難点があるようです。（虞美人草配列的には、ですよ。) 濁る仮名の配置に制約が大きい。これでは基本方針の実現の妨げとなる。 もう一つ、見た目は清濁で同じ鍵を使うで覚えやすそうだが、実際はストロークが違ってしまう。これではストロークの援用ができないので、習得コストの低減効果が低い。「か」が打てれば「が」も打てる…と言うのは間違ってはいない。けれどもそれは、「かん｣が滑らかに打てたら「がん｣が滑らかに打てること、を保証するだろうか？「かん」と「へん」が同じストロークであることは、習得の助けとはならないのではないか？ 濁音にこそ、親指を使うとしよう。 今度は、清音を１,２ストロークに割り振ることになる。なんか気持ち悪いことの様に感じられるかもしれませんけれど、却って濁音が２ストロークである事の方が気持ち悪いのです。一般的にですが濁音は強く短く発音するものです。そうするとこれはエイヤと同時打鍵する感覚と相性が良い。 ………どちらも１ストロークで無きゃ嫌というのは尤もなので、そういう方は２シフト方式がよろしいかと思います。……… でもね、ヒトと云うのは柔軟な生き物で、慣れたら気持ち悪いとは思わないはずです。そうでなければ、「っん」に不備のあるローマ字入力なんてやってられません。 sippai, kassai, annna, kanneiなんておかしいですよ。sitpai, katsai, anna, kan-eiであるべきです。こういう欠陥は、しかし、仮名入力にもあるんです。拗音もそうなんですけれど、「っ」問題もあるんです実は。私、「国会｣を「酷かい｣？とタイプしてしまいます。ローマ字のkokkaiの方が間違えないですね。まあこれは仮名入力の問題点ではなく、表音主義な現代仮名遣いの欠陥ですけれども。…旧仮名が良いと言ってる訳ではありませんよ。振り仮名を付けるのならば「国会(こっかい)」が良いです。… 話が逸れてしまいました。要はちょっとくらい気持ち悪くても効率のいいやり方が良い、という考え方で配列設計したということです。勿論、気持ち良いに越したことはないのですけれど、それが効率とのトレードオフであれば検討を要するということです。原理主義は美しい。けれど、それには対価を払うことになるのです。 払っても良いコストは勿論ありますよ。ちょっと配列選びの話をします。自分のリズムに合うということ、これが一番大事なことだと思います。いくら完成度の高い配列であろうと、リズムが合わないことには駄目なんです。この配列つくる前に他の配列作者の書いていることをかなりたくさん読み返したのですけれど、感覚の遠さを感じることが随分あります。私、ローマ字便利・脳内コストなんかないと言いましたけれど、更なる爆弾発言をします。 漢字＞仮名変換のほうが、漢字＞ローマ字変換よりコストが高いのではあるまいか？ ※これは証明不可能です。私の感覚に過ぎません。 口語・大和言葉・日常語であれば仮名のイメージがすぐ浮かびますから、仮名の方が優っています。しかし文章語・漢語・抽象概念ですとイデア＞漢字のイメージ（書けと言われて書けるかどうかは別の話です)＞脳内発音＞打鍵となります。同音異義語というものがありますから、発音というのは劣化した情報なのですね。(だからこそ仮名漢字変換が必要なのです。)その劣化した音声言語では抽象思考なんてできないのです。ですから漢直以外では３段階ものステップを踏むことになるのです。勿論、頻出であればイデア＞打鍵という様になりえるのですが。 さて、ローマ字のほうがコストが低いというとんでもないお話です。何でそんなことになるかといいますと、表音文字としてはアルファベットのほうが優れている………と感じるからなんです。同音異義語はおいて日常語を書いても見にくくて仕方がない。まあ、馴れという要素も大きいのですが。 仮名文字は漢字と混ぜ書きして使うものであるという特徴をもっていますから、表音文字として劣っていても仕方がないんです。 出典 フリー百科事典『ウィキペディア（Wikipedia）』 音節文字（おんせつもじ）とは、表音文字のうち、音節が単位の文字のこと。 日本語の仮名が代表的。仮名のように、音素の組み合わせでなく、各音節が独自の形を している音節文字を純粋音節文字と呼び、世界的に見て珍しい。一方、ハングルは音素を表す字母を音節ごとに組み合わせて表記する。このような文字を音素音節文字あるいは結合音節文字という。 とまあ、かな文字というのは珍しいとされていますが、これをたまたまと考えるか、表音文字として不利であるからであると考えるかは勿論自由です。 ………ええと、話が進まない。しかもなんて危険な発言なんだ……… 私にとって快適な打鍵のリズムを説明する前提として、脱線したのでした。 こと 創作打鍵 では 一つのイデアを なるべく速く打ち切ってしまいたいのです。 dlf bjkahEdk; Wdj dmfoa iWked s gmRh djzh junow irlel a Wkd. イメージとしては、こんな感じでしょうか。 lkj I f iwfj, dl;g s;I Wicjs. (続く)
https://w.atwiki.jp/keylay/pages/21.html
「ちょっと、かな配列」の記事、配列の評価基準に関連して、月見草での評価関数について少し解説を致します。 「月見草」では「打鍵四連接」、具体的には「最近の打鍵三つ」を考慮した「今からの打鍵負荷」を唯一の評価基準としています。「花」のように「トータルでの指の負担の平均化」は、計算することも考えましたけれど、結局のところ全く計算していません。そんなことをしなくても、それなりに平均化されますので問題ないと評価したということが一つの理由です。もう一つの理由は同じ指を短期間に集中して使うことが問題で、それは四連接までの評価ならば、かなり避けることになるのでそれで十分、というよりも短期間でのばらつきは総計評価より少なくなる。トータルでの頻度を考慮しても、どのみち文章の傾向でかなり差が出てしまうので、例えば「一日の総打鍵」の中でのバランスはとれない。そのようなことのために他の性能を犠牲にするのはかえって良くないのではないかということです。ただ、キーごとの打ちやすさを考慮して、単純な二連接よりやや差をつけて評価していますので、薬指はやや少なく、小指はかなり少なく使うようになっています。 基本的なデータとしては「打鍵二連接の評価値」を用いています。これは「速さ」に近いですけれど若干の違いがあります。まず、早く打てるとしても楽でない連接があると考えて、その評価値を悪くしてあります。具体的には「小指というものは結構器用で速く動くけれどひ弱ですぐに疲れる」ということです。また、速く打つと多少無理があるという評価を下した連接、例えば、｢KO｣はそれほど悪くないけれど、「WD」はちょっと悪いとか、「KU、LU」という連接もあまり良くない、「IN」とかの方がマシとかいうことです。以下のこの項での説明では「ms」と表記していますが、あくまでイメージしやすくするためです。 また、二連接では、さほど「交互打鍵」に拘ってはいません。具体的には「SK50ms」「KS55ms」「KL60ms」「SD65ms」とかいった具合です。 それから、二連接評価では、悪い運指をやや極端に悪く評価しています。例えば「KK」という連打…、それほど嫌うこともないのかもしれませんが、負荷の評価としては「150ms」としています。「KSDL」で170msですから悪すぎるかも知れません…。（ただしこれは、「K」の前の打鍵に問題がなく｢SD｣を滑らかに打てた時の話です。）そうまで低く評価したのは「打ちやすさ、あるいは逆に疲れ」を評価してのことです。 三連接についての評価は二連接の評価を基本に計算されています。ただし、ここで「片手三連打は良くない、特に左手は。」という評価が加えられています。どういうことかといいますと、例えば、「JK」も「KL」も大変打ち良い、速く打てます。しかしながら、「JKL」はあまり良くない…のです。実際、速度を計測するとどうしてもかなり差がつくのです。これはどういう訳かというと、「JK」と素早く連打するときに手首を…若干ですが…使ってしまっていて、その後「L」を打つのは単に「KL」と打つときとはどうも違うという観察結果によるものの様です。このあたりは、「キーボードの物理的特性」「個人の手の力」「構え方」などの要素で随分違うとは思います。 ……「ブナ配列」が速いはずだけれど疲れるという感想を述べておられましたが、この辺りが原因ではないでしょうか。 「月見草」では、この件は大きめに評価してあります。その結果として交互打鍵率が高くなり、「JI」に「ぁ」が割り当てられたりしています。多分、ゆっくり打つ分にはもっと頻度の高い仮名に割り当てたほうがよさそうです。その点「月見草」は高速時に合わせてあるということです。今のところ私にも是非はわからないところです。 また、「KK」と打つのと、「KDK」と打つのではやはり後者のほうが時間がかかります。左右の手が独立としたら説明がつかないのですけれど、何度測っても余計に時間がかかります。また、器用な人なら同じ時間で打てるかもしれないけれども、やはり後者の方が疲れるでしょうということで「KK150ms」「KDK170ms」ということになっています。「KDSL」と同じになってしまいますが…。そのような次第で、実は打鍵数もあまり重視しない計算をしています。しかし頻度の高い仮名が二打鍵になると、必然的に悪い運指が増えてしまいますので、結局はかなり少ない打鍵数となりました。
https://w.atwiki.jp/unitymemo/pages/26.html
配列宣言 private GameObject[] objects; 配列生成 objects = new GameObject[20]; 配列要素への代入 objects[i] = cube; 配列要素の破壊 Destroy(objects[i]); 配列の要素数 objects.Length 多次元配列 int[,] map = new int[10,10]; int[,] map = { {0,0,0}, {1,1,0} }; 多次元配列の長さ map.GetLength(要素番号) for (int i=0; i map.GetLength(0); i++) { for (int j=0; j map.GetLength(1); j++) { map[i,j]=0; } } 連想配列（ハッシュテーブル） Hashtable ren = new Hashtable(); ren[ key ] = www.text; 文字列配列 string[] menuTitle = { "物理","生物" };
https://w.atwiki.jp/slimelv1024/pages/54.html
配列とは 仮に学生番号を入れる変数を生徒の人数分作るとします 1人2人ならいいですが、これが100人だったらとても手打ちする気にはなれません このような同じ型で同じ目的を持つ変数をまとめて扱うもの配列といいます 配列の扱い 配列の宣言 型名 配列名[要素数] 変数同様、配列もはじめ宣言しなければ使えません 配列の宣言をすると、配列名[0],配列名[1]・・・配列名[要素数－1]と宣言された要素数の数だけデータを格納する領域が作られます この[]の中の数字のことを添字といいます 配列も変数同様、宣言だけでは中は不定値が入っています 配列の初期化 ①int data1[5]={1,2,3,4,5}; ②int data2[5]={1,2,3}; ③int data3[5]={0}; ④int data4[]={1,2,3} ⑤double data5[5]={1.1,2.2,3.3,4.4,5.5}; ⑥int data6[]; ⑦int data7[3]={1,2,3,4,5]; ⑧double data8[3]; data8={1.1,2.2,3.3}; ① 要素数を宣言し、要素数いっぱいに初期化子を与える ② 要素数を宣言し要素数より少なく、初期化子を宣言します 足りない分はすべて0で補われる ③ ②の応用で足りない分はすべて0で補われることから、初期化子を{0}で設定することですべて0で初期化することが出来る ④ 初期化子がある場合は要素数を省略することが出来ます この場合、要素数は必然的に3になります ⑤ 小数も同じ要領で初期化することが出来ます ⑥ 初期化子が無くて、要素数を省略することは出来ません ⑦ 要素数を超える初期化子の設定は出来ません ⑧ 宣言時以外にまとめての代入は出来ません 配列データの操作 配列データには添字で直接指定してデータにアクセスします もし要素数を超えた添字を指定したとしてもエラーは出ません しかし、その場合配列以外のデータにアクセスしています そのエリアがプログラムに必要なデータを格納してるエリアである可能性もあります そのエリアを書き換えたとしたら、やっぱりプログラムは動きません 配列のデータをまとめて操作したい場合はループ処理を用いる int kuku[9]; int i; for(i=1;i =9;i++){ kuku[i-1]=i*5; //配列に五段を入れる } printf("五の段の九九を表示します\n"); for(i=1;i =9;i++){ printf("3*%d=%d\n",i,kuku[i-1]); //配列の要素を一つずつ表示 } sizeof演算子 配列のサイズを求めるとき使う演算子です int data[20]; printf("配列dataのサイズは%dです\n",sizeof(data)); 文字列とは 文字列とは一般的に複数の文字の列です 中には文字列の型があるプログラムもありますが、C言語には文字列を扱う型がありません C言語で文字列を扱う場合は文字型の配列を使います 文字列の扱い 文字列の初期化 char 配列名[要素数]={ 文字 ・・・ \0 } char 配列名[要素数]="文字列"; 前者の文字列の初期化方法は数値の配列と変わりません 最後の\0は文字列の終了を示す特別なコードです 説明は後ほどします 後者は文字列にのみ使える初期化方法で、前者と違いまとめての代入が可能です 後者の方法では\0を記述しなくても、コンパイラが自動で\0を付加してくれます 終了コード 文字列の最後には必ず\0が付きます これを終了コード又はNULL文字といいます 何故文字列には終了コードが付くのかというと、文字というのも機械にとっては数字の集まりと変わりません 配列は宣言時の中身は不定値です もし何かの文字と同じコードになったとしたら、それが文字なのか、不定値なのかの判断が付きません そのため、文字列の終わりを示す終了コードが必要です また、要素数には\0も含めることを念頭において置いてください 文字列の操作 文字列は初期化子以外ではまとめての代入処理を行うことが出来ません 文字を配列に一つずつ代入するか、strcpy関数を用います 又、ポインタの項で詳しく説明する方法では、文字列をまとめて書き換えることが可能ではあります 文字列の表現は三通りあります 一つ目は配列と同様ループでひとつずつ表示する方法です char name[7]="TANAKA"; int i; for(i=0;i 7;i++){ printf("%c",name[i]); } しかし、これだと文字列を表示するためには毎回ループ文を書かなければいけないので、少し面倒です もうひとつの方法は配列名を指定してあげることでまとめて表示すること出来ます char name[7]="TANAKA"; printf("%s",name); 又は puts(name); 文字列の表示処理は大体こちらの二つの方法を取ります 多次元配列 今まで扱ってきた配列のことを一次元配列といい、表にすると一方に並んでるいるものを想像してください 1 2 3 4 5 二次元以上の配列を多次元配列といいます 二次元配列は縦方向と横方向の二つの方向に伸びる表を想像してください 00 01 02 03 04 10 11 12 13 14 20 21 22 23 24 二次元配列の操作 二次元配列の宣言 型名 配列名[行の要素数][列の要素数]; 基本的には一次元配列と一緒ですが、二次元なので行と列の二つの要素数が必要です 二次元配列の初期化 ①int data1[2][3]={1,2,3,4,5,6}; ②int data2[2][3]={{1,2,3}, {4,5,6}}; ③int data3[][3]={{1,2,3}, {4,5,6}}; ④int data4[2][3]={1,2,3}; ⑤int data5[2][3]={{1,2}, {3}}; ⑥int data6[2][]={{1,2,3}, {4,5,6}}; ⑦int data7[][]={{1,2,3}, {4,5,6}}; ⑧int data8[2][3]={1,2,3,4,5,6,7}; ⑨int data9[2][3]={{1,2}, {3,4}, {5,6}; ① 一次元配列同様カンマ(,)で区切って要素数いっぱいに初期化子を与える ② 二次元配列ではこの初期化の形が一般的で、行に対応させて{}区切って初期化子を与える ③ 多次元配列において先頭の要素数は省略することが出来ます ④ 一次元配列同様0で補われますが、この場合の要素の不足分は{1,2,3,0,0,0}で補われます ⑤ 一次元配列同様0で補われますが、この場合の要素の不足分は{{1,2,0},{3,0,0}}で補われます ⑥⑦ 多次元配列では先頭の要素数以外は省略できません ⑧ 要素数を超える初期化子の設定は出来ません ⑨ 次元の要素数が異なると、{{1,2,0},{3,4,0},{5,6,0}}と解釈され要素数より多いのでエラーとなります 二次元配列の操作 一次元配列同様添字を指定してあげて操作してあげます 注意点も同じで要素数を超えたデータの指定は厳禁です 二次元配列のデータまとめてまとめて操作したい場合は2重ループを行います int kuku[9][9]; int i,j; for(i=1;i 9;i++){ for(j=1;j =9;j++){ kuku[i-1][j-1]=i*j; //九九を作成 } } printf("九九を表示します\n"); for(i=1;i 9;i++){ for(j=1;j =9;j++){ printf("%d*%d=%d",i,j,kuku[i-1][j-1]); //九九を一から表示 } printf("\n"); } 二次元配列と文字列 複数の文字列を扱うときにも二次元配列が使えます char name[3][7]={"TANAKA", "SATOU", "SUZUKI"}; printf("%s",name[0]); printf("%s",name[1]); printf("%s",name[2]); 文字列の表示のときは配列名だけで表示できていましたが、今回は配列名と行要素を指定しています これにはアドレスというものが密接に関わってくるのですが、詳しいことはポインタの項でやります 配列の扱いについては、文字列になってもほとんど一緒です
https://w.atwiki.jp/japanese_keyboard_layout/pages/30.html
どなたでも、自由にリンクを追加することが出来ます。 編集しようとする方は、必ず以下をお読み下さい。 【最重要】他者の著作権を侵さないでください。 【重要】「誰でも自由に複写できる」状態を維持するため、主張・意見・見解などの文、及びリンク先内容の本文・要約・解説などは記述しないでください。技術的な理由により閲覧制限・閲覧条件がある場合は、その条件のみを記述してください。 リンクに用いるタイトルは、可能な限り「元のページにあるタイトルタグの中身をそのままコピー」としてください。不適切なタイトルがついている、もしくはタイトルが存在しないなどの場合については、ページ表題などの文字列を採用してください。「誰が」追記しても「結果は」同じ、という状態が理想です。 できる限り、配列制作者・配列使用者かつ配列そのものについて言及している人・資料のそれぞれを分離して記述してください。 各キー配列の発生年月日が解るものは、配列名のあとに年月日を追記してください。 各ドキュメントの初版作成年月日が解るものは、リンクのあとに年月日を追記してください。 …くらいでしょうか？ あとは、実運用してみて決めるしかなさそうです。 これ以降はリンク集となります。 より詳細なリンク集 制御配列(文字系定義配列とは切り離して使うことが出来る、制御系のみを定義した配列) 姫踊子草制御配列 - 【○○年○月○日～】 配列作者 繭姫版1.3006号構築#201 JCtrl制御配列 - 【2009年5月16日～】 配列作者 JCtrl旧版 配列作者 JCtrl enthumble制御配列 - 【2010年○月○日～】 配列作者 enthumble まだ名前のない制御配列。 ■思考の速度でパソコンを使う技術 - 【2007年2月12日～】 ■思考の速度でパソコンを使う技術
https://w.atwiki.jp/japanese_keyboard_layout/pages/4.html
どなたでも、自由にリンクを追加することが出来ます。 編集しようとする方は、必ず以下をお読み下さい。 【最重要】他者の著作権を侵さないでください。 【重要】「誰でも自由に複写できる」状態を維持するため、主張・意見・見解などの文、及びリンク先内容の本文・要約・解説などは記述しないでください。技術的な理由により閲覧制限・閲覧条件がある場合は、その条件のみを記述してください。 リンクに用いるタイトルは、可能な限り「元のページにあるタイトルタグの中身をそのままコピー」としてください。不適切なタイトルがついている、もしくはタイトルが存在しないなどの場合については、ページ表題などの文字列を採用してください。「誰が」追記しても「結果は」同じ、という状態が理想です。 できる限り、配列制作者・配列使用者かつ配列そのものについて言及している人・資料のそれぞれを分離して記述してください。 各キー配列の発生年月日が解るものは、配列名のあとに年月日を追記してください。 各ドキュメントの初版作成年月日が解るものは、リンクのあとに年月日を追記してください。 …くらいでしょうか？ あとは、実運用してみて決めるしかなさそうです。 これ以降はリンク集となります。 より詳細なリンク集 ○○○○○○○○○。 英字系鍵盤配列に関するリンク集 Qwerty配列 - 【1872年○月○日～】 QWERTY配列 - Wikipedia 配列製作者 Improvement in Type-Writing Machines(1875年3月8日、要TIFFヴューワ) レミントン・タイプライタの人間工学的不備(2000年1月) QWERTY配列に対する誤解(2005年2月10日) どうやってQWERTY配列は主流となったか(2005年2月14日) コンピュータのキーボードはなぜQWERTY配列なのか(2005年3月2日) QWERTY直前のキー配列(2005年3月6日) QWERTY配列再考(2005年5月1日) キーボードのキー配列（歴史）(2005年05月24日) 推理：なぜQWERTY配列なのだろうか WKey キーボードの半分だけを使って簡単片手入力! QWERTYに代わる新しいキー配列 Dvorak(US)配列 - 【1932年○月○日～】 Dvorak配列 - Wikipedia 配列製作者 Typewriter Keyboard(1932年5月21日、要TIFFヴューワ) Dvorak Simplified Keyboard for Japanese Dvorak配列の説明 ［DVORAK］ DVORAKが産みだすステルスな誤入力 Dvorak(ISO)配列 - 【○○○○年○月○日～】 タイピング道場～あぁ愛しのDvorak～ 日本語キーボード向きDvorak配列 Capewell-Dvorak配列 - 【○○年○月○日～】 Projects / Alternative Keyboard Layouts | Michael Capewell | smozoma OEA配列 - 【○○年○月○日～】 配列製作者 各種キー配列 配列製作者 南堂久史のホームページ 配列製作者 Open ブログ Azerty配列 - 【○○年○月○日～】 ○○○○○○○○○。 Qwertz配列 - 【○○年○月○日～】 ○○○○○○○○○。 片手用Dvorak配列 - 【○○年○月○日～】 ○○○○○○○○○。 53keys New Standard Keyboard - 【○○年○月○日～】 ○○○○○○○○○。 Best Evolved layout - 【○○年○月○日～】 Best Evolved layout keyboard layout にて英語で検索 ［DVORAK］ キーボード配列のバトルロワイヤル Colemak配列 - 【2006年1月1日～】 Colemak.com HAMANO Kiyoto氏による公式ページの一部訳出 オルタナ配列──コールマック Colemak Seruxie s layout - 【○○年○月○日～】 Colemak forum / Another layout for your reference Dusk Layout - 【2006年11月19日～】 英数/記号用キー配列 Dusk Layout X-002 QWERF配列 - 【○○年○月○日～】 Projects / Alternative Keyboard Layouts | Michael Capewell | smozoma ASSET配列 - 【○○年○月○日～】 Qwerty, Dvorak and the Asset Keyboard Arensito配列 - 【○○年○月○日～】 The Arensito Keyboard Layout XPeRT配列 - 【○○年○月○日～】 XPeRT Keyboard Aledrnative Carpalx系配列 - 【○○年○月○日～】 Carpalx - keyboard layout optimizer dvorak.jp管理人による公式ページの一部日本語訳 Workman Keyboard 配列 - 【2010年09月06日～】 A Different Philosophy in Designing Keyboard Layouts .
https://w.atwiki.jp/csharpwiki/pages/31.html
配列の初期化 多次元配列、配列の配列 インデクサ 配列の型を変換する
https://w.atwiki.jp/poppy/pages/19.html
NICOLAkana-sample.txt 小薬中人伸 伸人中薬小伸合計 9269151421608590977605上段65709039131629574370625810217136.8% 17577182751847255637165中段887313508152722137016865714294751.5% 105450848438561570下段241533101918409496703207411.5% 2685638867430411851616340合計1785825857303523503818202626527719299.8% 9.6%14%15.5%12.5% 15.7%10.9%12.6%8.8%シフト115965 飛鳥-333kana-sample.txt 小薬中人伸 伸人中薬小伸合計 2077496710150108116上段19312441290912316177430444977117.9% 105641584822713143731183中段146325124320761769915952398016097558% 17923793102514015663下段907013516654914898218506673224% 144332460843114194691862合計1072639884515344491319911702427747899.9% 5.2%8.8%15.5%7.6% 18.2%18.5%16.1%9.7%シフト140635 小梅1.22kana-sample.txt 小薬中人伸 伸人中薬小伸合計 9857129051491478322672上段9225598133089037327762588658031.2% 12008141531719896058550中段347319028245981910816374714410251.9% 9324552772842351775下段5537709976305116219204679616.8% 2279731610398402167212997合計993231725455363326121843626527747899.9% 8.2%11.3%14.3%12.4% 15%16.4%11.9%10.1%シフト103535 さら-1022kana-sample.txt 小薬中人伸 伸人中薬小伸合計 573986001059489081028上段297508382561351090389947191225.9% 129791461615778123796475中段105031795026089189956714632714880553.6% 7424581382027352768下段5058578062737983210805676120.4% 261422902934574286398271合計1585828813406184048897251532127747899.9% 9.4%10.4%12.4%13.3% 16%14.6%14.5%9%シフト81815 虞美人草-3.1kana-sample.txt 小薬中人伸 伸人中薬小伸合計 1611156961427276121141上段9062319191381207828707506021.6% 128332149740690153989222中段956322092388522548615847307521455561.9% 206429767085100372577下段6470890088076264166705684716.4% 1650840169620473304712940合計1693933311667974382817801307534646299.9% 4.7%11.5%17.9%13.2% 14.5%19.2%12.6%6%シフト30749 GA(2ch-698)kana-sample.txt 小薬中人伸 伸人中薬小伸合計 705071001115558472344上段81073572036117252374933118633622.6% 1063515333466181696910945中段552917066337383299616953307520985754.9% 68896410588793715685下段912217225882913325304708579022.4% 2457428843636603218718974合計1546141648629286357323749638638198399.9% 6.4%7.5%16.6%13.3% 14.9%16.4%16.6%7.8%シフト286 月(2-263)kana-sample.txt 小薬中人伸 伸人中薬小伸合計 3035912717462154085878上段45671457818635100264347385710692028.7% 801017640327591362113201中段126451626536831324877197524019589652.6% 688949761009885814872下段50517182700911880304706958518.6% 1793431743603193761023951合計2226338025624755439314591909737240199.9% 4.8%8.5%16.1%16.5% 16.1%16.7%14.6%6.3%シフト286 ローマ字kana-sample.txt 小薬中人伸 伸人中薬小伸合計 16365284441823530326上段78984433148824510432130161023920750.9% 57482254901105413688305中段1311045612958803068167315569933.1% 207148583864747下段373991290562598812118907471115.9% 5955432340403361960943378合計584076179784671598556387328346961799.9% 12.6%6.8%8.5%13.4% 25.5%18%12.7%2%シフト286
https://w.atwiki.jp/crsavrkouza/pages/54.html
12.配列 複数の変数を一度に扱いたいとき便利なのが配列です. 同じ型の変数を複数まとめることができます. 以下のような書式をとります. 宣言時 配列の型名 配列名[要素の個数] = {要素0の値, 要素1の値, ...}; 使用時 配列名[要素の番号] 使用例を見てみましょう. どちらも3つの変数の平均をとっているのですが,片方は変数を個別に用意しもう一方は配列を用意しています. #include stdio.h int main(void) { double x0 = 3; double x1 = 4; double x2 = 5; double x_average; x_average = (x0 + x1 + x2) / 3; printf("average of x is %f\n\r", x_average); return 0; } #include stdio.h int main(void) { double x[3] = {3, 4, 5}; double x_average = 0; int i; for(i = 0; i sizeof(x)/ sizeof(x[0]); i++) { x_average += x[i]; } x_average /= sizeof(x)/sizeof(x[0]); printf("average of x is %f\n\r", x_average); return 0; } 3つくらいであれば直接書いても大して差はないように思えますが,もし変数の個数が変わったとして前者は変更箇所が多く大変です. しかし後者は配列の定義のみをいじれば後はもう大丈夫です. 配列の何番目にアクセスするかというところに変数を入れられるのが大きな利点ですね. ただし,添え字の番号は0から始まります.配列x[]の先頭はx[0]です. また,宣言時x[n]としたとき要素はx[0], x[1], ... x[n-1]のn個となり,x[n]という要素は存在しません. 配列の添え字を間違えて存在しない要素にアクセスすることは一目に分かりにくいうえ挙動もつかみにくく大変厄介なバクの一つです.
https://w.atwiki.jp/japanese_keyboard_layout/pages/27.html
どなたでも、自由にリンクを追加することが出来ます。 編集しようとする方は、必ず以下をお読み下さい。 【最重要】他者の著作権を侵さないでください。 【重要】「誰でも自由に複写できる」状態を維持するため、主張・意見・見解などの文、及びリンク先内容の本文・要約・解説などは記述しないでください。技術的な理由により閲覧制限・閲覧条件がある場合は、その条件のみを記述してください。 リンクに用いるタイトルは、可能な限り「元のページにあるタイトルタグの中身をそのままコピー」としてください。不適切なタイトルがついている、もしくはタイトルが存在しないなどの場合については、ページ表題などの文字列を採用してください。「誰が」追記しても「結果は」同じ、という状態が理想です。 できる限り、配列制作者・配列使用者かつ配列そのものについて言及している人・資料のそれぞれを分離して記述してください。 各キー配列の発生年月日が解るものは、配列名のあとに年月日を追記してください。 各ドキュメントの初版作成年月日が解るものは、リンクのあとに年月日を追記してください。 …くらいでしょうか？ あとは、実運用してみて決めるしかなさそうです。 これ以降はリンク集となります。 ほかのWiki 飛鳥カナ配列まとめWiki (仮称) より詳細なリンク集 簡易練習法 練習方法 かえで式(50音練習シートPDF) 練習方法 かえで式(50音練習シートOpenDocumentSheet) 入力体験用アプレット＆FLASH 「公式」販促資材 飛鳥カナ配列以外の配列を含めたリンク集 いろいろなカナ入力配列 かなを入力するためのキーボードレイアウト各種 「姫踊子草」の動作概要 - 鍵盤画像 飛鳥カナ配列 飛鳥配列(途上;21世紀290以前) - 【2000年10月30日～2005年1月11日】 推奨運指法 【並行運指法】 飛鳥の開発過程を整理(メモ) 資料 キーボードによるかな入力効率の比較番外編・飛鳥 配列制作者 新親指シフト配列飛鳥のページ 資料 キーボードによる文章入力の容易さ比較のための方法論試案(3) (付論)エクセルファイル解説 教材 親指シフトキー“飛鳥”配列表綴り(PDF、キーボード貼り付けシール用原稿)、予備保管場所 飛鳥配列(安定;21世紀290版) - 【2005年1月12日】 推奨運指法 【並行運指法】 体験用ツール ［jainput］いろんな日本語入力方法をブラウザだけで体験しよう 入力体験用アプレット 飛鳥配列シフト動作研究用アプレット 入力用ツール Windows用親指シフト専用（飛鳥用）キーボード配列エミュレータ“やまぶき” 教材 飛鳥のために(2005年2月6日～) 教材 飛鳥 きりんシステム(2005年4月19日～) 教材 【実験中】あすかのーと(ノート：文系ではない人にも便利な「飛鳥」カナ配列。) 資料 「飛鳥を含む打鍵様子スクリプト」(InternetExplorer推奨) 運指動画 「ノートPC、側面から撮影」 運指動画 「ノートPC、上部から撮影」 入力用ツール 窓使いの憂鬱用定義 窓使いの憂鬱用 シフト残り現象半改善版飛鳥配列［21世紀-290］定義ファイル (109キーボード用) 入力用ツール Windows用親指シフト専用（飛鳥用）キーボード配列エミュレータ“やまぶき” 入力用ツール Windows用キー入力入れ替えソフト「姫踊子草」 教材 親指シフトキー“飛鳥”配列表綴り(PDF、キーボード貼り付けシール用原稿)、予備保管場所 運指動画 Touch typing of Japanese. I use alternative input method. 運指動画 「飛鳥配列でタイプウェル打ってみた動画作ったよ」 飛鳥配列(開発;21世紀290以降) - 【2005年2月18日～2006年04月24日】 推奨運指法 【並行運指法】 ツール Windows用親指シフト専用（飛鳥用）キーボード配列エミュレータ“やまぶき” 配列制作者 飛鳥カナ配列の作者のRayがうだうだ長いのを書く予定のブログ(2005年4月14日～) 腱鞘炎は配列で防げる etc... 右連打が多く左連打が極端に少ない飛鳥 ＪＩＳカナ時代の体験に強く影響されている飛鳥 飛鳥の練習法：マイナーなカナほど集中的に練習すべし！ 両立し得ない配列の覚え易さと打ち易さ かなの連接順位と配列 ＞＞442の51さん 飛鳥330公開 閃くんだから仕方がない。。飛鳥332公開 入力用ツール 窓使いの憂鬱用定義 飛鳥の設定ファイルを2年ぶりに修正しました。 入力用ツール 窓使いの憂鬱用定義 飛鳥21世紀-321配列のテスト繭(104キーボード用) 入力用ツール Windows用親指シフト専用（飛鳥用）キーボード配列エミュレータ“やまぶき” 入力用ツール Windows用キー入力入れ替えソフト「姫踊子草」 練習方法 飛鳥をこうやって練習してみました｜とりあえず月配列とかのブログ 練習方法 飛鳥ある程度覚えました 資料 TRON配列評価 飛鳥配列(完成,開発再開;21世紀333版以降) - 【2006年04月25日～】 推奨運指法 【並行運指法】 配列制作者 飛鳥カナ配列の作者のRayがうだうだ長いのを書く予定のブログ(2005年4月14日～) 飛鳥開発終了＆最終版公開 飛鳥21世紀－334 公開 お年玉没収です！（飛鳥338公開） ７年掛かったブレークスルー！飛鳥339公開飛鳥340正式版公開 教材 親指シフトキー“飛鳥”配列表綴り(PDF、キーボード貼り付けシール用原稿、21世紀-333版対応バージョン) 飛鳥開発完了宣言 （飛鳥123-341公開） 資料 Kinesis Ergo Elan 飛鳥21世紀-333 練習方法 かえで式(50音練習シートPDF) 練習方法 かえで式(50音練習シートOpenDocumentSheet) ■21c333風レフティー。多分。 練習方法 長いのでコメントにしてみる 配列制作者 飛鳥開発完了宣言 （決定版「飛鳥」＆「飛鳥123」公開） 配列制作者 慨嘆。。。 配列制作者 テキスト版配列表など 飛鳥完成！ 飛鳥スレ799にレスしようと思ったら、２ちゃんねるに規制されてしまっていたので 21-341への移行が完了したと思うので 謎がすべて解けた。 「弱い人差指」という表現。 ゴメン＜(_ _)＞。。。飛鳥343公開！ 「でまが」の入れ替えで分かったこと 飛鳥21世紀－356 公開 ジャイロボールと掛けて飛鳥と解く 2 数字データに囚われるな！ 数字データを馬鹿にするなよ！ 羮に懲りて鱠を吹かない飛鳥！