The size of the array is equal to the number of classes (= 22). Passing the array prob_estimates plenty of zeros (array cells are initialized to zero). When WEKA experimenter makes testing, it calls to: public static double svm_predict_probability(svm_model model, svm_node x, double prob_estimates) So if there are classes in the dataset with zero occurrences through all the instances, LibSVM thinks that these classes don't exist whereas WEKA knows they exist.įor example, there is a class in primary tumor dataset that never appears. attributes name and type, set of possible values for nominal attributes), but LibSVM format doesn't. Classes without instancesĪRFF format provides some meta-information (i.e. However, WEKA accuracy results on primary_tumor data were still worse, so there's something wrong when weka uses the svm model at testing step. Then we have obtained the same svm from weka LibSVM than from LibSVM train_svm. We have changed all Math.random() invokations to ranGen.nextdouble(). We made a quick fix adding an static Random attribute to libsvm.svm class: static ranGen = new Random(0) So, I'm afraid some important design changes are required on libsvm.jar and .class to keep such behaviour. WEKA experimenter is based on using always the same random sequences in order to repeat experiments with the same results. Then you can see that ProbA values use to be different. You can use libsvm.svm_save_model to record the svms into files, and then compare the model file from WEKA LibSVM with the model file from libsvm.svm_predict. Obviously, if you call libsvm.svm from, and you call it again from libsvm.svm_train, the results are also different. Libsvm.svm calls Math.random so the model it returns is usually different for the same training set and svm parameters over time. It's left to the reader to incorporate these changes. The authors of LibSVM might have to consider that update. The following changes were not incorporated in WEKA, since it also means modifying the LibSVM Java code, which (I think) is autogenerated from the C code. Issues with libsvm.jar that were discussed on the Weka list in April 2007 (and may no longer be relevant)
In other words, instead of one you have to use four:Ĭ:\some\where then turns into C:\\\\some\\\\where. Note: backslashes have to be escaped, not only once, but twice (they get interpreted by Java twice!). If %CLASSPATH% is listed there, your system has the same problem. You can inspect your current CLASSPATH with which WEKA got started up with the SimpleCLI (see previous bullet point). This can happen where the %CLASSPATH% does not get expanded to its actual value in starting up WEKA.
#Weka jar download windows#
If you're on Windows and you find %CLASSPATH% there, see next bullet point to fix this. If it is listed, check whether the path is correct. Execute the following command in the SimpleCLI:
#Weka jar download full#
Instead use something like this on Linux: java -classpath $CLASSPATH:weka.jar:libsvm.jar
The -jar option overwrites the CLASSPATH, not augments it (a very common trap to fall into). Note: Do NOT start WEKA then with java -jar weka.jar. CLASSPATHĪdd the libsvm.jar from the LibSVM distribution to your CLASSPATH to make it available.
#Weka jar download upgrade#
It is recommended to upgrade to a post-3.5.3 version (or Subversion) for bug-fixes and extensions (contains now the distributionForInstance method). But LibSVM, as a third-party-tool needs to be downloaded separately. The wrapper class is part of WEKA since version 3.5.2. The current version is complete rewrite of the wrapper, using Reflection in order to avoid compilation errors, in case the libsvm.jar is not in the CLASSPATH.įrom WEKA >= 3.7.2 installation and use of LibSVM in WEKA has been simplified by the creation of a LibSVM package that can be installed using either the graphical or command line package manager. The original wrapper, named WLSVM, was developed by Yasser EL-Manzalawy. Wrapper class for the LibSVM library by Chih-Chung Chang and Chih-Jen Lin.
0 kommentar(er)
