That depends a lot on your taste. I personally consider the modular interfaces (python_modular, octave_modular) to be "best". Here best means very flexible and easily extensible. However, in case you just want to train a single SVM with a single or multiple kernels all of the static interfaces are sufficient. And well, of course you should be using python :-)
Either report it in our bug tracker or ask on the mailinglist.
No, as of version 0.7.0 you won't need CPLEX if you want to learn the weights in front of the kernels. However, to enable Multiple Kernel Learning with CPLEX(TM) just make sure CPLEX can be found in the PATH. Note that for standard 1-norm multiple kernel learning (MKL) the GNU Linear Programming Kit (GLPK) version at least 4.29 or CPLEX is required. For general p-norm MKL with p>1 it will work nonetheless.
No, a plain combination of features/kernels will remain a plain concatenation. Only in case you learn the kernel weights you really do MKL. In the static interfaces you can issue:
and check whether all weights W are still 1.0.
Yes! With cygwin 1.7.1 the cmdline, python, python_modular and octave compile cleanly. However, octave_modular won't work since the swig version in cygwin is outdated - if you want that interface you need to compile swig manually. In addition neither R and Matlab interfaces do currently compile: cygwin does not yet include up-to-date mingw packages. As none one of us use windows, and things (in external dependencies) break frequently, feel free to submit patches to cygwin. Ohh, and one hint! To choose the installation directory use:
make DESTDIR= install
As does python, we use reference counting internally, i.e. objects holding a reference to another object should increase the reference count of the object they are referencing and decrease the counter when they finished using the object. It should be noted that loops (e.g., object A holding a reference to object B and vice versa) are not detecting and may thus create memory leaks. However, this scenario can so far be easily avoided - just don't create a combined kernel that contains itself as a subkernel ;-)
The reason for this error is a mismatch between the libstdc++ Matlab ships and the one in your system. Please note that the version of Matlab shown above (r2012a), as well as the system where it is installed (glnxa64, which means linux 64 bits) might differ for you; however this workaround may still help you. We will refer to the version of Matlab and the OS and architecture with MATLAB_VERSION and ARCH below.
Make a backup of the files libstdc++* in MATLAB_DIR/MATLAB_VERSION/bin/ARCH and in MATLAB_DIR/MATLAB_VERSION/sys/os/ARCH. Then, copy or symbolic link the libstdc++ files in /usr/lib/libstdc++* to the two Matlab directories above. You need to restart Matlab after this. Also, it might be necessary to re-compile Shogun against matlab_static and to fix other library dependencies in a similar way in case Matlab keeps on complaining with a similar error.