Wikipedia のモニタの項を読む。日本語のもけっこう書いてあるが、英語のはさらに詳しいな。
ちょっとずつ読んでいる Practical API Design であるが、API のドキュメントを楽しんで書く方法が載っていた。
それは、コードを書く前にドキュメントを書くという方法である。
これは意表をつかれた。
理由もいくらか書いてあるが、本当に効くかどうかは分からない。でも、機会があれば (そして機会はたくさんあるはずだが) 試してみよう。
ふと、ffs() の歴史を調べてみた。
とりあえず 4.2BSD にはあって、3BSD にはないようだ。Version 7 にもない。
4.2BSD では src/sys/subr_xxx.c に (VAX 以外の) 実装がある。
#ifndef vax
ffs(mask)
register long mask;
{
register int i;
for(i = 1; i < NSIG; i++) {
if (mask & 1)
return (i);
mask >>= 1;
}
return (0);
}
なら VAX では、というと、src/lib/libc/vax/gen/ffs.s で実装されている。
ENTRY(ffs)
ffs $0,$32,4(ap),r0
bneq 1f
mnegl $1,r0
1:
incl r0
ret
さて、これらから推測できることがある。
前者について、4.2BSD の中での ffs() の用法をみると、たしかにシグナルに使われている。それ以外でも select とかで使っているが。
VAX の命令を調べると、ffs 以外に、ffc もあったようだ。ffs が 1 のビットを探すのに対し、ffc は 0 のビットを探すのだろう。
divmod の div で、0 に向かって丸めるか、-∞に向かって丸めるかは、後者であるべきだと思っている。
これはおそらく、昔、時刻の計算で苦労したからである。時刻は、なんらかの起点 (1970年1月1日午前0時、紀元前4713年1月1日正午、など) からの差で表す。その差を 1日単位あるいは他の単位に丸める、また丸めたときに出た半端を求めることはよくあるのだが、0 に向かって丸めるのは起点に向かって丸めることになる。しかし、起点はとくに意味のある時刻ではないので、それはまず間違いである。-∞に向かって丸めるのが都合がいい。
これを一般化して、間隔尺度の divmod では 0 に向かって丸めることに意味がない、といえないだろうか。
時刻だけでなく、(摂氏や華氏の) 気温の divmod でも、やはりそれは成り立ちそうである。
そう考えると、0 に向かって丸めることにも意味があるものを探すなら比例尺度だろうか?
丸めといえば近いほうに丸める、というものもある。つまり四捨五入である。
値の誤差も考慮して扱うにはこれが都合がいい。
さて、気温を測定するとまず誤差がある。そして、摂氏であれば、間隔尺度である。
では、気温は -∞に向かって丸めるべきか、あるいは、四捨五入すべきか。
考えてみると、丸めたときの余りを捨てるかどうかがポイントだろうか。
捨てないでちゃんと使うなら -∞に向かうのがいいし、捨てるなら四捨五入がいい。
そういえば、温度計の誤差は JIS ではどうなっていたかな... と思って検索すると、JIS B 7411 なのかな。
JIS 本体は確認していないが、最小目盛の±2目盛以内が要求されるらしい?
電圧計 (たしか 1級でフルスケールの 1%) とか、金属製直尺 (たしか 1級でフルスケールの 0.1%) と比べるとなんかゆるい?
実験では最小目盛の 1/10 まで読め、といわれたものだが、温度計でもそうなのだろうか。
Practical API Design をやっと読み終わった。
とても互換性を重視している。もちろんそれは良いことなのだが。
変化しないなら非互換性は発生しないわけで、問題は互換性を保って進化できる API というのがテーマである。
互換性を保った API の進化は、継承とかなり相性が悪くて、かなり制約しないと難しいようだ。まぁ、難しいだろうとは思っていたが、ここまで制約するとは、っていう感じ。
柱状グラフ (ヒストグラム) を描くときは、-∞に向かって丸めて、余りは捨てるのがいいか。
たとえば、wikipedia の「ブラックチェリーの木の高さの度数分布」は 60feet-65feet, 65feet-70feet, ... と分割してそれぞれの度数を示している。
度数を調べるには、個々の木の高さを 5feet で割るわけだが、余りは切り捨てである。そして、切り捨てた余りは使わない。
これは前に考えた「捨てないでちゃんと使うなら -∞に向かうのがいいし、捨てるなら四捨五入がいい」という仮説には反する。
しかし、四捨五入のほうがいいという気もしなくはない。つまり、62.5feet-67.5feet, 67.5feet-72.5feet, ... というように分割するのである。そうすれば、各度数の意味を 65feet くらいの木の数、などと表現できる。62.5feet くらいの木の数、という表現に比べて短いのと、あと、有効数字が変に長いような印象を与えないで済む。
しかし、分割位置に意味がある場合もあるか。BMI だったら 18.5, 25, 30 で分割されていたほうがいいだろう。また、0 で分割されていたほうがいいケースも多いかもしれない。
ヒストグラムをもう少し考えてみる。
100点満点のテストの点数分布をヒストグラムで表現するのはどのような処理になるか。
とりあえず 40点から50点など、10点ごとにまとめるとする。
問題になるのは、区切りの部分、とくに 0点・100点の扱いである。
0点以上10点未満というように、10の倍数な点数を大きい側に入れるとすると、100点は 100点以上110点未満に数えるのだろうか。もしそうしたなら、100点以上110点未満は、101点以上がありえないことからして他の部分とそろっていないのではないか。
あるいは、90点以上を特別扱いして、90点以上100点以下とするか。その特別扱いは適切か。
区切りの部分は両側に半分ずつわけるというのはどうか。60点が n人いたら、50点から60点の部分に n/2、60点から70点の部分に n/2 とわけて数える。しかしそうするなら 0点と100点はどうするか。-10点から0点、100点から110点という部分を考えるか。あるいは、0点と100点は半分にせずに、そのまま 0点から10点、90点から100点の部分に入れるか。
または、5点から15点というように、10点の倍数を各部分の中心にとるか。その場合 0点から5点、95点から100点はどう扱うか。
さて。ある点数がどの部分に入るかは 10で割って余りを切り捨てるわけだが、10の倍数かどうかを調べるのも同時にやるとすると、divmod の出番かもしれない。
[latest]
