image.plot の目盛を axis 関数で描く

Rのfieldsパッケージのimage.plot関数で目盛に数値ではなくテキストを書き込みたい。axis関数を使っても何故か反映されないというバグ?がある(fieldsのバージョンは6.9.1)。例えば以下の例:

library(fields)

x <- matrix(rnorm(25),nc=5)

colnames <- paste0("col",1:5)
rownames <- paste0("raw",1:5)

# Fail
image.plot(1:5, 1:5, x, xaxt="n", yaxt="n", xlab="X-axis", ylab="Y-axis")
axis(side=2,at=1:5,labels=rownames)
axis(side=1,at=1:5,labels=colnames)

image_plot_fail

確かに最後の二行の axis 関数の結果が反映されていない(x軸, y軸の目盛に文字が書けていない)。

r- how to edit elements on x axis in image.plot
この問題はここでも議論されていて、普通のimageを使って、凡例だけimage.plotを使え、とある。

もう少し簡単に解決する方法を見つけた。

# Success
image.plot(1:5, 1:5, x, xaxt="n", yaxt="n", xlab="X-axis", ylab="Y-axis")
text(-100,-100,".")  # This is dummy, but required for drawing axis
axis(side=2,at=1:5,labels=rownames)
axis(side=1,at=1:5,labels=colnames)

image.plot と axis の間にダミーでtext関数を実行する(三行目)。以下のとおり不思議なことにこれで解決した(理由は未調査)。

image_plot_success

重点サンプリング (2)

前回は正規分布の裾の積分をなんとなく決めた提案分布による重点サンプリングで求めた。今回は提案分布の違いがどのような誤差の違いを生むのかについて実験した。ただし、今回の積分範囲は [4,∞) とした。ようするに \(f\) を標準正規分布のpdfとして

\begin{align}
\int_4^\infty f(x)dx
\end{align}

を求める問題。
“重点サンプリング (2)”の続きを読む

モデル選択の実験 (AIC vs AICc / R の AICcmodavg パッケージ)

前回の「モデル選択の実験 (AIC vs LOOCV)」の続きです。

小標本の場合は、AIC じゃなくて AICc を使うといいよとのことなので、今回は、前回同様の方法で AIC と AICc を比較してみた。

真のモデルやその他のモデルの設定などは前回と全く同様。図の見方も前回と同様です。LOOCV の結果も並べてみたかったが計算量の関係で断念。

いろんな意味で手抜き気味です。あしからず。

AICc

「正規ノイズの線形モデル」のケースでは以下で定義される情報量基準。

\begin{align}
AICc = AIC + \frac{2k(k+1)}{n-k-1}
\end{align}
k : パラメータ数、n : データ数。

GLM のケースではこの定式化は使えないらしい[1]。 そんなこんなで GLM の場合は R の AICcmodavg パッケージをつかう。

glm.fit <- glm(...)
AICc(glm.fit)

とすることで AICc の値を良きに計らって計算してくれる。
“モデル選択の実験 (AIC vs AICc / R の AICcmodavg パッケージ)”の続きを読む

  1. [1] でも実は間違えてこの定式化でやってみたけどそれなりに良い結果 (AIC よりもよい結果) が得られた。

モデル選択の実験 (AIC vs LOOCV)

最近読んだ「データ解析のための統計モデリング入門――一般化線形モデル・階層ベイズモデル・MCMC (→ amazon)」に感化されて、モデル選択基準である、AIC、LOOCV (Leave One-Out Cross Validation) について実験してみた(参考:モデル選択の周辺の話の整理)。

LOOCV と AIC はある意味で両極端だ。LOOCV は利用するのに必要な仮定が少なく、直感的にも何をやっているのかわかりやすい(ただし計算量は非常に大きい)。一方で AIC は評価式の簡単さ(計算量の少なさ)とは裏腹に、背後には正則条件だとかネストだとかの直感的とは言いがたい仮定をしたりする。

まあ AIC とか LOOCV とかが常に正しいモデルを選択するわけじゃない、というのは直感的にはわかるけど、実際に試してみたことはなかったので、真のモデルを知っているという神の視点からみて、こいつらがどんな挙動を示すのかをシミュレーションで確かめてみた。

“モデル選択の実験 (AIC vs LOOCV)”の続きを読む

[R] データフレームを可視化するtabplotパッケージについて

データの列数が多くなってくる (高次元になってくる) とデータの全体像が捉えにくくなる.R-bloggers を読んでたら,Rのデータフレームを可視化するためのパッケージ tabplot なんてのがあるらしい,ということで試してみた.コレを使うとデータを効率的に可視化できるので,よくわからないデータをとりあえず可視化してみて,それからあれこれ考えてみると捗るかもしれない.

CRAN から tabplot パッケージをインストールすればすぐに使える (類似の名前で tableplot なんてのがあるので注意).
“[R] データフレームを可視化するtabplotパッケージについて”の続きを読む

Rで階段プロットを書く

知らなかったのでメモ。Rで階段プロットを書くには type=”s” を指定する。

以下は経験累積分布関数を書くためのコード片。

cumplot <- function(x,...){
  plot(sort(x),(1:length(x))/length(x),type="s",...)
}

cumplot(rnorm(100),xlab="",ylab="",xlim=c(-3,3))
curve(pnorm,add=T,col=2)
legend("topleft",legend=c("empirical CDF","normal CDF"),
       lt=1,col=1:2)

こんな図が書ける。

ほかにも type=”S” (大文字) なんてのがあって、だいたい同じなんだけど、S は上にずれる。経験累積分布の場合は小文字 s が正解。

CRPのテーブルの数の分布

Chinese Restaurant Process (→ 以前の記事) でデータ数(レストランに来る人数/壺からボールを取り出す回数)や \(\alpha\) が変化した時に利用されるテーブルの数の分布がどうなるか実験してみた(下の図をクリックで拡大)。


“CRPのテーブルの数の分布”の続きを読む

Rにおける値渡しと参照渡し (2)

昨日の記事を書いたあと、twitter で tracemem 使うといいよ、と教えていただきました (@sfchaosさん、ありがとうございました!)。

この関数ははじめて知ったのですが、ヘルプを見て意訳すると以下の様な感じです。

tracemem(x) を実行すると x について duplicate (複製)が生じた時にメッセージを表示する。これは2つのオブジェクトがメモリを共有している場合において、1つが変更された時に生じる。ちなみに untracemem(x) でメッセージフックを解除できる。

ということで関数の内部でコピーが起きたか、を判別するのにピッタリです。

今回の内容:

  • tracemem を使って値渡し、参照渡しを確かめる
  • 参照渡しなのか、値渡しなのか、が確定するタイミングについて考える

tracemem を使った方法

以下の方法は @sfchaos さんに教えてもらった方法そのままです。前回同様、prod1 は行列 A について値渡しになりそうな関数で、prod2 は参照渡しになりそうな関数です。

prod1 <- function(A,x){
  A <- A + diag(x)
  A %*% x
}

prod2 <- function(A,x){
  A %*% x
}

N <- 1000
A <- matrix(rnorm(N*N),nc=N)
x <- rnorm(N)

tracemem(A)
# => [1] "<0x7e790008>"
invisible(prod1(A,x))  # invisible は結果を print しないようにする関数
# => tracemem[0x7e790008 -> 0x7dfe0008]: prod1  # コピーが発生した!

invisible(prod2(A,x))
# => 何も表示されない!=コピーが生じていない!

ということで、前回は実行時間から推論しただけでしたが、やはり引数を変更するとコピーが生じる、ということで間違いないことが確認できました。

複製はどのタイミングで生じるのか?

前回、以下のように書きました。

そして、引数が変更されるかされないかはパースした段階でわかる(なのでパースの段階で値渡しか参照渡しかを判別することが可能)

ですが、これは誤りでした。実際、以下のような関数はパースの段階で値渡しか参照渡しかを判別できるでしょうか?

prod3 <- function(A,x,add=T){
  if(add) A <- A + diag(x)
  A %*% x
}

add が真のときは引数が変更されて、偽のときは引数が変更されません。

これをパースの時点で判別しようとすると、Rの副作用を作らないという原則から add がいかなる値であろうともコピーを行うことになるはずです。

もう一つの可能性としては、実際に変更が起きたその瞬間にコピーを作る、というものがありえるでしょう。

実験してみます。

N <- 1000
A <- matrix(rnorm(N*N),nc=N)
x <- rnorm(N)

tracemem(A)
# => [1] "<0x7dfe0008>"

invisible(prod3(A,x,add=T))
# => tracemem[0x7dfe0008 -> 0x7ef40008]: prod3

invisible(prod3(A,x,add=F))
# => 何も表示されない!=コピーが生じていない!

同じ関数でも引数の状態によってコピーが発生したり、しなかったり。add=F のときは prod3 の if の内部まで進まないため、A が変更されず、したがってコピーが発動しない、ということになります。

つまりRは

  • 引数のコピーを作るか(値渡しか)、作らないか(参照渡しか)は実際に引数が変更される瞬間ギリギリまで判別しない、
  • 変更される瞬間(直前?)で重い腰を上げてコピーを作成する(遅延評価)

という挙動をしているようですね。

まとめ

  • Rは基本的には値渡しであり、C++のように引数として与えられた変数を変更することで外側の世界に影響させることはできない
  • 関数内部で引数を変更しない場合は、コピーが生じない (C++ の const& のようなイメージ)
  • 関数内部に引数を変更するコードがあったとしても、実際に引数が変更される段まではコピーは生じない (遅延評価)

Rにおける値渡しと参照渡し

Rの関数に引数を渡すと値渡しになる、とずっと信じていたわけだけど、どうも違うらしい。Rはどうやら「自動的に」値渡しすべきか、参照渡しにすべきか、を判断しているようだ。

C++みたいな言語では「フツーに」引数を渡すと全部値渡しになって(特に行列のような巨大なオブジェクトを渡す場合には)効率が悪いので、ポインタや参照で渡したり、副作用を気にする場合は const 参照で渡したりする。

さて、上で述べた R の自動判断機能は以下のような事実に基づくようだ。

  • そもそも値渡しは関数に引数を渡した段階でオブジェクトのコピーを生成して「引数として渡された変数を関数の内部で変更してもスコープの外では値が変更されない」ことを保証するのだが、
  • オブジェクトが関数の内部で変更されないことが保証されるならば「関数の実行中はスコープの外でも値が変更されない」ことは保証されるのでコピーをそもそも生成する必要がない、
  • そして、引数が変更されるかされないかはパースした段階でわかる(なのでパースの段階で値渡しか参照渡しかを判別することが可能) → 間違いでした。詳細はRにおける値渡しと参照渡し(2)に書きました。

実験

これは以下のようにして確かめることができる、はず。

prod1 <- function(A,x){
  A[1,1] <- A[1,1] + 1
  A %*% x
}

prod2 <- function(A,x){
  x[1] <- x[1] + 1
  A %*% x
}
  • prod1, prod2 はともに引数として渡された行列 A とベクトル x の積を計算する
  • prod1 では A[1,1] に 1 を加える
  • prod2 では x[1] に 1 を加える(これはprod1の代入作業のコストと揃えるため)
  • その後、積を計算する

ということをやっているのだが、上で述べたようなことがただしければ、

  • prod1 では行列 A のコピーが発生し
  • prod2 ではベクトル x のコピーが発生する

ため、より巨大なオブジェクトを渡すことになる prod1 が (生じる四則演算の数は同一にもかかわらず) 大幅に遅くなることが予測される。

実際、1000 x 1000 程度の行列を考えると以下の様な結果が得られる。


N <- 1000
A <- matrix(rnorm(N*N),nc=N)
x <- rnorm(N)

system.time( for(i in 1:1000) prod1(A,x) )
# =>   user  system elapsed
# =>  11.03    3.50   14.56

system.time( for(i in 1:1000) prod2(A,x) )
# =>  user  system elapsed
# =>  4.59    0.01    4.62

prod1のほうがかなり遅くなっていることが分かる。これより、上で述べたことはおそらく正しいだろうと結論される。

まとめ

このことを知ったからといって高速なプログラムが書けるようになるわけではないが、少なくとも「こんな大きなオブジェクトを関数に渡すのは気が引ける(なのでグローバル変数にしてしまえ)」という不安を払拭することができると思う。

【追記】続きを書きました。