otsune 氏はどうしても「道義的うんぬん」の話にしたいみたいだけど、atsushieno 氏は最初から「サイバースクワッターの行為が道義的にどうか」などは問題にしていないように僕には読める。atsushieno 氏が根拠にしているのは、ドメイン名紛争処理方針というルールと、それによって保護されるはずの権利だけである。ドメイン管理人の過失が、サイバースクワッターの故意のルール違反をルール上 正当化しない、というのが atsushieno 氏の主張だと僕は理解している。
財布を落したのは ぼんやりしていたその人の過失かも知らんけど、落し主の過失の程度が拾った人のネコババ(占有離脱物横領罪)を法的に正当化する事はない、のと同じ。
ドメイン名紛争処理方針が「法的」と呼ぶにふさわしい重いものなのかは、知識がないので判断できない。
衆院選は自民党の圧勝で終わりました。民主党はどうしてここまで惨敗してしまったのでしょうか。小選挙区制に原因があるとも言われています。小選挙区での得票数と議席は以下のようになります。従来から小選挙区制度では2大政党制になるだとか、なんだとか色々なことがいわれているようですがそれって本当なんでしょうか。
その他にも、一票の格差が結果に影響を与えているかもしれません。民主党は都市部で強くて、一票の格差のために不利であるという説もあります。
Ruby を使って簡単に実験してみましょう。
小選挙区での得票数と議席 | ||
得票数 | 議席 | |
自民 | 32518389 | 219 |
民主 | 24804786 | 52 |
公明 | 981105 | 8 |
共産 | 4937375 | 0 |
社民 | 996007 | 1 |
国民 | 432679 | 2 |
日本 | 137172 | 0 |
無所属 | 3240521 | 18 |
300の選挙区の人口はすべて同じだとします。上の得票をランダムに300の小選挙区に割り振っていき、選挙区毎にトップになった政党がその選挙区の議席を獲得するとします。プログラムを速くて簡単なものにするために、各選挙区の人口を実際の1/100として、政党に投票する確率は独立同分布にしています。
voter = {} voter[:jimin] = 32518389 voter[:minshu] = 24804786 voter[:kome] = 981105 voter[:kyosan] = 4937375 voter[:shamin] = 996007 voter[:kokumin]= 432679 voter[:nippon] = 137172 voter[:mushozk]= 3240521 seats = {} voter.each_key{|k| seats[k] = 0} sum = 0 voter.each_value{|v| sum += v} voter_per_zone = sum / (300 * 100) 300.times{ zone = {} voter.each_key{|k| zone[k] = 0} voter_per_zone.times{ vote = rand(sum) + 1 voter.each{|k, v| if vote <= v zone[k] += 1 break else vote -= v end } } seats[zone.sort{|a, b| a[1] <=> b[1]}[-1][0]] += 1 } seats.each{|k, v| puts "%7s" % k + ": %4d" % v }
さて結果は、実際の選挙結果と似たようなものになるでしょうか。それとも、民主党に有利なものになるでしょうか。少し考えてみて下さい。
結果は以下のようになります。
$ ruby vote.rb jimin: 300 nippon: 0 minshu: 0 mushozk: 0 kome: 0 kyosan: 0 shamin: 0 kokumin: 0
驚くべきことに、自民党がすべての小選挙区で議席を獲得してしまうのです。つまり私たちの単純なモデルは現実をうまく説明できないということです。また、最初の問の立て方も間違っていたことが分かります。私たちは「どうして民主党が惨敗したのか」ではなく、「どうして民主党はこんなにも小選挙区で議席を獲得できたか」を考えないといけません。
しかし、有権者が実際にどのように投票しているかを考えるトイモデルとしてはなかなか悪くないでしょう。得票率を色々変えて遊んでみると良いかもしれません。例えば、小選挙区にランダムに各党の支持者が住んでいるこの単純なモデルでは、得票数がかなり拮抗しないと2大政党制にはならないことが分かります。2大政党制はそんなに簡単には実現しないようです。
このようなことを考えていくのが政治学であると僕は理解しています。
Hash#each は遅いのか。
$ cat h_vs_a.rb require 'benchmark' h = {} n = 1000000 n.times{|i| h[i] = nil } a = Array.new(n) Benchmark.bm{|b| b.report do h.each{|k, v| } end b.report do a.each{|e| } end }
$ ruby -v h_vs_a.rb ruby 1.9.0 (2005-09-09) [i686-linux] user system total real 9.250000 0.030000 9.280000 ( 10.004543) 0.330000 0.000000 0.330000 ( 0.337381)
Hash を Array で書き直し。
voter = [ [:jimin, 32518389], [:minshu, 24804786], [:kome, 981105], [:kyosan, 4937375], [:shamin, 996007], [:kokumin, 432679], [:nippon, 137172], [:mushozk, 3240521], ] seats = {} voter.each{|k| seats[k[0]] = 0} sum = 0 voter.each{|v| sum += v[1]} voter_per_zone = sum / (300*100) 300.times{ zone = {} voter.each{|k| zone[k[0]] = 0} voter_per_zone.times{ vote = rand(sum) + 1 voter.each{|k| if vote <= k[1] zone[k[0]] += 1 break else vote -= k[1] end } } seats[zone.sort{|a, b| a[1] <=> b[1]}[-1][0]] += 1 } seats.each{|k, v| puts "%7s" % k + ": %4d" % v }
$ time ruby -v vote.rb > /dev/null 3.33s user 0.01s system 98% cpu 3.401 total $ time ruby -v vote.rb.old > /dev/null 7.78s user 0.01s system 99% cpu 7.827 total $ time ./miniruby -v ../../vote.rb ruby 1.9.0 (2005-08-19) [i686-linux] YARVCore 0.3.1 (rev: 254) [opts: [direct threaded code] [optimize basic operation] [stack caching] [operands unification] [instructions unification] [inline method cache] ] 1.18s user 0.00s system 81% cpu 1.450 total $ time ./miniruby -v ../../vote.rb.bak ruby 1.9.0 (2005-08-19) [i686-linux] YARVCore 0.3.1 (rev: 254) [opts: [direct threaded code] [optimize basic operation] [stack caching] [operands unification] [instructions unification] [inline method cache] ] 7.34s user 0.00s system 96% cpu 7.577 total
yarv だと違いが顕著だ。
独立同分布じゃないバージョン。
voter = [ [:jimin, 32518389], [:minshu, 24804786], [:kome, 981105], [:kyosan, 4937375], [:shamin, 996007], [:kokumin, 432679], [:nippon, 137172], [:mushozk, 3240521], ] voter.each{|e| e[1] /= 100 } seats = {} voter.each{|e| seats[e[0]] = 0} sum = 0 voter.each{|e| sum += e[1]} voter_per_zone = sum / 300 300.times{ zone = {} voter.each{|e| zone[e[0]] = 0} voter_per_zone.times{ vote = rand(sum) + 1 voter.each{|e| if vote <= e[1] zone[e[0]] += 1 e[1] -= 1 break else vote -= e[1] end } sum -= 1 } seats[zone.sort{|a, b| a[1] <=> b[1]}[-1][0]] += 1 } seats.each{|k, v| puts "%7s" % k + ": %4d" % v }
http://b.hatena.ne.jp/entry/http://www.rengo-soken.or.jp/dio/no197/siten.htm
論文中に用いられている「相対的貧困」の定義を具体的に金額に直すと、税金と社会保険料を引いて残った手取り(可処分所得)が
独り暮らし | 子どもと二人 | 両親と子どもひとり | 両親と子ども二人 |
138万円以下 | 195万円以下 | 239万円以下 | 276万円以下 |
の場合ということになる。P60 参照。論文中で日本の相対的貧困に分類されている人のうち48.5%は51才以上。29.1%が66才以上。
「一人暮らし高齢者」の指標(PDF)
大竹文雄著『日本の不平等』を見る限り、日本の貧困率は1986年から1998年の10年で15%弱から16%強程度になだらかに上昇している。近年、急激に上昇したわけではない。貧困率の国際比較に関して大竹氏の意見を聞いてみたい。国による世帯構造の違いが効いてくる気がするんだけど。
東京都区部等 | 地方郡部等 | |
標準3人世帯(33歳、29歳、4歳) | 162170円 | 125690円 |
高齢者単身世帯(68歳) | 80820円 | 62640円 |
高齢者夫婦世帯(68歳、65歳) | 121940円 | 94500円 |
母子世帯(30歳、9歳、3歳) | 158650円 | 122960円 |
興奮した。
セキュリティモデルは結局〈制限リスト〉でしかない。〈安全性〉の定義は人によっても場合によっても違う。だから、「〈安全性〉を確保できる」と書いた時に、ruby の開発者と Ruby プログラマとの間で〈安全性〉の理解に差ができてしまう。ruby は「制限できる機能のリストを提供しているだけです」というスタンスでいるべきだと思う。
スクリプトを実行する上で機能を制限したい場合がある。system("rm -rf /") を呼べないようにしたいとか。ファイルへの読み書きをして欲しく無いとか。そういう時のために、機能を無効にするスイッチがあれば便利だ。IO.disable、 SAFE[:system].disable とかね。でも、こういったスイッチの粒度が細か過ぎると、機能をオフにし忘れる可能性がある。
そこで、ruby 側が制限したい機能の便利なリストを作って、「$SAFE レベル がこれならこれだけの機能が制限されます。」と保証する。Ruby プログラマはそのリストを眺めて、自分の目的にあっていそうな、$SAFE レベルを選ぶ。ただそれだけ。「80:20 の法則」に従って、機能の制限が必要になるケースの8割をカバーできるような「便利なリスト」を目指す。あとの2割は OS が提供する機能だとか別の手段で頑張ってもらう。「セキュリティモデルが提供する安全性とは何か」を考えるとドツボにハマってしまうと思う。
「ある $SAFE レベルで機能を制限した結果として、どのようなことが不可能になるか」を証明できないなら、保証するべきではない。そして、大抵の場合それは証明できないと思う。
〈制限リスト〉で制限できると言っておきながら、制限できていないならそれは脆弱性があるということになる。ので、上のようにセキュリティモデルをとらえ直したとしても、今回の件は脆弱性があったということになるんだと思う。その深刻度がどれだけかはまた別問題。
一人当たりに直すと平均…。
戦略商品「ウォークマンA」の上下をさかさまにして持つストリンガーたん。持ち直したストリンガーたん。AV Watch より。
3人中2人が間違えている。MYCOM PCより。持ち直したストリンガーたん。INTERNET Watchより。
Jobs が iPod の上下を間違えるところを想像できるかい?ソニーの携帯型オーディオが復活する日は遠そうだ。2ちゃんねるのスレより。
書いてみた。まだ不完全だけど。ruby 1.8.2 以降ではコマンドライン解析には OptionParser を使うことが標準になったけど、リファレンスがあれでは何だろうということで。optparse::チュートリアルにも少し書き足した。
opt.on('-a'){|v| ...}
と on メソッドを呼んだ時点では、ブロックが実行されないことが OptionParser が難しいといわれる原因だろうと思ったので、そこんところを意識して書いた。「non-option argument」を「非オプション引数」と日本語で書いてしまうと何のことかわからないので、「オプションではないコマンドの引数」と長ったらしく書くことにした。
メソッドの名前がなぜ on なのかいまだにわからない。与えられたオプションにコマンドラインで出会った時にブロックを実行するというということで、on なのかな。
最近のコメント