15:39 < Anand> Marcus : I made the merge. See if the changes are reflected

15:42 < Anand> Marcus : Do we not have the code for all methods in shogun? I see only kmeans.cpp

15:53 < Anand> The m_label_prob.vector[i] gives the probability for class 'i' , I suppose but where is this vector set? Where do the values come from?

17:27 < marcus_zoq> Anand: Generally we use the python bindings to run the shogun method, but to set initial centroids we had to modify the C++ code. Thats the reason for the kmeans.cpp code.

17:31 < Anand> Marcus : Yeah I got that. We will need the code for Gaussian Naive bayes though

17:31 < Anand> Right?

17:32 < Anand> And currently you use the apply(..) method in nbc. Form there we can get the predicted labels

17:33 < Anand> To get the probabilities we will need the m_label_prob vector. I cannot figure out how does this vector get its values from. We need to get that method and then we can have the probabilities

17:36 < andrewmw94> naywhayare: In the R-Tree, the non-leaf nodes will not store any points. However, I made the dataset a reference instead of a pointer to match the dataset in the BSP tree, which means I can't set it to null or reassign it etc. Am I correct in assuming that there are tree abstractions that make it important to have this match the BSP trees?

17:39 < oldbeardo> marcus_zoq: hey, I just pushed a blog post, and like last time I cannot see it

17:40 < marcus_zoq> Anand: Okay I will look into the code.

17:45 < marcus_zoq> oldbeardo: You've done everything right. Sometimes the webhook don't react immediately after a new commit. Btw. now there is a new blog post :)

17:46 < oldbeardo> marcus_zoq: okay, thanks. I thought I had made some mistake again

17:52 < naywhayare> andrewmw94: no, what's held internally is not a problem. Only the public methods must act the same

17:53 < naywhayare> so you can use a pointer -- or a matrix itself -- so that each leaf node can hold whatever points

17:53 < andrewmw94> ahh. That's good.

17:53 < andrewmw94> thanks

17:59 < naywhayare> I may be losing service soon... any other questions?

17:59 < naywhayare> currently at the New Mexico / Arizona border

17:59 < naywhayare> lots of nothing ahead... lots of nothing behind

18:02 < andrewmw94> no more at the moment. I'm starting to realize I did a lot of things very wrong

18:05 < naywhayare> isn't that always the case :-)

18:05 < naywhayare> if you get hung up on something, as always, feel free to ask

18:19 < udit_s> marcus_zoq: hey, I'm having a few problems with the perceptron - could have a look at the code ?

18:20 < udit_s> naywhayare: you too ?

18:21 < udit_s> I've pushed the code on my repo, and have provided the tests for AND, OR and an arbitrary linearly separable testcase.

18:21 < udit_s> The perceptron seems to be working for OR perfectly, and not so for the other tow.

18:21 < udit_s> *two.

18:26 < marcus_zoq> udit_s: Sure I'll look into the code tonight, if this is okay for you?

18:27 < udit_s> okay. I've been stuck on this for almost half a day - I'd gotten this coded and set up yesterday; been trying out these test cases for a while now.

18:31 < udit_s> marcus: also, the paper you shared says that for the pocket algorithm with ratchet check, " the number

18:31 < udit_s> of trials required to produce an optimal weight vector is prohibitively large (Gallant, 1990)."

18:33 < udit_s> and further goes on to talk about the majority vote and the averaged perceptron being almost identical and less cheaper than pocket with rachet.

18:34 < marcus_zoq> udit_s: Yeah, the algorithm is probably not the way to go.

18:36 < udit_s> Right now, I've just used the normal RosenBlatt update rule, w = w + x for the correct class and w = w -x for the incorrect class predictions.