「エムブレム」と「エンブレム」を比較するならば，「ブ」ないし「ｂ」の前に置かれ「ブ」ないし「ｂ」と連続して発音される「ム」ないし「ｍ」の音と，同じく「ブ」ないし「ｂ」の前に置かれ「ブ」ないし「ｂ」と連続して発音される「ン」ないし「ｎ」の音とは，これらを発音する場合でも，これらを聞く場合でも，通常の速度で発音される限り，実際上ほぼ同じにしかならないところ，日本語の「紋章」や「標章」に対応する英語として現在一般的に用いられているのは「エンブレム」であり（甲４１５ないし４１７，乙１６８），紋章や標章を意味する普通名詞となっている「エンブレム」と異なり，「エムブレム」は造語的印象を受ける特徴的表記であることは否定できない。
これほど熱く「エムブレム」と「エンブレム」の違いが法廷で語られたことがあっただろうか。
なぜか6巻を買うのを忘れていた。
安くなった。
こんなのあったんだ。
あとがきによると売れてないそうです。「百合」がブームのはずなのに。
安くなった。
すげえ分かりやすい。大きさと重さも手頃でちょっと調べるのにも便利。数式に関しては Google で検索するよりも早い。
「共有地の悲劇」という概念が経済学にはあります。共同で所有されている土地は誰もが利用しようとするけど、誰も維持管理しないので最適な水準よりも過剰に利用され荒廃してしまうという理論です。
同じような「焼肉の悲劇」というものを僕は思いつきました。みんなで焼肉を食べにいった場合、肉を食べるには他の人よりも先に鉄板から肉を取らないといけません。当然他の人も同じように相手よりも先に肉を食べようとします。競争の結果、相手よりも先に食べるためには多少焼けてなくても我慢して肉を食べることになります。
肉は最適な焼け具合よりも前の「生焼け」の状態で食べられることが多くなります。肉という消費財の効率的な消費が妨げられています。これをぼくは「焼肉の悲劇」と呼ぶことにしました。
さてこの「焼肉の悲劇」をどうやったら防ぐことができるでしょうか。ひとつは「共有地の悲劇」を防ぐのと同じように管理人を置く方法です。管理人はみんなに肉を平等に割り当てます。
もうひとつはオークションを行う方法です。ある肉を食べたい人は払ってもいいと思う金額を提示し、一番高い金額を提示した人が肉を食べられるとするのです。そして、食べた人が払ったお金は焼肉の代金の支払に回されます。このようにすれば、肉が生焼けの状態で食べられてしまう「焼肉の悲劇」は防げます。
「共有地の悲劇」は所有権を設定できない(していない)ときに起きる非効率のひとつの形態ですから、供給の多寡というのは本質的ではありません。
例えば焼肉の場合、各自が自腹だったら注文するだろう肉の合計を、最初にあらかじめ注文しておくとします。「焼肉の悲劇」を防ぐことはできるでしょうか。できません。人というのは不思議なもので自腹の時とおごりの時とでは胃袋の大きさが変わる生き物です。ワリカンの時も同じように、自分が払う以上の肉を食べようとみんなが先を争います。結果、肉が生焼けの状態で食べられてしまう「焼肉の悲劇」が生まれます。
では、みんなが食べ切れないくらいの肉を注文すればどうでしょうか。この場合肉が生焼けの状態で食べられてしまうことは防ぐことができます。しかし、 食べ切れないくらい注文した肉の合計は自腹だったら注文するだろう肉の合計を遥かに上回るでしょう。結局、自腹の時以上に払わないといけなくなります。
他人と一緒に焼肉に行くと最適な水準よりもたくさん食べてしまうこの種の非効率を「焼肉の第2の悲劇」と呼びます(今、決めた)。過剰な消費という点において この「焼肉の第2の悲劇」が本来の「共有地の悲劇」と対応します。
クリスマスに双葉理保関連作品を24時間ぶっ続けで遊んでみよう、という企画です。
結構ある。
こんな感じで。
def perm(arry)
return [arry] if arry.size <= 1
ret = []
beg = arry[0]
rest = perm(arry[1..-1])
rest.each{|a|
ret << [beg] + a
a.size.times{|i|
ret << a[0..i] + [beg] + a[i+1..-1]
}
}
return ret
end
p perm( [:a, :b, :c] )
もっと長い配列をちかんしたい場合。
class Permutation
def initialize(ary)
if ary.size <= 1
@buf = [ary]
else
@buf = []
@beg = ary[0]
@rest = Permutation.new(ary[1..-1])
fill_buf()
end
end
def fill_buf
return @buf if @buf.size > 0
if @rest and a = @rest.perm
@buf << [@beg] + a
a.size.times{|i|
@buf << a[0..i] + [@beg] + a[i+1..-1]
}
return @buf
else
return nil
end
end
def perm
ret = @buf.pop
if ret
return ret
else
if fill_buf()
return @buf.pop
else
return nil
end
end
end
end
perm = Permutation.new((1..100).to_a)
6.times{
p perm.perm
}
ふと思いついて Zlib のメモリーリークを直してみようと思った。けど、どうやったらいいか良く分からなかった。ruby の例外は C 言語の longjump で実装されている。C++ と違って C 言語にはスタックを巻き戻す時にデストラクタを実行するような仕組みがないので、人が管理しないといけない。どこら辺で例外が起きたことを検知してメモリを解放するコードを書いたらいいかはコードの全体を把握していないといけない。でもまあ、ext/zlib/zlib.c の全体なんて知るわけないし。
なんで C 言語には GC がないんだろう。
とか思っていたら解決法を思いついた。C 言語で頑張らずに Ruby のコードで書けば良いのだ。
require 'zlib'
module Zlib
class Inflate
def self.inflate(string)
zstream = self.new
buf = zstream.inflate(string)
zstream.finish
zstream.close
buf
end
end
end
こう書いておけばメモリリークは起きない。
ポール・ホフマン著『放浪の天才数学者エルデシュ』、読了。
ブックオフで100円で売られていたのでタイトルだけで買ってみた。トンデモ本かも知れないけど100円なら大した額でもないし。家に帰ってから調べてみたら、
この本は全体として見れば「心理学を批判している」どころか「心理学の知見によって俗流心理学を批判している」という方が正解です。
(中略)
批判の根拠として引用されている実証的研究は心理学者の手になるものが圧倒的に多いのです。この点は今回改めて確認して，よくもまあ調べたなと感心しました。
(中略)
ただ特定のケースで否定されているから全体として価値がないという著者の論法にはまると危険です。
(中略)
このような瑕に目をつぶるならそれなりにためになる本だと思うのですが，思い込みの強い半可通が読むとかえって毒になるかもしれません。Amazonの批評にもひどいのがありますね。
ということでそれなりに良い本らしい。いつか読もう。
『電車男』をパクったアダルトビデオ(痴漢物)が発売される。
Haskell で実装されたブログツールが流行って tDiary ユーザの何人かが乗り換える。
Google が人件費の安い英語圏の国で人を雇って人力検索をはじめる。
「あなたの作っているオープンソースのドキュメントをちゃんと書かないと不幸になります」という内容のチェーンメールが流行る。
久米田先生がマガジンに登場していきなり MIQ をネタにする。
www.amazon.co.jp が大人のおもちゃの販売も開始する。
『ドラえもん』の裏番組の『ポチタマ』に大山のぶ代が飼い猫を連れて出演。
ゲームキューブの後継機のコントローラーはこれ。
ハマったのでメモ。
test/unit は assert_xxx に失敗すると適当な例外を投げる。
また Ruby では「あるスレッドで例外が発生し、そのスレッド内で rescue で捕捉されなかった場合、通常はそのスレッドだけがなにも警告なしに終了され」る(参照)。
上の二つをまとめると、「メインスレッド以外のスレッドで assert_xxx を呼び出してさらにテストに失敗したとしても、そのスレッドが終了するだけでテストに失敗したように見えない」、ということになる。実際以下のような明らかにテストに失敗するはずのスクリプトを実行すると
require "test/unit"
class TestThread < Test::Unit::TestCase
def call_block_in_thread(&block)
Thread.start{ block.call }
end
def test_do_block_in_thread
call_block_in_thread {
assert_equal(0, 1)
}
end
end
結果は以下のようになる。失敗しているようには見えない。
$ ruby test_th.rb Loaded suite test_th Started . Finished in 0.013102 seconds. 1 tests, 1 assertions, 0 failures, 0 errors
このような時はどう対処すべきなんでしょう。どこかですでに議論されているのかな。検索したけど見つかりませんでした。ご存知でしたら教えて下さい。
ちょっと考えてみました。
「スレッド内で assert_xxx に呼ぶ時にユーザがそれなりの注意を払う」。ちょっと大変かも。上のスクリプトの assert_equal(0, 1) がスレッドの中で実行されるかどうかはユーザには分からない。いちいち call_block_in_thread の実装を知らないといけない。
「assert_xxx が実行されているスレッドがメインスレッドでない場合には warning を出す」。取り敢えずユーザがテストが成功していると勘違いすることがなくなる。
「test/unit 側で対処する」。以下のようなことをあらかじめ test/unit がしてくれると嬉しい。けど、まずい場合がでてくるかも知れない。
require "test/unit"
require 'thwait'
class TestThread < Test::Unit::TestCase
def setup
@exs = []
end
def teardown
ths = Thread.list - [Thread.current]
ThreadsWait.all_waits(*ths)
@exs.each{|e|
raise e
}
end
def call_block_in_thread(&block)
Thread.start{ block.call }
end
def assert_equal2(a, b)
if Thread.current == Thread.main
assert_equal(a, b)
else
begin
assert_equal(a, b)
rescue StandardError => ex
@exs << ex
end
end
end
def test_do_block_in_thread
call_block_in_thread {
assert_equal2(0, 1)
}
end
end
このスクリプトを実行すると前と違ってちゃんと失敗しているように見える。
$ ruby test_th.rb
Loaded suite test_th
Started
F
Finished in 0.048713 seconds.
1) Failure:
test_do_block_in_thread(TestThread)
[test_th.rb:27:in `assert_equal2'
test_th.rb:36:in `test_do_block_in_thread'
test_th.rb:35:in `call'
test_th.rb:19:in `call_block_in_thread'
test_th.rb:19:in `start'
test_th.rb:19:in `call_block_in_thread'
test_th.rb:35:in `test_do_block_in_thread']:
<0> expected but was
<1>.
1 tests, 1 assertions, 1 failures, 0 errors
どうなんでしょうか。
『フロイト先生のウソ』をパラパラ眺めてみたけど、どうなんだろう。例えば「本人の性格は遺伝子がある程度決める」ということを双子を使って立証したという研究が肯定的に紹介されている。で、ここで聞きたいのは「〈性格〉の定義はなんですか。どうやって測定するんですか。」ということ。
〈性格〉なんて定義するまでもなく明らかで確固として存在するものだ、というわけではない。
以下は帯広畜産大学心理学研究室の渡邊氏の文章。
仮説１ われわれは自分や他者に一貫性を持った性格の存在を感じている（性格の認知）．
仮説２ 人の行動には個人に特有の持続的なパターン（個性）がある（行動上の性格）
(中略)
ところが，われわれの素朴な認識や従来の性格心理学では，そこに３つめの仮説が加わります．
仮説３ 行動上の性格は，人の内部にある何らかの実体によって規定される（性格の実体論）．
(中略)
この仮説３はわれわれの日常的な性格認知を基盤に持っているのです．したがって，
派生仮説Ａ 性格の認知は，性格の実体や行動上の性格をある程度正確に反映している（正確反映仮説）
そして，
派生仮説Ｂ 状況とは独立の内的要因に規定される以上，行動上の性格は状況を越えた一貫性を持つ（性格関連行動の通状況的一貫性）．
という仮説がそこから派生します．
(中略)
ミシェルの批判は，この仮説３に対して，派生仮説を実証データから検証するという形で挑戦したものです．まず，ミシェルは自分自身が集めたデータから次の事実を発見しました．
事実１ 性格検査は人の実際の行動をほとんど予測できない．
そして自分のデータや他の研究の精査から，その理由を以下のような事実に求めました．
事実２ 性格の認知（たとえば性格検査の結果）は，実際の行動上の性格と一致していない．
事実３ 行動上の性格は環境・状況の影響を大きく受け，通状況的一貫性を示さない．
事実２と３は先の派生仮説ＡＢを直接反証するもので，ミシェルはここから，それまでの性格心理学の基本になっていた仮説３に疑問を突きつけたのです．このことは大変な論争（一貫性論争）を生み出しました．そして，２０年以上の論争の中でも事実１から３を無条件で反証できるような新しい事実は発見されなかったのです．
つまり，われわれが自分の性格認知をもとに信じている「性格を決めるのは内的な何かで，だから性格は状況を越えて一貫している」という仮説３はかなり怪しい，ということです．
そして，行動上の性格，つまり科学的に扱うことができる現実としての性格は内的要因と環境・状況との相互作用（注２）で決定され，内的要因だけから性格を理解することはできないと考えられるようになりました．これが相互作用論です．
ビッグファイブの性格測定といくつかの生理指標，遺伝指標などとの間に相関があることから「ビッグファイブによる性格測定が外的に妥当化される」という主張がある。本当にそうだろうか。ふつう，あることについての測定を外的に妥当化するには，測定対象と明確な関係を持つことが確定している外的基準と，測定値とが相関することが必要である。だとすると，性格測定を妥当化するには，性格と明確な関係を持つことが確定しているなにかと，性格測定の結果とに相関があればよいことになる。ビッグファイブと相関する生理指標が「性格と明確な関係を持つ」ことは証明されていない（ビッグファイブと相関するから性格と関係があるというのはいうまでもなく循環論である）ので，ビッグファイブによる測定値と生理指標との相関は，性格測定としてのビッグファイブを妥当化しない。
実際には，これらのデータからわかるのは，ビッグファイブによる性格測定と，いくつかの生理指標・遺伝指標が「部分的に同じものを測っている」ということだけである。それが「性格の遺伝的基盤」である可能性はもちろんあるが，そうでない可能性もある。
解決した。ユーザが下の例の assert_in_thread みたいなのを用意すれば良い。でも警告は欲しいなあ。気付かずにハマると思う。
require "test/unit"
require 'thread.rb'
class TestThread < Test::Unit::TestCase
def assert_in_thread
if Thread.main == Thread.current
yield
else
Thread.exclusive {
begin
yield
rescue StandardError => ex
Thread.main.raise(ex)
end
}
end
end
def call_block_in_thread(&block)
Thread.start{ block.call }
end
def test_do_block_in_thread
call_block_in_thread {
assert_in_thread do
assert_equal(0, 1)
end
}
end
end
久しぶりに日本橋に行ったらアダルトショップ街になっていた。いやほんと。前から少しはあったけどあそこまで多くなると嬉しくない。日本橋にエロは求めてないと思うんだけどなあ。でも梅田にヨドバシカメラが出来ちゃったし、残る道はエロしかないんだろうか。
テレビ大阪(テレビ東京)の深夜枠みたいなもんか。
「グランドセフトオートIII」が安くなった。
「いまどきBasic認証を使う意義って何?」を読んで、そういえば net/http は Digest 認証に対応していないなあと思った。net/http を Digest 認証に対応させてみた。dig.rb。
使い方は
require 'net/http'
require 'dig'
http = Net::HTTP.new('www.example.com', 80)
http.start{|h|
req = Net::HTTP::Get.new('/digest_auth')
res = h.request(req)
if res.code == '401'
da = req.digest_auth('username', 'passwd', res)
res = h.request(req)
assert da.check_rspauth(res)
end
puts res.body
}
nonce-count をどこでインクリメントするのがスマートなんだろう。
最近のコメント