java - ELKI和RapidMiner中LOF实现的结果不同

我已经编写了自己的LOF实现，并且试图将结果与ELKI和RapidMiner中的实现进行比较，但是这3种给出的结果都不一样!我正在尝试找出原因。

我的参考数据集是一维102个真实值，其中有很多重复项。我会尝试将其张贴在下面。

首先，RapidMiner的实现。 LOF分数与ELKI和我的结果有很大的出入。许多返回的LOF为无穷大。此实现是否已被验证为正确？

我的结果与ELKI相似，但是我没有得到完全相同的LOF值。通过快速浏览ELKI源代码中的注释，我认为这可能是由于k邻域的计算方式不同。

在LOF文件中，MinPts参数(在其他地方称为k)指定最小值。 k街区中包含的点数。在ELKI实施中，我认为他们将k邻域定义为恰好是k个点，而不是k个距离或k个不同距离内的所有点。谁能确切确认ELKI如何构建k邻域？还有一个私有变量，它允许将点本身包含在其自己的社区中，但是默认情况下似乎不包括它。

有谁知道附有LOF分数以进行验证的公共参考数据集？

-更多细节如下-

参考:ELKI源代码在这里:

http://elki.dbs.ifi.lmu.de/browser/elki/trunk/src/de/lmu/ifi/dbs/elki/algorithm/outlier/lof/LOF.java

RapidMiner源代码在这里:

http://code.google.com/p/rapidminer-anomalydetection/source/browse/trunk/src/de/dfki/madm/anomalydetection/evaluator/nearest_neighbor_based/LOFEvaluator.java

这是我的测试数据集:

4.32323
5.12595 5.12595 5.12595 5.12595 5.7457 5.7457 5.7457
5.7457 5.7457 5.7457 5.97766 5.97766
6.07352 6.07352 6.12015 6.12015 6.12015 6.44797 6.44797
6.48131 6.48131 6.48131 6.48131 6.48131 6.48131 6.6333
6.6333 6.6333 6.70872 6.70872 6.70872 6.70872 6.70872
6.77579 6.77579 6.77579 6.77579 6.77579 6.77579 6.77579
6.77579 6.77579 6.77579 6.77579 6.77579 6.77579 6.77579
6.77579
7.03654 7.03654 7.03654 7.03654 7.03654 7.03654 7.03654
7.03654 7.03654 7.03654 7.03654 7.03654 7.03654 7.03654
7.03654 7.10361 7.10361 7.10361 7.10361 7.10361 7.10361
7.10361 7.10361 7.15651 7.15651 7.15651 7.15651 7.15651
7.15651 7.15651 7.15651
8.22598 8.22598 8.22598 8.22598 8.5538 8.5538 8.5538
8.5538 8.5538 8.5538 8.5538 8.5538 8.5538 8.5538 8.5538
8.5538 8.5538 8.5538 8.5538 8.5538 8.5538 8.5538

例如，对于第一个数字(4.32323)，我得到以下LOF分数:

RapidMiner:无限(MinPts上下限设置为10,100)

ELKI:2.6774(其中k = 10且distfunction / reachdistfunction设置为默认值)

我的实现:1.9531

有关我的实现方式的更多详细信息:

MinPts是10，所以我找到该点的10个不同的邻居。因此，4.32323的邻域实际上是48点，从5.12595到6.77579。

这使我与k的距离为2.45256

我正在计算第一个邻居的可达距离为1.58277

我正在将样本的LRD计算为1 /(99.9103 / 48)

所有48个邻居的lrd(o)/ lrd(p)的总和是93.748939

除以48得到的LOF为1.9531

最佳答案

实际上，我并不感到惊讶。您还可以添加Weka的LOF实施，您可能还会得到另一个答案。

这是您要添加到方程式中的另一个不同点:据我所知，rapidminer实现会合并具有相同坐标的点。但是也许，他们在计算最近的邻居时忘记了考虑这些权重!

在经典数据库上下文中，您将不会将重复的坐标合并到单个观测值中。它们仍然是有效的数据库记录，应计为完整记录。

我不知道它们中的任何一个是否执行某些自动数据预处理，例如重新缩放数据集。

ELKI实现已通过我们用于教学的许多教科书示例进行了验证。

但是，算法中有一些极端情况并非100％固定，因此即使在算法的“文字”实现中也存在差异的空间。您已经遇到了其中三个:

如何处理重复的点:A)聚合，B)下降，C)考虑不同

从数据挖掘的角度来看，C是正确的，而A(正确实施时)是可以节省不必要的距离计算的优化。 B是常见的数学视图，但对数据库上下文没有太大意义。如果我有两个“John Doe”，他们是同一个人吗？

定义k个最近邻居和k个距离。

k距离的通常定义是:最小距离，因此至少包含k个观测值。当排除查询点时，这将得出从起点开始的最大5.7457的平均值:半径为5.7457-4.32323的其他10个观测值。

通常将k个最近的邻居定义为该距离内的任何点，该点可能大于k。但是，所有其他对象的距离必须与第k个相同!
似乎Rapidminer恰好使用了与LOF出版物不符的k(请参阅LOF出版物中的定义4!)。

实际上，它是k个最近的邻居(包括关系，但不超过k个对象)，不是第k个最小的最小距离。您从哪里得到“与众不同”的？

在LOF使用的kNN集合上，LOF出版物中的定义3和4非常清楚。

因此，您附近的48个对象不正确。

如果存在多个minPts重复点，该怎么办(文字实现将产生除以零的结果，但出于明显的原因，该点的LOF应该设置为1.0)

Rapidminer可能正在发生这种情况。

然后是可达距离:这个距离确实很棘手，因为它不是一个数学距离。它是不对称的。

从第二个观察点到第一个观察点的可达性恰好是第二个观察点的k距离，通过快速查看(未仔细检查)，它是reach-dist(x[0], x[1]) = max(5.97766 - 5.12595, 5.12595 - 4.32323) = 0.80272
有关如何计算LOF的逐步演示，请参见my extensive tutorial slides on outlier detection。据我所知，这是字面的LOF。它并没有涉及所有极端情况，但是它激发了LOF算法的设计，并且非常详尽。