ggpairsパッケージ内はかなり便利なようですが、データセットのどこかにGGally存在すると失敗するようです:NA
#require(GGally)
data(tips, package="reshape")
pm <- ggpairs(tips[,1:3]) #works just fine
#introduce NA
tips[1,1] <- NA
ggpairs(tips[,1:3])
> Error in if (lims[1] > lims[2]) { : missing value where TRUE/FALSE needed
NA値を扱うためのドキュメントは見当たらず、 ggpairs(tips[,1:3], na.rm=TRUE)(当然のことながら) のような解決策はエラー メッセージを変更しません。
おそらく 10% の値がNAデータセット全体にランダムに散らばっているデータ セットがあります。したがってna.omit(myDataSet)、多くのデータが削除されます。これを回避する方法はありますか？
GGally同様の一部の関数は、パラメーターggparcoord()による NA の処理をサポートしていmissing=[exclude,mean,median,min10,random]ます。ただし、ggpairs()残念ながらこの限りではありません。
できることは、NA を、予想していたデータの適切な推定値に置き換えることggpair()です。これは自動的に行われます。それらを行の平均、ゼロ、中央値、さらには最も近い点に置き換えるなどの良い解決策があります（最近の文の単語に4つのハイパーリンクがあることに注意してください！）。
これには刺激が必要だと思うので、私自身の恐ろしい回避策でそれを試してみます. 統計的仮定または選択されたハックに基づいてデータを入力することは探索的分析にとってひどい考えであるというOPに同意します.それは何か他のものです。
免責事項
これはひどいやり方で、私は嫌いです。おそらくOPが持っている高次元データセットのまばらなサンプリングのようなものから来るNAの体系的なソースがある場合に役立ちます。
非常に大きなデータセットの小さなサブセットがあり、一部の列がまばらに表現されているとします。
| Sample (0:350)| Channel(1:118)| Trial(1:10)| Voltage|Class (1:2)| Subject (1:3)|
|---------------:|---------------:|------------:|-----------:|:-----------|--------------:|
| 1| 1| 1| 0.17142245|1 | 1|
| 2| 2| 2| 0.27733185|2 | 2|
| 3| 1| 3| 0.33203066|1 | 3|
| 4| 2| 1| 0.09483775|2 | 1|
| 5| 1| 2| 0.79609409|1 | 2|
| 6| 2| 3| 0.85227987|2 | 3|
| 7| 1| 1| 0.52804960|1 | 1|
| 8| 2| 2| 0.50156096|2 | 2|
| 9| 1| 3| 0.30680522|1 | 3|
| 10| 2| 1| 0.11250801|2 | 1|
require(data.table) # needs the latest rForge version of data.table for dcast
sample.table <- data.table(Sample = seq_len(10), Channel = rep(1:2,length.out=10),
Trial = rep(1:3, length.out=10), Voltage = runif(10),
Class = as.factor(rep(1:2,length.out=10)),
Subject = rep(1:3, length.out=10))
例はばかげていますが、列がより大きなサブセットから均一にサンプリングされているふりをします。
でプロットするすべてのチャネルに沿ってデータをワイド フォーマットにキャストするとしますggpairs。これで、列の範囲がまばらに (そして決して完全に) 表現されないため、標準的なdcastワイド形式に戻すことは、id列またはそれ以外では機能しません。
wide.table <- dcast.data.table(sample.table, Sample ~ Channel,
value.var="Voltage",
drop=TRUE)
> wide.table
Sample 1 2
1: 1 0.1714224 NA
2: 2 NA 0.27733185
3: 3 0.3320307 NA
4: 4 NA 0.09483775
5: 5 0.7960941 NA
6: 6 NA 0.85227987
7: 7 0.5280496 NA
8: 8 NA 0.50156096
9: 9 0.3068052 NA
10: 10 NA 0.11250801
この場合id、おもちゃの例なのでどの列が機能するかは明らかですsample.table[,index:=seq_len(nrow(sample.table)/2)]が ( )、巨大な data.table の小さな均一なサンプルの場合、idデータのすべての穴を通過する一連の値を見つけることは基本的に不可能です。式の引数に適用された場合。このクラッジは機能します：
setkey(sample.table,Class)
順序が固定されていることを確認するために、最後にこれが必要になります。
chan.split <- split(sample.table,sample.table$Channel)
これにより、一意のチャネルごとに data.frames のリストが取得されます。
cut.fringes <- min(sapply(chan.split,function(x) nrow(x)))
chan.dt <- cbind(lapply(chan.split, function(x){
x[1:cut.fringes,]$Voltage}))
各 data.frame の行数が同じであることを確認するためのより良い方法が必要ですが、私のアプリケーションでは、それらが数行だけ異なることを保証できるので、余分な行を削除するだけです。
chan.dt <- as.data.table(matrix(unlist(chan.dt),
ncol = length(unique(sample.table$Channel)),
byrow=TRUE))
これにより、チャネルが列として含まれる big data.table に戻ります。
chan.dt[,Class:=
as.factor(rep(0:1,each=sampling.factor/2*nrow(original.table)/ncol(chan.dt))[1:cut.fringes])]
最後に、カテゴリ変数を再度バインドします。これが一致するように、テーブルは既にカテゴリ別にソートされている必要があります。これは、すべてのデータを含む元のテーブルがあることを前提としています。他にも方法があります。
ggpairs(data=chan.dt,
columns=1:length(unique(sample.table$Channel)), colour="Class",axisLabels="show")
これで、上記でプロット可能になりました。
私が知る限り、これを ggpairs() で回避する方法はありません。また、「偽の」データを入力しないことは絶対に正しいです。ここで提案することが適切である場合は、別のプロット方法を使用することをお勧めします。例えば
cor.data<- cor(data,use="pairwise.complete.obs") #data correlations ignoring pair-wise NA's
chart.Correlation(cor.data) #library(PerformanceAnalytics)
またはここからコードを使用するhttp://hlplab.wordpress.com/2012/03/20/correlation-plot-matrices-using-the-ellipse-library/