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

Java ELKI和RapidMiner中LOF实现的不同结果,java,rapidminer,outliers,elki,Java,Rapidminer,Outliers,Elki,我已经编写了自己的LOF实现,我正在尝试将结果与ELKI和RapidMiner中的实现进行比较,但所有3个都给出了不同的结果!我在想原因 我的参考数据集是一维的,102个真实值,有许多重复项。我会试着把它贴在下面 首先,RapidMiner实现。LOF分数与ELKI和我的结果大不相同;许多人带着无限的爱回来了。此实现是否已验证为正确 我的结果与ELKI相似,但我没有得到完全相同的LOF值。快速浏览一下ELKI源代码中的注释,我认为这可能是因为k-邻域的计算方式不同 在LOF文件中,MinPts参

我已经编写了自己的LOF实现,我正在尝试将结果与ELKI和RapidMiner中的实现进行比较,但所有3个都给出了不同的结果!我在想原因

我的参考数据集是一维的,102个真实值,有许多重复项。我会试着把它贴在下面

首先,RapidMiner实现。LOF分数与ELKI和我的结果大不相同;许多人带着无限的爱回来了。此实现是否已验证为正确

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

在LOF文件中,MinPts参数(在别处称为k)指定了k邻域中要包含的最小点数。在ELKI实现中,我认为他们将k-邻域定义为k个点,而不是k-距离或k-不同距离内的所有点。有人能确切地证实ELKI是如何构建k社区的吗?还有一个私有变量,它允许点本身包含在它自己的邻域中,但默认情况下不包含它

是否有人知道公共参考数据集附带LOF分数用于验证

---更多细节如下---

参考:ELKI源代码如下:

RapidMiner源代码如下:

这是我的测试数据集:

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 8.5538 8.5538

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

  • RapidMiner:infinity(最小值下限/上限设置为10100)
  • ELKI:2.6774(k=10且distfunction/reachdistfunction设置为默认值)
  • 我的实现:1.9531
有关我的实现所做工作的更多详细信息:

  • MinPts是10,所以我找到了点的10个不同的邻域。因此,4.32323的邻域实际上是48点,从5.12595到6.77579
  • 这给了我2.45256的k-distinct距离
  • 我计算第一个邻居的可达距离为1.58277
  • 我计算样本的LRD为1/(99.9103/48)
  • 所有48个邻居的lrd(o)/lrd(p)之和为93.748939
  • 除以48得到1.9531的LOF

  • 事实上,我并不惊讶他们的不同。您还可以添加Weka的LOF实现,您可能会得到另一个答案

    这里还有一个不同点需要添加到等式中:据我所知,rapidminer实现合并具有相同坐标的点。但也许,他们在计算最近邻时忘记了考虑这些权重

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

    我不知道他们中是否有人执行一些自动数据预处理,例如重新缩放数据集

    ELKI的实施已通过我们用于教学的大量教科书示例验证

    然而,该算法中存在一些并非100%固定的角落情况,因此即使在该算法的“文字”实现中也存在差异。您已经遇到以下三种情况:

    如何处理重复点:a)骨料,b)滴,c)考虑不同的

    从数据挖掘的角度来看,C是正确的,a(正确实现时)是一种优化,可以节省不必要的距离计算。B是常见的数学视图,但对于数据库上下文来说意义不大。如果我有两个“约翰·多伊”,他们是同一个人吗

  • k近邻和k距离的定义

    k-距离的通常定义是:最小距离,至少包含k个观测值。当排除查询点时,这将从起始点产生高达5.7457的inverval:在5.7457-4.32323的半径范围内还有10个其他观测值

    k个最近邻通常定义为该距离内的任何点,该距离可能大于k。但是,所有其他对象必须与第k个对象具有相同的距离! 似乎rapidminer使用的是与LOF出版物不一致的k(请参见LOF出版物中的定义4!)

    它实际上是k个最近的邻居(包括领带,但除此之外不超过k个对象),不是第k个最小的不同距离。你是从哪里得到“与众不同”的

    LOF出版物中的定义3和4对于kNN集合LOF的使用非常清楚

    因此,48个对象的邻域是不正确的

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

    这也许就是Rapidminer的遭遇

  • 然后是可达性dis