私はマルチクラスの分類にKDEを使用しています。 scikitを使って実装しています。ウェブサイト上で述べたように 、点xのためのKDEは、異なるクラスのための別のカーネル密度推定値を比較しながら
scikitを使ってカーネル密度推定を正規化する方法は?
は、私は結果を正規化するべきである、と定義されていますか? KDE用
リンク:
http://scikit-learn.org/stable/modules/density.html#kernel-density-estimation
私はマルチクラスの分類にKDEを使用しています。 scikitを使って実装しています。ウェブサイト上で述べたように 、点xのためのKDEは、異なるクラスのための別のカーネル密度推定値を比較しながら
scikitを使ってカーネル密度推定を正規化する方法は?
は、私は結果を正規化するべきである、と定義されていますか? KDE用
リンク:
http://scikit-learn.org/stable/modules/density.html#kernel-density-estimation
平等保持していない、これは明らかに悪い文書の例です。あなたは、あなたがはっきりN
で割るここ
log_density -= np.log(N)
return log_density
のように、それは正規化されているコードで見ることができます。
数学的な観点から正しい式は、実際にはどちらか
1/N SUM_i K(x_i - x)
または
1/(hN) SUM_i K((x_i - x)/h)
あなたも
deeper into .c code実際に計算カーネルを潜ることができますし、彼らは内部的に正規化されていることがわかります
case __pyx_e_7sklearn_9neighbors_9ball_tree_GAUSSIAN_KERNEL:
/* "binary_tree.pxi":475
* cdef ITYPE_t k
* if kernel == GAUSSIAN_KERNEL:
* factor = 0.5 * d * LOG_2PI # <<<<<<<<<<<<<<
* elif kernel == TOPHAT_KERNEL:
* factor = logVn(d)
*/
__pyx_v_factor = ((0.5 * __pyx_v_d) * __pyx_v_7sklearn_9neighbors_9ball_tree_LOG_2PI);
break;
したがって、それぞれK
は実際には1
に統合されています。その結果、KDE全体の有効な密度を得るには平均値をとるだけです。これはまさに内部で起こります。
あなたの答えをありがとう。明確にするために、私は内部で正常化するので、何もする必要はありませんか?私はちょうど異なるKDEを比較することができますか? –
はい、正規化されています。比較の点では、それはあなたがそのような比較によって達成したいものに依存しますが、原理的にはそれは匹敵します。あなたが分類したら、いいえ。分類には事前のクラスも含める必要があります.KDEは生成モデルなので、クラスベースの精度に基づいてクラスサイズに比例した重みを追加する必要があります。これを追加しないと、「バランスの取れた」正確さが得られます – lejlot
KDEは確率密度を推定します - 私が間違っていなければ、密度は定義ごとに正規化されます。数式が正規化されていない理由をよく分からない - 等号が保持されないIMO。 – cel