Open in new window / Try shogun cloud
--- Log opened Sun Jan 19 00:00:58 2014
-!- iglesiasg [] has quit [Quit: Leaving]00:52
-!- sonne|osx_ [] has joined #shogun03:32
-!- sonne|osx [] has quit [Ping timeout: 260 seconds]03:33
-!- sonne|osx_ is now known as sonne|osx03:33
shogun-buildbotbuild #685 of nightly_default is complete: Failure [failed test]  Build details are at
-!- parijat [671b082a@gateway/web/freenode/ip.] has joined #shogun12:17
parijatHi, is there a way to multiply a scalar with a vector (or matrix) without having to iterate over its elements?12:26
-!- iglesiasg [] has joined #shogun13:02
-!- mode/#shogun [+o iglesiasg] by ChanServ13:02
@iglesiasgsonney2k, ping13:35
parijat@iglesiasg: hello13:36
@iglesiasgparijat, hey13:36
parijatiglesiasg, regarding KMeans interface, I think the 2nd option suggested by you is better13:37
@iglesiasgparijat, all right13:38
parijatiglesiasg, user can then possibly switch between implementations13:38
@iglesiasgparijat, yep, indeed13:38
@iglesiasgparijat, be sure to test that works once it is done then13:38
@iglesiasgparijat, this is, in the same example, first train with one kmeans method, then with another, etc13:39
@iglesiasgwith the same KMeans instance13:39
parijatiglesiasg, is it possible to implement it in a modular fashion?13:39
@iglesiasgparijat, can you elaborate?13:39
@iglesiasgdo you mean to have the general KMeans class which is the interface13:40
@iglesiasgthen the other classes with the implementations for each KMeans method?13:40
parijatiglesiasg, I meant keeping separate classes for each implementation of kmeans but showing to user just one class. how can I do it?13:41
@iglesiasgparijat, yes, sure it is possible13:42
@iglesiasgparijat, I would have a KMeans class that has (among possibly other attributes) one enum attribute to select the KMeans method to use13:42
@iglesiasgthen the train in this class would basically have a switch statement13:43
@iglesiasgthat depending on the value of this attribute, basically the train method implemented in one of the other classes13:43
@iglesiasgbasically calls* (missed that verb :)13:44
@iglesiasgand then the idea would be that these other classes need not to be visible from target interfaces (e.g. python_modular, etc)13:45
@iglesiasgso in KMeans.cpp you include KMeansElkanImpl.h, KMeansMiniBatchImpl.h, etc13:46
@iglesiasgparijat, does that make sense to you?13:46
parijatiglesiasg, yup13:46
@iglesiasgit is probably not the only way to do this..13:46
@sonney2kiglesiasg, what did you not understand with git bisect?13:47
@sonney2kiglesiasg, and hey pong :)13:47
parijatiglesiasg, so basically its 3 (possibly more) to one kind of inheritance structure?13:47
@iglesiasgsonney2k, I think I understood it13:48
@iglesiasgsonney2k, the thing is that I don't know yet when the tests were actually in good state13:48
@iglesiasgsonney2k, I just realized that when I am currently going to a past commit and running the tester, that is comparing with the current version of the data file13:49
@sonney2kiglesiasg, I thought you did?13:49
@iglesiasgsonney2k, nope13:49
@iglesiasgsonney2k, do you see the problem I mean with the data file used in the integration test?13:50
@iglesiasgbecause as I see it right now, this makes a huuuuge pain13:51
@sonney2kiglesiasg, no - I don't get it13:52
@iglesiasgsonney2k, integration tests used files in shogun/data/testsuite/tests, right?13:52
@iglesiasgsonney2k, which are tracked in the data repository13:53
@sonney2kyes and?13:53
@iglesiasgsonney2k, if one the files in the testsuite has several versions13:53
@iglesiasgsonney2k, then say I go back in shogun repository to a past version, and run the tester13:54
@iglesiasgsonney2k, it might not use the file it should be using for that revision!13:54
@sonney2kiglesiasg, well just git submodule update13:55
@sonney2kand done13:55
@iglesiasgaham, that is indeed more practical than checking by hand what is the corresponding data version13:55
@sonney2kiglesiasg, so could you continue trying to figure this out?13:56
@sonney2kiglesiasg, I mean you could find out if mmd still works using the buildbot / some build where it actually worked13:57
@iglesiasgsonney2k, I continue trying yes13:58
@iglesiasgI was using my machine but it is true that the process would be faster in the buildbot13:58
@iglesiasgsonney2k, can you remind me how do I ssh to it? :)13:58
@iglesiasgI will write it down this time13:59
@sonney2kiglesiasg, ssh fatbot.*13:59
@sonney2kiglesiasg, but I meant the logs - because there is one where it still works I am sure :)13:59
@iglesiasgsonney2k, according to the logs, as we discussed the other day, it is in 2069 where it worked and in 2070 where it started failing14:00
@iglesiasgbut this makes no sense14:00
@iglesiasgsince they are the same revision14:00
@sonney2kiglesiasg, well checkout some version before 2069 - compile and test locally14:01
@sonney2kiglesiasg, if it works start the bisect with good14:01
@iglesiasgsonney2k, I checked out 2069, compiled and tested locally14:01
@sonney2kand find some version after 2070 that fails14:01
@iglesiasgwhen I realized about the data file issue14:01
@iglesiasgso right now I am checking if statistics_linear_time_mmd actually has more than version14:01
@iglesiasgthe data file14:01
@sonney2kiglesiasg, well keep trying...14:02
@iglesiasgit indeed has more than one version14:03
@iglesiasglet me check now that git submodule update goes back to the right onw14:03
@sonney2kiglesiasg, I am still messing with the bmrm serialization issue - no idea still. When serializing the MCSOLabels these are ok - but not what comes out of *BMRM.apply()14:03
@iglesiasgaham! I see14:03
@iglesiasgsonney2k, maybe they are internally created as StructuredLabels instead of MulticlassSO?14:04
@sonney2kbut only when serializing14:04
@iglesiasgI mean in the BMRM code14:04
@sonney2kiglesiasg, might be - but still if they are cast by apply()14:04
@iglesiasgsure cast, but the problem might be there, who knows14:05
@iglesiasgparijat, I don't see right away the inheritance using this approach with enums -- but maybe it makes sense!14:06
@sonney2kiglesiasg, it uses m_model->structured_labels_factory14:07
@sonney2kand m_model is MulticlassModel14:08
@iglesiasgsonney2k, aham, cannot tell you about the factory thingy14:08
@sonney2kwhich gives    return new CMulticlassSOLabels(num_labels);14:08
@sonney2kso it looks good14:09
@sonney2kiglesiasg, do we have an equivalent C++ example14:10
parijatiglesiasg, let me think carefully what might be best implementation and since Peter will be contributing Elkan's kmeans, let me start working with lloyd's and mini-batch versions only14:10
@sonney2kiglesiasg, I would want to iron out that it is a swig thing14:11
@iglesiasgsonney2k, I think there is one, yes. Let me check14:11
@iglesiasgsonney2k, so_multiclass_BMRM.cpp14:11
@iglesiasgand yes, it is a pain that some are called so_ and others structure_14:12
@iglesiasgI should have renamed the so_* already :S14:12
@sonney2kiglesiasg, well and that some are called BMRM and others bmrm ...14:12
@sonney2kiglesiasg, first tests green before that no new pushes14:12
@iglesiasgtotally agree14:13
@iglesiasgsonney2k, but I don't understand! How is it possible that for instance in 2068 the test is fine in the buildbot but not locally?14:20
@iglesiasgsonney2k,  I did the git submodule update. Is there something else I am missing?14:23
@iglesiasgI am trying now going far before in time, to 200014:24
@iglesiasggtg, will continue on it later14:35
-!- iglesiasg [] has quit [Quit: Leaving]14:35
-!- parijat [671b082a@gateway/web/freenode/ip.] has quit [Quit: Page closed]14:44
-!- gsomix [~gsomix@] has joined #shogun17:09
-!- lisitsyn [~lisitsyn@] has quit [Ping timeout: 260 seconds]17:18
-!- iglesiasg [] has joined #shogun17:32
-!- mode/#shogun [+o iglesiasg] by ChanServ17:32
@iglesiasgsonney2k, ping17:45
@iglesiasgsonney2k, sonne|osx, any idea what does this one mean?17:45
-!- lisitsyn [~lisitsyn@] has joined #shogun18:08
-!- lisitsyn [~lisitsyn@] has quit [Ping timeout: 272 seconds]18:14
-!- lisitsyn [~lisitsyn@] has joined #shogun18:20
-!- lisitsyn1 [~lisitsyn@] has joined #shogun18:30
@iglesiasglisitsyn, man I don't manage to check out a version where a test actually works locally18:30
@iglesiasgit is driving me nuts18:30
-!- lisitsyn [~lisitsyn@] has quit [Read error: No route to host]18:32
-!- pickle27 [] has joined #shogun18:39
lisitsyn1iglesiasg: what's going on? :)19:27
@iglesiasglisitsyn1, these integration tests19:33
@iglesiasgfuck yeah!19:33
@iglesiasgI found a revision in which the fucking test is fine19:33
@iglesiasgthat's an step forward indeed19:36
@sonney2kiglesiasg, hurray!19:56
@sonney2kiglesiasg, which revision is it?19:57
@iglesiasgsonney2k, commit c00c71a6cf13ed166dc52bb6395d4ec82874189420:11
@sonney2kiglesiasg, so that is the last known working?20:11
@iglesiasgsonney2k, not really. That is one that works20:14
@iglesiasgthere might be other revisions after that one where the test work as well20:14
@sonney2kiglesiasg, and the oldest non-working one?20:14
@sonney2kyou know so far?20:15
@iglesiasgsonney2k, nope20:20
@iglesiasgsonney2k, but I know no-working ones so I can use git bisect20:20
@iglesiasgI know an old one, but it is unknown whether it is the oldest non-working20:20
@sonney2kiglesiasg, well which one...20:37
@sonney2kiglesiasg, gsomix - found the reason why the fails20:40
@sonney2kp a20:41
@sonney2kp type(a)20:41
@sonney2k<type 'StructuredLabels'>20:41
@sonney2kso wtf is going on here...20:41
@sonney2kgsomix, could that have to do with the apply hack you did?20:43
@sonney2kgsomix, or is this some swig thing not being aware of the type at that stage?!20:43
gsomixsonney2k, checking...20:43
@sonney2kit is not happening in the C++ code20:48
@sonney2kgsomix, I think it indeed is a swig thing20:53
@sonney2klet me check what happens if I forcefully convert it to MulticlassSOLabels20:54
gsomixsonney2k, I'm not sure that we have this case in LabesFactory20:58
@sonney2kgsomix, no we don't but it is worth a try...20:59
@sonney2kgsomix, maybe you know from your swig endeavors - how can we override the type of the object?21:04
@sonney2kgsomix, I guess that is what we need in this case21:05
gsomixsonney2k, nope.21:07
@sonney2kiglesiasg, why is the MulticlassSOLabels.{h,cpp} not in shogun/labels/ ?21:08
@sonney2kgsomix, adding a to_multiclass_so fixes the type and so the example21:23
@sonney2ktoo bad swig cannot magically handle that since this apply here might return various different types21:24
gsomixwe have hack for features that do it magically21:25
@sonney2kgsomix, yeah but there the type is clear upfront or?21:26
@sonney2kgsomix, or not?21:26
@sonney2kgsomix, this apply method here just returns CStructuredLabels21:26
@sonney2kand these can be CMulticlassSOLabels or anything else derived from CStructuredLabels21:28
@sonney2kiglesiasg, should we have a new label type (cf LabelTypes.h) for CMulticlassSOLabels?21:29
@sonney2kgsomix, so what is the hack - and could we use it in this case too?21:40
gsomixsonney2k, there is some additional info in features like feat_class and typecode. so I just wrote typemaps that just converts swig's pointers using this info.21:53
gsomixbut this is hard coding21:54
-!- shogun-notifier- [] has joined #shogun21:58
shogun-notifier-shogun-data: Soeren Sonnenburg :master * 9ea447e / testsuite/tests/structure_multiclass_bmrm0.txt:
shogun-notifier-shogun-data: add bmrm test data21:58
shogun-notifier-shogun: Soeren Sonnenburg :develop * 1bfa8cf / / (5 files):
shogun-notifier-shogun: add to_multiclass_structured in LabelsFactory and use that for bmrm example / test21:59
@sonney2kgsomix, well we could do the same - labels have a LabelType...22:00
@sonney2kgsomix, time to do this?22:00
gsomixsonney2k, yep, ok.22:02
gsomixI'm still preparing to exams, but this makes me crazy - so, I will prefer coding tonight.22:04
-!- pickle27 [] has quit [Quit: Leaving]22:19
shogun-buildbotbuild #350 of osx1 - libshogun is complete: Failure [failed test]  Build details are at  blamelist: Soeren Sonnenburg <>22:22
@iglesiasgsonney2k, didn't get why having a new label type for MulticlassSOLabels22:38
shogun-buildbotbuild #36 of deb4 - python3 is complete: Failure [failed test python modular]  Build details are at  blamelist: Soeren Sonnenburg <>22:43
shogun-buildbotbuild #2141 of deb3 - modular_interfaces is complete: Failure [failed test python modular]  Build details are at  blamelist: Soeren Sonnenburg <>23:33
@iglesiasgsonney2k, I am in the git bisect process, still about 5-6 revisions to test. Will update you tom about it23:48
-!- iglesiasg [] has quit [Quit: Leaving]23:48
--- Log closed Mon Jan 20 00:00:00 2014