尽管在ubuntu的终点站:
db@morris:~/lisbet/elki-master/elki/target$ elki-cli -algorithm outlier.lof.LOF -dbc.parser ArffParser -dbc.in /home/db/lisbet/AllData/literature/WBC/WBC_withoutdupl_norm_v10_no_ids.arff -lof.k 8 -evaluator outlier.OutlierROCCurve -rocauc.positive yes
给予# ROCAUC: 0.6230046948356808
在ELKI的GUI中:
Running: -verbose -dbc.in /home/db/lisbet/AllData/literature/WBC/WBC_withoutdupl_norm_v10_no_ids.arff -dbc.parser ArffParser -algorithm outlier.lof.LOF -lof.k 8 -evaluator outlier.OutlierROCCurve -rocauc.positive yes
de.lmu.ifi.dbs.elki.datasource.FileBasedDatabaseConnection.parse: 18 ms
de.lmu.ifi.dbs.elki.datasource.FileBasedDatabaseConnection.filter: 0 ms
LOF #1/3: Materializing LOF neighborhoods.
de.lmu.ifi.dbs.elki.index.preprocessed.knn.MaterializeKNNPreprocessor.k: 9
Materializing k nearest neighbors (k=9): 223 [100%]
de.lmu.ifi.dbs.elki.index.preprocessed.knn.MaterializeKNNPreprocessor.precomputation-time: 10 ms
LOF #2/3: Computing LRDs.
LOF #3/3: Computing LOFs.
LOF: complete.
de.lmu.ifi.dbs.elki.algorithm.outlier.lof.LOF.runtime: 39 ms
ROCAUC: **0.6220657276995305**
我不明白为什么2 ROCAUCcurves不一样。
我在测试这方面的目标是对我的结果感到舒服,我所做的是正确的,但是当我没有得到匹配的结果时就很难了。当我看到我的设置是正确的,我将继续做我自己的实验,我可以相信。
发布于 2015-07-23 15:48:34
传递cli
作为第一个命令行参数来启动CLI,或者传递minigui
来启动MiniGUI。以下内容相当于:
java -jar elki/target/elki-0.6.5-SNAPSHOT.jar cli
java -jar elki/target/elki-0.6.5-SNAPSHOT.jar KDDCLIApplication
java -jar elki/target/elki-0.6.5-SNAPSHOT.jar de.lmu.ifi.dbs.elki.application.KDDCLIApplication
这将适用于任何扩展类AbstractApplication
的类。
你也可以:
java -cp elki/target/elki-0.6.5-SNAPSHOT.jar de.lmu.ifi.dbs.elki.application.KDDCLIApplication
(这将减少一个类的加载,但这通常不值得付出努力。)
这将适用于任何具有标准public void main(String[])
方法的类,因为这是标准的Java调用。
但是请注意,-h
目前仍将打印0.6.0 (2014, January)
,该值未对0.6.5中期版本进行更新。对0.7.0
来说,这将是个大问题。因此,该版本号不可靠。
至于您观察到的不同之处:尝试用1来表示k
。如果我没记错的话,我们改变了k参数的含义,使其在不同的算法中更加一致。(无论如何,它们在文学上并不一致。)
https://stackoverflow.com/questions/31589075
复制相似问题