Thanks for your feedback. I had already considered this issue myself and I disagree with the initial assumption of a future incompatible header file. I think it is likely because there are some interface problems in the current libsvm software. For example from the libsvm FAQ: -- Q: I would like to use my own kernel but find out that there are two subroutines for kernel evaluations: k_function() and kernel_function(). Which one should I modify ?
The reason why we have two functions is as follows: For the RBF kernel exp(-g |xi - xj|^2), if we calculate xi - xj first and then the norm square, there are 3n operations. Thus we consider exp(-g (|xi|^2 - 2dot(xi,xj) +|xj|^2)) and by calculating all |xi|^2 in the beginning, the number of operations is reduced to 2n. This is for the training. For prediction we cannot do this so a regular subroutine using that 3n operations is needed. The easiest way to have your own kernel is to put the same code in these two subroutines by replacing any kernel. -- Since custom kernels are an important part of the current leading edge in SVM research, I think there will need to be an improved custom kernel interface involving function pointers. The issue above might be handled with a simple enhancement, but there are other problems also with the current interface functionality. Therefore I expect a new incomptabile version 3 to come out soon. I still appreciate the problem of the added complexity that you mentioned. For now, the easiest way to avoid changing the source code is to never put the libsvm-2.0 in the .c or .h files (unless version 2 is actually necessary), but only in Makefile's (use -I/usr/include/libsvm-2.0) or use pkg-config. Then it is already included for your convenience and represents something like a configuration system that will naturally allow your code to recompile with version 3 without modifying .c or .h files. If your Makefile uses pkg-config it is likely nothing would need to be modified to use the next version if the interface is as stable as you predict, so the current plan seems to capture the best of both worlds. I appreciate the feedback and look forward to more. On 2/21/07, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote:
Package: libsvm-dev Version: 2.82.0-3 Severity: normal Since I really doubt that there ever would be need to maintain incompatible versions of headers for different versions of libsvm, please correct installation path to svm.h to be simply /usr/include/libsvm/svm.h. Otherwise any code which would make use of libsvm/svm.h would need to adjust their paths whenever new version of libsvm comes out and gets installed under /usr/include/libsvm-3.0/libsvm following used now schema... Please correct me if I am wrong and don't see something crucial in such current setup. Thank you in advance -- System Information: Debian Release: 4.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-generic Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libsvm-dev depends on: ii libsvm2 2.82.0-3 The LIBSVM shared library ii pkg-config 0.21-1 manage compile and link flags for libsvm-dev recommends no packages. -- no debconf information
-- Experiment with Artificial Intelligence at http://complearn.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
