fsck.ext3
で修復.
/proc/cpuinfo
を調べてみると,
cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.40GHz stepping : 7 cpu MHz : 2398.794 cache size : 512 KBほらほらクロック数は 2.4GHz で, ThinkPad は
cpu family : 6 model : 37 model name : Intel(R) Core(TM) i7 CPU L 640 @ 2.13GHz stepping : 5 cpu MHz : 2134.000 cache size : 4096 KB2.1GHz …… うーむ, しかし cache size とかぜんぜんちがうし, やはり Pentium 4 と Core i7 のあいだには, クロック数みたいな単純な数値では説明できない 何か隔絶した CPU 設計の進化があって, 計算速度にこれほどの差が生じてしまったのだろうか?
library(foreach) library(doMC) registerDoMC(cores = 4) # use 4 cores list.bugs <- foreach(job = 1:3) %dopar% { wd <- sprintf("tmp%i", job) # i.e. "tmp1", "tmp2", "tmp3" if (!any(dir() %in% wd)) dir.create(wd) call.bugs( file = "model.bug.txt", n.chains = 1, debug = F, bugs.seed = round(runif(1, -10^6, 10^6)), # random seed working.directory = wd, n.iter = 30000, n.burnin = 5000, n.thin = 50 ) }要点は
bugs.seed
で WinBUGS の「乱数のたね」を
bugs.seed
は当初まったく気づかなくて,
この日の午後は悪夢のごとき bugs
クラスのコード読み地獄にはまりこんでしまった
……
ユーザ システム 経過 123.99 0.40 129.07並列化すると
ユーザ システム 経過 63.287 0.288 69.835 ユーザ システム 経過 74.228 0.212 81.263 ユーザ システム 経過 76.764 0.296 86.264こうだから 124 秒ぐらいかかってたのが 77 秒ぐらいで終了ということ. まあ, これはゐんばぐすの起動とかコードのコンパイルや初期設定に時間とられているんだろう …… などと思っていたんだけど, あとでもっと長い計算で比較してみても, やはり 3 倍ではなく 2 倍 ぐらいの高速化にとどまる (1 core だと 4.5 時間かかるはずの計算, 4 core だと 2.3 時間ぐらいかかった) …… ようで. いろいろおーばーへっどとかあるのかな? まあ 2 倍でもじゅうぶんありがたいけどね.
list.bugs
というところに結果が格納されるんだけど,
これは n.chains = 1
の bugs
3 個の list
になっている.
これではいろいろと不便なので
……
n.chains = 1
な bugs
3 個から,
ひとつの n.chains = 3
な bugs
をねつぞうしてやろうという問題なのだが
……
よくわからなくて,
あちこち走りまわってカベにあたまうちつけてひっくりかえって
(呪われぎみな bugs
オブジェクトの構造は
こちらで解説してます)
……
merge.bugs <- function(list.bugs) { b1 <- list.bugs[[1]] m1 <- b1$sims.matrix mall <- matrix(numeric(0), 0, ncol(m1)) n.chains <- length(list.bugs) for (i in 1:n.chains) { mall <- rbind(mall, list.bugs[[i]]$sims.matrix) } sims.array <- array(mall, dim = c(nrow(m1), n.chains, ncol(m1))) dimnames(sims.array) <- list(NULL, NULL, colnames(m1)) as.bugs.array( sims.array = sims.array, model.file = b1$model.file, program = b1$program, DIC = FALSE, DICOutput = NULL, n.iter = b1$n.iter, n.burnin = b1$n.burnin, n.thin = b1$n.thin ) }ようするに, 各
bugs
オブジェクトから結果を matrix
のカタチでとりだし,
それを (サンプル数, chain 数, パラメーター数)
という 3 次元の array
に整形して,
あとは library(R2WinBUGS)
の as.bugs.array()
に投げてしまうという策.
bugs
おぶぢぇくとに変換すれば plot(bugs)
とかできるでしょう.
list.bugs
内にある 3 つの bugs
オブジェクトを統合して,
ひとつの n.chains = 3
な bugs
がえられる
……
post.bugs <- merge.bugs(list.bugs)
……
なぜだ?
R-hat がぴったり 1 になっている?
bugs.seed
問題で
……
このときは bugs.seed
を指定してなかったんだよね.
そうすると,
(user manual にも書いてないんだけど)
seed が何か特定の値 (たぶん 0 か 1) にセットされてしまう.
そうすると,
n.chains = 1
の MCMC サンプリングを 3 回実施しても,
下の図のように,
完全に同じものしか得られないわけで
……
下の図は,わかりやすくするため,ちょっと上下にずらしてます.
bugs.seed
を設定する.
すると,
このようになる.
n.chains = 1
の MCMC サンプリングのプロセスたちを走らせるときには,
それぞれ異なる bugs.seed
を指定すること.
ホントは初期値も乱数とかで与えて変えるべきなんだけど,
現在の R2WBwrapper.R
ではまだそれはできない
……
初期値のあつかいはだいたいわかってきたので,
そのうちに改造します.
ユーザ システム 経過 6867.62 9.56 6919.35 ユーザ システム 経過 8389.471 2.392 8435.749 ユーザ システム 経過 8408.1 5.4 8463.8ではでは,
post.bugs <- merge.bugs(list.bugs)
してと
……
えーい,
もっと長くサンプリングしないとダメか.