*Dr.Webトラブルの原因は、/var/drweb/bases/以下の drw7*****など「7万番台」のファイル 及び 2011年12月15日21:30更新の /var/drweb/bases/update.drl というファイルとされています。 Dr.Webバージョンは5.XXです。その他あれこれと教えていただいたので， Dr.Web サイトから新しい dll だのパターンファイルだのダウンロードして， さーばー内で展開 ……
... Loading /var/drweb/bases/dwn50002.vdb - Ok, virus records: 2715 Loading /var/drweb/bases/dwn50001.vdb - Ok, virus records: 2545 Loading /var/drweb/bases/dwn50000.vdb - Ok, virus records: 2801 Loading /var/drweb/bases/drwrisky.vdb - Ok, virus records: 6197 Loading /var/drweb/bases/drwnasty.vdb - Ok, virus records: 28348 Total virus records: 3052733 Key file: /opt/drweb/drweb32.key - loaded. License key number: 0011656835 License key activates: 2011-12-08 License key expires: 2013-01-31 License for Internet gateways: None License for file-servers: Unlimited License for mail-servers: Unlimited Daemon is installed, active interfaces: /var/drweb/run/.daemon 127.0.0.1:3000
/etc/init.d/drwebd restart
editorialmanager.com
なるサイト
(ここか?)
からのメイルは spam あつかいされてるなぁ
……
対応して返信．
久保です．調べてみたところ，editorialmanager.com が毎回毎回 送り元を変更しているために，不正な迷惑メイルと自動判定され ていたことがわかりました．とりあえず edittorialmanager.com からきたメイルは無条件に通過させるように設定しました．つまり whitelist に追加したということで．
editorialmanager.com のメイルが spam 認定されてしまったかもしれないってことだよね．
beta[2])
と高密度化 (beta[4]) に重要とゆーことに．
このデータから，
こういう「いかにも個体群生態学」みたいなコトが言えたら，
なかなか良いと思うんだけど．
dbin(prob, sample.number)
は prob がマイナスの値になっていても，
かまわず計算してくれるとわかった!
修正修正．
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)
してと
……
えーい，
もっと長くサンプリングしないとダメか．
/etc/initd
を再起動してみた
……
と記録しておく．