| --- Log opened Sun Jan 19 00:00:58 2014 | ||
| -!- iglesiasg [~iglesiasg@524AE0A7.cm-4-3d.dynamic.ziggo.nl] has quit [Quit: Leaving] | 00:52 | |
| -!- sonne|osx_ [~sonne@f052018132.adsl.alicedsl.de] has joined #shogun | 03:32 | |
| -!- sonne|osx [~sonne@f053035047.adsl.alicedsl.de] has quit [Ping timeout: 260 seconds] | 03:33 | |
| -!- sonne|osx_ is now known as sonne|osx | 03:33 | |
| shogun-buildbot | build #685 of nightly_default is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/685 | 03:58 |
|---|---|---|
| -!- parijat [671b082a@gateway/web/freenode/ip.103.27.8.42] has joined #shogun | 12:17 | |
| parijat | Hi, is there a way to multiply a scalar with a vector (or matrix) without having to iterate over its elements? | 12:26 |
| -!- iglesiasg [~iglesiasg@524AE0A7.cm-4-3d.dynamic.ziggo.nl] has joined #shogun | 13:02 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 13:02 | |
| @iglesiasg | sonney2k, ping | 13:35 |
| parijat | @iglesiasg: hello | 13:36 |
| @iglesiasg | parijat, hey | 13:36 |
| parijat | iglesiasg, regarding KMeans interface, I think the 2nd option suggested by you is better | 13:37 |
| @iglesiasg | parijat, all right | 13:38 |
| parijat | iglesiasg, user can then possibly switch between implementations | 13:38 |
| @iglesiasg | parijat, yep, indeed | 13:38 |
| @iglesiasg | parijat, be sure to test that works once it is done then | 13:38 |
| @iglesiasg | parijat, this is, in the same example, first train with one kmeans method, then with another, etc | 13:39 |
| @iglesiasg | with the same KMeans instance | 13:39 |
| parijat | iglesiasg, is it possible to implement it in a modular fashion? | 13:39 |
| @iglesiasg | parijat, can you elaborate? | 13:39 |
| @iglesiasg | do you mean to have the general KMeans class which is the interface | 13:40 |
| @iglesiasg | then the other classes with the implementations for each KMeans method? | 13:40 |
| parijat | iglesiasg, I meant keeping separate classes for each implementation of kmeans but showing to user just one class. how can I do it? | 13:41 |
| @iglesiasg | parijat, yes, sure it is possible | 13:42 |
| @iglesiasg | parijat, I would have a KMeans class that has (among possibly other attributes) one enum attribute to select the KMeans method to use | 13:42 |
| @iglesiasg | then the train in this class would basically have a switch statement | 13:43 |
| @iglesiasg | that depending on the value of this attribute, basically the train method implemented in one of the other classes | 13:43 |
| @iglesiasg | basically calls* (missed that verb :) | 13:44 |
| @iglesiasg | and then the idea would be that these other classes need not to be visible from target interfaces (e.g. python_modular, etc) | 13:45 |
| @iglesiasg | so in KMeans.cpp you include KMeansElkanImpl.h, KMeansMiniBatchImpl.h, etc | 13:46 |
| @iglesiasg | parijat, does that make sense to you? | 13:46 |
| parijat | iglesiasg, yup | 13:46 |
| @iglesiasg | it is probably not the only way to do this.. | 13:46 |
| @sonney2k | iglesiasg, what did you not understand with git bisect? | 13:47 |
| @sonney2k | iglesiasg, and hey pong :) | 13:47 |
| parijat | iglesiasg, so basically its 3 (possibly more) to one kind of inheritance structure? | 13:47 |
| @iglesiasg | sonney2k, I think I understood it | 13:48 |
| @iglesiasg | sonney2k, the thing is that I don't know yet when the tests were actually in good state | 13:48 |
| @iglesiasg | sonney2k, 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 file | 13:49 |
| @sonney2k | iglesiasg, I thought you did? | 13:49 |
| @iglesiasg | sonney2k, nope | 13:49 |
| @iglesiasg | sonney2k, do you see the problem I mean with the data file used in the integration test? | 13:50 |
| @iglesiasg | because as I see it right now, this makes a huuuuge pain | 13:51 |
| @sonney2k | iglesiasg, no - I don't get it | 13:52 |
| @iglesiasg | sonney2k, integration tests used files in shogun/data/testsuite/tests, right? | 13:52 |
| @iglesiasg | sonney2k, which are tracked in the data repository | 13:53 |
| @sonney2k | yes and? | 13:53 |
| @iglesiasg | sonney2k, if one the files in the testsuite has several versions | 13:53 |
| @iglesiasg | sonney2k, then say I go back in shogun repository to a past version, and run the tester | 13:54 |
| @sonney2k | and? | 13:54 |
| @iglesiasg | sonney2k, it might not use the file it should be using for that revision! | 13:54 |
| @sonney2k | iglesiasg, well just git submodule update | 13:55 |
| @sonney2k | and done | 13:55 |
| @iglesiasg | aham, that is indeed more practical than checking by hand what is the corresponding data version | 13:55 |
| @sonney2k | iglesiasg, so could you continue trying to figure this out? | 13:56 |
| @sonney2k | iglesiasg, I mean you could find out if mmd still works using the buildbot / some build where it actually worked | 13:57 |
| @iglesiasg | sonney2k, I continue trying yes | 13:58 |
| @iglesiasg | I was using my machine but it is true that the process would be faster in the buildbot | 13:58 |
| @iglesiasg | sonney2k, can you remind me how do I ssh to it? :) | 13:58 |
| @iglesiasg | I will write it down this time | 13:59 |
| @sonney2k | iglesiasg, ssh fatbot.* | 13:59 |
| @sonney2k | iglesiasg, but I meant the buildbot.sgtb.eu logs - because there is one where it still works I am sure :) | 13:59 |
| @iglesiasg | sonney2k, according to the logs, as we discussed the other day, it is in 2069 where it worked and in 2070 where it started failing | 14:00 |
| @iglesiasg | but this makes no sense | 14:00 |
| @iglesiasg | since they are the same revision | 14:00 |
| @sonney2k | iglesiasg, well checkout some version before 2069 - compile and test locally | 14:01 |
| @sonney2k | iglesiasg, if it works start the bisect with good | 14:01 |
| @iglesiasg | sonney2k, I checked out 2069, compiled and tested locally | 14:01 |
| @sonney2k | and find some version after 2070 that fails | 14:01 |
| @iglesiasg | failed | 14:01 |
| @iglesiasg | when I realized about the data file issue | 14:01 |
| @iglesiasg | so right now I am checking if statistics_linear_time_mmd actually has more than version | 14:01 |
| @iglesiasg | the data file | 14:01 |
| @sonney2k | ok | 14:02 |
| @sonney2k | iglesiasg, well keep trying... | 14:02 |
| @iglesiasg | https://github.com/shogun-toolbox/shogun-data/commits/master/testsuite/tests/statistics_linear_time_mmd0.txt | 14:03 |
| @iglesiasg | it indeed has more than one version | 14:03 |
| @iglesiasg | let me check now that git submodule update goes back to the right onw | 14:03 |
| @sonney2k | iglesiasg, 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 |
| @iglesiasg | aham! I see | 14:03 |
| @iglesiasg | sonney2k, maybe they are internally created as StructuredLabels instead of MulticlassSO? | 14:04 |
| @sonney2k | but only when serializing | 14:04 |
| @iglesiasg | I mean in the BMRM code | 14:04 |
| @sonney2k | iglesiasg, might be - but still if they are cast by apply() | 14:04 |
| @iglesiasg | sure cast, but the problem might be there, who knows | 14:05 |
| @iglesiasg | parijat, I don't see right away the inheritance using this approach with enums -- but maybe it makes sense! | 14:06 |
| @sonney2k | iglesiasg, it uses m_model->structured_labels_factory | 14:07 |
| @sonney2k | and m_model is MulticlassModel | 14:08 |
| @iglesiasg | sonney2k, aham, cannot tell you about the factory thingy | 14:08 |
| @sonney2k | which gives return new CMulticlassSOLabels(num_labels); | 14:08 |
| @sonney2k | so it looks good | 14:09 |
| @iglesiasg | yep | 14:10 |
| @sonney2k | iglesiasg, do we have an equivalent C++ example | 14:10 |
| parijat | iglesiasg, 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 only | 14:10 |
| @sonney2k | iglesiasg, I would want to iron out that it is a swig thing | 14:11 |
| @iglesiasg | sonney2k, I think there is one, yes. Let me check | 14:11 |
| @iglesiasg | sonney2k, so_multiclass_BMRM.cpp | 14:11 |
| @iglesiasg | and yes, it is a pain that some are called so_ and others structure_ | 14:12 |
| @iglesiasg | I should have renamed the so_* already :S | 14:12 |
| @sonney2k | iglesiasg, well and that some are called BMRM and others bmrm ... | 14:12 |
| @iglesiasg | :D | 14:12 |
| @sonney2k | iglesiasg, first tests green before that no new pushes | 14:12 |
| @iglesiasg | totally agree | 14:13 |
| @iglesiasg | sonney2k, 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 |
| @iglesiasg | sonney2k, I did the git submodule update. Is there something else I am missing? | 14:23 |
| @iglesiasg | I am trying now going far before in time, to 2000 | 14:24 |
| @iglesiasg | gtg, will continue on it later | 14:35 |
| -!- iglesiasg [~iglesiasg@524AE0A7.cm-4-3d.dynamic.ziggo.nl] has quit [Quit: Leaving] | 14:35 | |
| -!- parijat [671b082a@gateway/web/freenode/ip.103.27.8.42] has quit [Quit: Page closed] | 14:44 | |
| -!- gsomix [~gsomix@46.20.65.64] has joined #shogun | 17:09 | |
| -!- lisitsyn [~lisitsyn@80.252.20.67] has quit [Ping timeout: 260 seconds] | 17:18 | |
| -!- iglesiasg [~iglesiasg@524AE0A7.cm-4-3d.dynamic.ziggo.nl] has joined #shogun | 17:32 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 17:32 | |
| @iglesiasg | sonney2k, ping | 17:45 |
| @iglesiasg | sonney2k, sonne|osx, any idea what does this one mean? | 17:45 |
| @iglesiasg | http://pastebin.com/YpFJjAWs | 17:46 |
| -!- lisitsyn [~lisitsyn@213.87.129.91] has joined #shogun | 18:08 | |
| -!- lisitsyn [~lisitsyn@213.87.129.91] has quit [Ping timeout: 272 seconds] | 18:14 | |
| -!- lisitsyn [~lisitsyn@213.87.129.91] has joined #shogun | 18:20 | |
| -!- lisitsyn1 [~lisitsyn@80.252.20.67] has joined #shogun | 18:30 | |
| @iglesiasg | lisitsyn, man I don't manage to check out a version where a test actually works locally | 18:30 |
| @iglesiasg | it is driving me nuts | 18:30 |
| -!- lisitsyn [~lisitsyn@213.87.129.91] has quit [Read error: No route to host] | 18:32 | |
| -!- pickle27 [~kevin@192-0-136-118.cpe.teksavvy.com] has joined #shogun | 18:39 | |
| lisitsyn1 | iglesiasg: what's going on? :) | 19:27 |
| @iglesiasg | lisitsyn1, these integration tests | 19:33 |
| @iglesiasg | fuck yeah! | 19:33 |
| @iglesiasg | finally | 19:33 |
| @iglesiasg | I found a revision in which the fucking test is fine | 19:33 |
| @iglesiasg | that's an step forward indeed | 19:36 |
| @sonney2k | iglesiasg, hurray! | 19:56 |
| @sonney2k | iglesiasg, which revision is it? | 19:57 |
| @iglesiasg | sonney2k, commit c00c71a6cf13ed166dc52bb6395d4ec828741894 | 20:11 |
| @sonney2k | iglesiasg, so that is the last known working? | 20:11 |
| @iglesiasg | sonney2k, not really. That is one that works | 20:14 |
| @iglesiasg | there might be other revisions after that one where the test work as well | 20:14 |
| @sonney2k | iglesiasg, and the oldest non-working one? | 20:14 |
| @sonney2k | you know so far? | 20:15 |
| @iglesiasg | sonney2k, nope | 20:20 |
| @iglesiasg | sonney2k, but I know no-working ones so I can use git bisect | 20:20 |
| @iglesiasg | I know an old one, but it is unknown whether it is the oldest non-working | 20:20 |
| @sonney2k | iglesiasg, well which one... | 20:37 |
| @sonney2k | iglesiasg, gsomix - found the reason why the structure_multiclass_bmrm.py fails | 20:40 |
| @sonney2k | p a | 20:41 |
| @sonney2k | MulticlassSOLabels | 20:41 |
| @sonney2k | p type(a) | 20:41 |
| @sonney2k | <type 'StructuredLabels'> | 20:41 |
| @sonney2k | so wtf is going on here... | 20:41 |
| gsomix | hm | 20:42 |
| @sonney2k | gsomix, could that have to do with the apply hack you did? | 20:43 |
| @sonney2k | gsomix, or is this some swig thing not being aware of the type at that stage?! | 20:43 |
| gsomix | sonney2k, checking... | 20:43 |
| @sonney2k | it is not happening in the C++ code | 20:48 |
| @sonney2k | gsomix, I think it indeed is a swig thing | 20:53 |
| @sonney2k | let me check what happens if I forcefully convert it to MulticlassSOLabels | 20:54 |
| gsomix | sonney2k, I'm not sure that we have this case in LabesFactory | 20:58 |
| gsomix | *LabelsFactory | 20:58 |
| @sonney2k | gsomix, no we don't but it is worth a try... | 20:59 |
| @sonney2k | gsomix, maybe you know from your swig endeavors - how can we override the type of the object? | 21:04 |
| @sonney2k | gsomix, I guess that is what we need in this case | 21:05 |
| gsomix | sonney2k, nope. | 21:07 |
| @sonney2k | iglesiasg, why is the MulticlassSOLabels.{h,cpp} not in shogun/labels/ ? | 21:08 |
| @sonney2k | gsomix, adding a to_multiclass_so fixes the type and so the example | 21:23 |
| @sonney2k | too bad swig cannot magically handle that since this apply here might return various different types | 21:24 |
| gsomix | we have hack for features that do it magically | 21:25 |
| @sonney2k | gsomix, yeah but there the type is clear upfront or? | 21:26 |
| @sonney2k | gsomix, or not? | 21:26 |
| @sonney2k | gsomix, this apply method here just returns CStructuredLabels | 21:26 |
| @sonney2k | and these can be CMulticlassSOLabels or anything else derived from CStructuredLabels | 21:28 |
| @sonney2k | iglesiasg, should we have a new label type (cf LabelTypes.h) for CMulticlassSOLabels? | 21:29 |
| @sonney2k | gsomix, so what is the hack - and could we use it in this case too? | 21:40 |
| gsomix | sonney2k, 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 |
| gsomix | but this is hard coding | 21:54 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 21:58 | |
| shogun-notifier- | shogun-data: Soeren Sonnenburg :master * 9ea447e / testsuite/tests/structure_multiclass_bmrm0.txt: https://github.com/shogun-toolbox/shogun-data/commit/9ea447e356fc71ef9a815e9af027893c91cd2a0c | 21:58 |
| shogun-notifier- | shogun-data: add bmrm test data | 21:58 |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 1bfa8cf / / (5 files): https://github.com/shogun-toolbox/shogun/commit/1bfa8cf84396bfbf2609ad4bac4b4af862db4112 | 21:59 |
| shogun-notifier- | shogun: add to_multiclass_structured in LabelsFactory and use that for bmrm example / test | 21:59 |
| @sonney2k | gsomix, well we could do the same - labels have a LabelType... | 22:00 |
| @sonney2k | gsomix, time to do this? | 22:00 |
| gsomix | sonney2k, yep, ok. | 22:02 |
| gsomix | I'm still preparing to exams, but this makes me crazy - so, I will prefer coding tonight. | 22:04 |
| -!- pickle27 [~kevin@192-0-136-118.cpe.teksavvy.com] has quit [Quit: Leaving] | 22:19 | |
| shogun-buildbot | build #350 of osx1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/osx1%20-%20libshogun/builds/350 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:22 |
| @iglesiasg | sonney2k, didn't get why having a new label type for MulticlassSOLabels | 22:38 |
| shogun-buildbot | build #36 of deb4 - python3 is complete: Failure [failed test python modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb4%20-%20python3/builds/36 blamelist: Soeren Sonnenburg <sonne@debian.org> | 22:43 |
| shogun-buildbot | build #2141 of deb3 - modular_interfaces is complete: Failure [failed test python modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2141 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:33 |
| @iglesiasg | sonney2k, I am in the git bisect process, still about 5-6 revisions to test. Will update you tom about it | 23:48 |
| -!- iglesiasg [~iglesiasg@524AE0A7.cm-4-3d.dynamic.ziggo.nl] has quit [Quit: Leaving] | 23:48 | |
| --- Log closed Mon Jan 20 00:00:00 2014 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!