#1




Question 12
Looks like there's two answers for Q13. It's possible to get different number of support vectors with octave qp and libsvm.

#2




Re: Question 13
Quote:
__________________
Where everyone thinks alike, no one thinks very much 
#3




Re: Question 13
I think it has to do with the fact that qp ( and quadprog in MATLAB) provide alpha values that are negligbly small. By setting an appropriate threshold, it is possible to filter out these very small values.
In Homework 7, one of the students introduced a trick as means to go around the initialization problem in qp (or quadprod). When I applied this trick, qp and libsvm provide different number of SVs. However, when I initialize all alphas to a vector of zeros, libsvm and Octave's qp yield the same number of SVs. Last edited by MLearning; 09132012 at 10:02 AM. Reason: I just checked that qp and libsvm (command line) give the same number of support vectors. 
#4




Re: Question 13
In this problem vectors are placed symmetrically. In qp solution one of them touches the margin with alpha==0.

#5




Re: Question 13
Symmetric in X space, yes. How about in Z space, are they symmetric?

#6




Re: Question 13
This is the only question I got wrong on the final, and I would have got it right if I used my libsvm version of the answer rather than my handbuilt version with qp (all in Octave). My qp (wrong!) answer was one less support vector than I got with libsvm and that might only be because I used 10e012 as a threshhold. (If I had omitted the threshhold I would have gotten the same number of sv's as in libsvm ).
I got w = [0.88889, 5.0e016] and b = 1.6667 using qp, but strangely I get w = [0.88869, 0] and b = 1.6663 using libsvm. They both have Ein=0 and on a thousand test runs of a million random points in [3,3]^2 they agree on labels on average 99.999% of the cases. (For libsvm, I use svmpredict with all labels = +1 which is ~71% accurate to get the actual prediction labels.) The difference in sign may not be significant. I got w and b for qp directly by following the class slides, but I got w = model.SVs'*model.sv_coef and b =  model.rho in the libsvm case (which may not be exactly correct). The values of alpha (for qp) are different from model.sv_coef, and the qp version uses all but the last of the libsvm support vectors. So I do agree that there may be 2 correct answers for this question, based on numerical issues and different ways qp and libsvm handle the calculations, but beyond the control of the student. If required I can PM the alphas and the code I used to support the claim, or wait and post an **answer** after the deadline. 
#7




Re: Question 13
Quote:
__________________
Where everyone thinks alike, no one thinks very much 
#8




Re: Question 13
My experience is the same. My intuition indicated the correct answer from the key, but my experiments using QP with Octave consistently gave an answer of one less than that identified by libsvm (even when comparing against a threshold of zero). After completing the final, I went back and tried some additional experiments and discovered that rearranging the order of the training data changed the number of support vectors.

#9




Re: Question 13
Can you guys do the following: Perturb one of the SV's that are symmetric by a small amount, run your qp programs again, and see if the ambiguity goes away? I will do that myself but I just wanted more people with different packages to try as well. Thank you.
__________________
Where everyone thinks alike, no one thinks very much 
#10




Re: Question 13
Quote:
Code:
w = model.SVs' * model.sv_coef; b = model.rho; if model.Label(1) == 1 w = w; b = b; end 
Thread Tools  
Display Modes  

