这些是报价形式http://elki.dbs.ifi.lmu.de/ http://elki.dbs.ifi.lmu.de/ :
“本质上，我们将抽象距离查询绑定到数据库，然后对该距离进行最近邻搜索。此时，ELKI 将自动选择最合适的 kNN 查询类。如果我们的距离函数存在合适的索引（不是每个索引都可以加速每个距离！），这里会自动使用它。”
“getKNNForDBID 方法可能归结为缓慢的线性扫描，但是当数据库有适当的索引时，将使用索引查询。然后该算法可以在 O(n k log n) 甚至 O(n k) 时间内运行。”
问题是：ELKI基于什么基础选择运行索引查询或不运行索引查询？
“当数据库有适当的索引时”是什么意思，我如何保证这一点？
关于“run”方法签名的另一个不相关的问题，
为什么有 3 个签名而不是 1 个？它们之间有什么区别，
确定使用哪个签名的标准是什么？
ELKI wiki 中有一个关于此的操作页面：http://elki.dbs.ifi.lmu.de/wiki/HowTo/Index http://elki.dbs.ifi.lmu.de/wiki/HowTo/Index
本质上，您必须使用添加索引-db.index。然后就会自动使用if该索引支持距离度量。 R*-Tree 似乎是最强大的。还有一个关于为自定义距离函数添加 R 树索引支持的教程：http://elki.dbs.ifi.lmu.de/wiki/Tutorial/SpatialDistanceFunctions http://elki.dbs.ifi.lmu.de/wiki/Tutorial/SpatialDistanceFunctions
至于第二个问题：有一个run(Database)中的方法AbstractAlgorithm它使用内省来检查替代方法签名。虽然很乱，但是能够选择其中一个签名实际上很方便。只需确保，您的getInputTypeRestriction()火柴。当您与多个关系一起工作时，这是有意义的。只要你还生活在“一切都是（单个）向量”的思维中，这似乎是多余的；但即便如此，拥有一个也很方便run(Database database, Relation<O> relation)签名already与过程有数据关系。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
