2013_0003

2013年のメモ #0003

2013.08.21 Wed

• neriさんはCLEをスタックマシンベースに改造するらしいです。
  • http://nerry.hatenablog.com/entry/2013/08/20/071532

    スタックベースにするとレジスタベースの時より機能密度が上がることが期待できます。

  • これは僕も何度も聞いたことがあります！
  • でもこれってどうなのかな。僕はOSECPUでレジスタマシンでも負けないというか、レジスタマシンのほうがむしろ機能密度が高くなると証明したつもりになっています。
  • スタックマシンだと確かにテンポラリ変数の扱いは有利です。長い式も有利です。でも実際のプログラムは i++; とか a = b + c; 程度の式ばかりで、むしろスタックに積みおろしをするための指示子の分（実質1ビット程度？）のぶんだけ損をしている気がします。
  • しかしまあ結局はやってみないと分からないので、neriさんの結果から目が離せません！

2013.08.24 Sat

• neriさんの検討が面白いです。
  • http://nerry.hatenablog.com/entry/2013/08/24/064220
• 僕だったらスタックマシンの試作を

  |4|   load c
  |4|   load b
  |4|4| add
  |4|4| store a
  =24

• とかにするかなあ。loadは使用頻度が高いので、0～Dで、14レジスタに対応。
  • いくつかは定数ロードにしてもいいかも。
• add はF0とか。
• store a はE0とか。

• しかし3レジスタの16に勝つのは難しい。とはいえ、OSECPUの場合

  |12|4|4|8| add a,b,c

• なので、28だったりする。・・・あれ？

• OSECPUの3項型addが長いのは、2項型を優先しているため。

  |8|4|8| add a,b

• これなら20で済む。

• OSECPUの第三項が8なのは定数を優先しているため。

  |8|4|4| add a,2

• これなら16で済む。

• スタックマシンの場合2項型とかを工夫することはできず、つねに24になる気がする。
• でもloadをひとつつぶしてそれをaddにするなら、addだけは20にできます。でもこれをやりすぎると、短い形式でloadできるものが減ります。
• あとstoreも、load元へ書き戻すという命令を作れば、そしてそれもloadをつぶして実現するなら、2項演算みたいになって、addはついに16になるかも！
• まあload元へ書き戻すのはよくても、add命令を4にするのはやりすぎかなあ。他の演算命令はどうするんだっていう話になるし。だからやっぱり演算子は8のままで。
• ちなみにOSECPUの改善案では、演算子に応じてよく使う定数演算が変わるだろうということで、それを配慮してもっとコンパクトにしようとしています。つまり、文脈が活かせるレジスタマシンはやっぱり機能密度的に有利なんじゃないかと。

2013.08.25 Sun

• http://nerry.hatenablog.com/entry/2013/08/24/150952 を読んで思ったこと。

• CLEはレジスタと変数の区別があるから苦労しているんだなあと思いました。・・・OSECPUみたいに仕様上は全部レジスタにしてしまって、実際のところはJITコンパイラでごまかしてしまえばいいのに。そうすれば、レジスタマシンの3項演算タイプが文句無く最強になって、機能密度追及は存分にできるのに。

2013.09.21 Sat #0

• なんか最近はneriさんブログの感想ばかり書いているけど、でも面白いんだから仕方ない。・・・で、今日もneriさんブログの話題。

• http://nerry.hatenablog.com/entry/2013/08/27/043031 で、ついにneriさんも多レジスタ仕様に向かうことになって、おおお！と期待していたら、
  • neriさんはこの方向が初期の方向と違っていることを少し残念がっていたけど、まあ初期の方針を貫くか（＝実行が速くてシンプルなJITコンパイラが書ける仕様）、機能密度を追及するか、のどちらを取るかということなんだと思う。両立は難しい。
• http://nerry.hatenablog.com/entry/2013/09/11/065826 あたりからARM64への期待が出てきてとっても楽しそう。
• しかもARM64ってレジスタが多いんですね！これはneriさんの新仕様が生きる展開だと思います。

2013.09.21 Sat #1

• 前から考えていたことなんだけど、偏差値とかIQとかって、どうしてあんなふうに表現するのだろうか。必要以上に物事を複雑にしていると僕は感じる。
  • 偏差値60と偏差値70。70のほうがすごいのは誰でも分かる。でもどのくらいすごいんだ？
  • 偏差値70というのは、平均から標準偏差の2倍だけ優れていることを表している。だからそれくらいすごい。じゃあ標準偏差って何？そんなに難しい言葉を使わないとすごさを表現できないの？
• もっと単純にこうしたらどうだろう。
  • 偏差値50、つまり平均と同じくらい優れている場合は、「2人に1人の天才」と表現する。
  • 偏差値60は「6.3人に1人の天才」と表現する。
  • 偏差値70は「44人に1人の天才」と表現する。
  • 偏差値80は「740人に1人の天才」と表現する。
  • 偏差値90は「3.2万人に1人の天才」と表現する。
  • 偏差値100は「500万人に1人の天才」と表現する。
• この表現方法のいいところは、1億人の人がいたとしたら「500万人に1人の天才」というのは何番目くらいの存在なのか容易に分かるということだ。そうとも、20番目くらいだ。この程度の計算なら小学生でもできる。この表現はとても分かりやすい。まあ数字がどんどん大きくなってしまうという弊害があることは認める。でもそれについては後で対策を考えよう。
  • 逆に、「偏差値100」の人が1億人中の何番目くらいの存在なのか、上記の変換表なしで容易に計算できるだろうか。僕はできない。
• 偏差値50未満はどう表現するべきだろうか。簡単だ、こうすればいい。
  • 偏差値40は「1.19人に1人の天才」と表現する。
  • 偏差値30は「1.023人に1人の天才」と表現する。
  • 偏差値20は「1.0014人に1人の天才」と表現する。
  • 偏差値10は「1.000032人に1人の天才」と表現する。
  • 偏差値0は「1.0000002人に1人の天才」と表現する。
• なぜこれでいいのか。偏差値40の例で考えてみよう。
  • 偏差値40というのは、1億人の中では下から数えて1600万番目だということなので、上から数えれば8400万番目ということになる。
  • これを「x人に1人の天才」の形式に合わせると、「1億÷x=8400万」になればよい。
  • これを解けばx=1.19となる。
  • もっと式を整理すれば、(6.3-1)*(1.19-1)=1、(44-1)*(1.023-1)=1などの関係がある。
• この整理した関係式でも分かるように、実はこれらの数字そのものよりも、そこから1を引いた数値のほうにこそ、本質的な意味がある。だからこれらを以下のように言い換えてもいい。
  • 偏差値0は「相対戦闘力0.0000002」と表現する。
  • 偏差値10は「相対戦闘力0.000032」と表現する。
  • 偏差値20は「相対戦闘力0.0014」と表現する。
  • 偏差値30は「相対戦闘力0.023」と表現する。
  • 偏差値40は「相対戦闘力0.19」と表現する。
  • 偏差値50は「相対戦闘力1.0」と表現する。
  • 偏差値60は「相対戦闘力5.3」と表現する。
  • 偏差値70は「相対戦闘力43」と表現する。
  • 偏差値80は「相対戦闘力740」と表現する。
  • 偏差値90は「相対戦闘力3.2万」と表現する。
  • 偏差値100は「相対戦闘力500万」と表現する。
  • 戦闘力というのはマンガのドラゴンボールの用語を真似してみた。相対とついているのは、これは攻撃力やテストの点数などの生な数字ではなく、平均的な戦闘力の持ち主を1とした相対的なものだからである。
• とにかくこの表記なら、その天才がどれほどの順位に相当するのかを簡単に計算できる。しかもすごい人のすごさも分かりやすい。
• さて最後に桁数が大きくなりすぎる問題をどうにかしよう。一般的に言ってこういうときはどうするのかというと対数を取って「指数化」する。
  • 偏差値0は「相対戦闘力指数-6.7」と表現する。
  • 偏差値10は「相対戦闘力指数-4.5」と表現する。
  • 偏差値20は「相対戦闘力指数-2.9」と表現する。
  • 偏差値30は「相対戦闘力指数-1.6」と表現する。
  • 偏差値40は「相対戦闘力指数-0.72」と表現する。
  • 偏差値50は「相対戦闘力指数0.0」と表現する。
  • 偏差値60は「相対戦闘力指数+0.72」と表現する。
  • 偏差値70は「相対戦闘力指数+1.6」と表現する。
  • 偏差値80は「相対戦闘力指数+2.9」と表現する。
  • 偏差値90は「相対戦闘力指数+4.5」と表現する。
  • 偏差値100は「相対戦闘力指数+6.7」と表現する。
  • 対数を取るときには、自然対数にするか常用対数にするかで流派があるのだけど、ここでは元の値を想像しやすいということで、常用対数を採用してみた。だから指数が+2.9だといわれれば、800かそれくらいだろうとすぐ分かる。+4.5なら3万くらいだとすぐ分かる。
  • ちなみに僕は自然対数のほうが好みではある。でも今回は「いかに偏差値やIQなどよりも実感しやすいか」を重視しているので、あえて常用対数を採用した。
• 偏差値のかなりまずいことは、「偏差値というのは100が最高値で、101なんてない」「偏差値-1というのも存在しない」と思っている人が一定数存在することだと思う。
  • これはもちろん誤解で、偏差値が100を超えたりマイナスになったりすることはありうる。
  • 「偏差値というのは、平均点を50点に補正した100点満点テストの点数」という誤解をする人がいるから、こんなことになる。
  • 同様にIQ（DIQ）も必ず0以上になると誤解している人がいるけどそんなことはない。IQ200超えの大天才がいるけれど、それとほぼ同数のIQマイナスの人がいる。
  • 「○○人に1人の天才」という表現なら、何か上限があると誤解することはまずないだろう。まあせいぜいあるとしたら対象人口よりは大きくならないとは思うかもしれない。しかしそれは誤解で対象人口の100倍になることだってありうる、100年に1人の大天才なら。
  • そして下限についても誤解は生じないだろう。1より小さくなることはないように見えるが、その理解は正しい。どんなに成績が悪くとも「○○人に1人の天才」という表現において○○が1未満になることはない。1にもならない。必ず1より大きい。相対戦闘力が0になることもない。
• さて偏差値80というと僕には相当な天才に思えたわけだと、これは実は「740人に1人の天才」でしかない。
  • つまり「偏差値計算の対象になるような人：（大学＋短大＋高専＋専修）進学率が80%くらい」の中から無作為に740人を集めれば、その中の1人は偏差値80以上なのだ。なんだ結構たくさんいるんだなー。もっと少ないと思っていたよ。やっぱり「偏差値80」なんていわないで「740人に1人の天才」とか「相対戦闘力指数+2.9」って言ってほしい。最初からそういってくれたら、誤解しないで済んだはずだ。
  • 偏差値80がその程度なら100も実はたいしたことないのかなーと思ったりすると、今度は痛い目を見る。「500万人に1人」なのだから。偏差値は20しか違わないのに6000倍も違う。うお、これは本当の大天才だ。偏差値は本当に誤解しやすい。
• 偏差値100は「500万人に1人の天才」なのだけど、これは別の言い方をすれば、「5.2年に1人の天才」とも言える。ほら、すごく頭のよい人を表現するときに、「10年に1人の天才」などと表現することがあるだろう。そのまねをしてみた。
  • この表現も同じくらいに分かりやすいと思うけど、「5年に1人の天才」といっても、人口が少ないのなら実はたいしたことはないわけで、普遍性がない。
• 「44人に1人の天才」というのは「44人クラスの中で1位」ということと単純に一致するわけではない。
  • というのは44人クラスで1位をとったとしても、ぎりぎりで取った2位に近い1位なのか、それともぶっちぎりの1位なのかという違いがある。単純な順位ではそれは分からない。だからこそ統計処理をして、平均と標準偏差を算出した上で、「○○人に1人の天才」という言い方で表現する価値がある。
• しかし思い起こしてみると、学校での学力の表現方法って本当に一貫性がないよなあ。
  • 時には10段階評価。時には偏差値。時には学年内順位だったり、全国順位。
  • 10段階評価っていうのは何だろう。つまり誤差が多分に含まれているので、せいぜい10段階でしか表記できないってこと？誤差への配慮は感心するけど、スケールの表示方法は他との統一感がほしい。それぞれの段階が他の表現方法でのどこに相当するのか、対応表なしで分かるだろうか？
  • 偏差値が分かりにくいことはここで散々書いたとおり。しかし偏差値は統計処理をしている分だけ、単純な順位表示よりはましだと思う。同じ1位でもどのくらいの1位なのかが分かりやすい。しかし自分の経験したことのない偏差値については、スケール感というか感覚が全くつかめない。
  • だからみんな相対戦闘力方式にしてしまえばいいのに。誤差は有効数字に配慮しておけばいいだけ。40人や30人のクラスだったら、1桁半くらい書いておけばいいんじゃないかな。
• 偏差値xと相対戦闘力yの関係式：

  y = 2.0 / (1.0 + erf((50.0 - x) * 0.05 * sqrt(2.0))) - 1.0;

• おまけ：
  • こういう試算は読んでいて楽しい： 「イチローは何人に一人の天才か？」http://allabout.co.jp/gm/gc/212410/
    • 「1800万人に1人の天才」・・・やっぱりすごい！

2013.10.18 Fri

• 今日は http://sourceforge.jp/projects/osask/releases/ から 28GO_K_src_0033.tar.gz をダウンロードした。おかげでobj2bim.cが読めた。
  • ありがとうhideyosiさん！
• Livaさんと一緒にOSCの準備を始めましたー。

2013.11.06

• http://d.hatena.ne.jp/r_ikeda/20111204/osjisaku を読んだ。

  「はりぼてOS」のソースコードだが、先に進むと本のサンプルはどんどん汚くなっていく。
  低レベルの（ハードに近い）ソースは汚くなるのは必至なのか。似たようなコードがずっと続いたり、
  やたらネストが深くなったりする。行き当たりばったり感が抜群である。

• まず行き当たりばったり感が抜群というのは正しい。しかし「ソースが汚くなるのは低レベルでは必至」ではない。僕はそう思う。
• ソースが汚くなるのは、本を分かりやすくするためだ。きれいなコードはその気になれば書けるが、そうするとプログラムの構造をその都度変えなければいけない。構造を変えるときには、なぜその構造に変えたのかを説明しなければいけない。そうやっていくと、結局僕がこの本で説明したい「ハードウェアの仕様」や「アルゴリズム」から離れて、このプログラムがなぜこうなったのかという説明ばかりになる。それは僕のしたいことではない。だから僕はそれをやらないことにした。差分が最も小さくなる書き方を追求したらこうなっただけだ。
• 最初から、きれいな構造で書き進めることももちろんできる。しかしそうなると、最初に「なぜこの構造なのか。こんなのわざわざ関数にする必要があるのか？」という疑問が生じて、結局うまくいかない。プログラム構成の説明を後にするか最初にするかの違いでしかない。どういう構成にすべきか的な、そんなものが読みたければ、きれいなプログラムの書き方の文章なんて掃いて捨てるほどあるので、それを読めばいいだろう。僕はありふれたものは書きたくない。
• むしろ僕は、プログラムなんて動けばいいのだ、「動かないきれいなプログラム」は「動く汚いプログラム」と比べてどちらが価値があると思っているんだ、くらいのことを言う人の方が好きだ。たまに「すごく汚いけど、でもちゃんと動くプログラムを書く」人がいる。そしてそういう人のプログラムにケチをつける人ほど、大したプログラムは書けない。できるプログラマは自分ではきれいにコードを書いても、他人のやることにケチは付けない。というか僕はむしろ自分が読めないほど汚いプログラムを書く人を尊敬する傾向がある。だってすごいじゃないか。僕が読めないコードをその人は読めるのだから。
• とはいえ、僕はこのr_ikedaさんが嫌いなわけじゃない。というかいろんなことに挑戦しているから偉いと思う。きっとまだ何を作りたいのか決まっていなくて、でも何かしなきゃいけないと思って、手段ばかり学んでいる段階なんだろうなと思う。目的が決まらないので、手段が決まらない。やる気が空回りしてかわいそうだ。

2013.12.29 Sun

• エネループをお買い物（買い足し）：
  • アマゾンブランドの単3を8本、アマゾンブランドの単4を8本
    • 容量や繰り返し回数は最近の本家のエネループには及ばないけど、このスペックで不満は無いので価格重視でこれを選択。
  • 充電器 K-KJ11MCC40 を購入
    • これは充電器と電池のセット。2,930円だった。充電器の型番は BQ-CC11 。
    • 今まで古い充電器を使っていて、4本充電できるタイプがほしかったので。
    • 待機電力がすごく少ないところが気に入った。他の充電器よりも割高で、しかもその差額を待機電力の差で取り返すのも容易ではないのは分かった上で、それでもこっちが好き。
  • 電池ケース DG-BT5C
    • 他と比べていいと思ったので2つ買ってみた。

• 通貨の2進数化：
  • 僕は2進数が大好きで、通貨も今の10進数ベースをやめて、将来は2進数化されるべきだと思っている。
  • その際、1円玉、2円玉、4円玉、8円玉・・・としていくと、金種計算がややこしいことこの上ない。ということで、1円玉、4円玉、0x10円玉、0x40円玉、0x100円玉・・・と4進数ベースにするのがいいのではないかと思った。
  • ただそれだけの思いつき。

2013.12.30 Mon

• neriさんはCLEにメモリアクセスをつける決心をしたみたいだ。
  • http://nerry.hatenablog.com/entry/2013/12/29/032717
• この方針は正しいと思う。僕もosecpuを作る前からkhabaの設計においてメモリアクセスをずっと悩んでいた。今の形式は「もうこれでいいや」と勢いで実装した。メモリアクセスを作らないとセキュアなことは何もできないので、osecpu化にあたってそれまでで一番マシなアイデアを形にすることにした。
• ということで、やっぱり同じ道を行くんだなあと思った。

こめんと欄