| --- Log opened Sat Jul 12 00:00:11 2014 | ||
| -!- jiaolong [9e6d1f01@gateway/web/freenode/ip.158.109.31.1] has quit [] | 00:33 | |
| -!- rajul [~rajul@182.68.152.170] has quit [Ping timeout: 256 seconds] | 00:41 | |
| -!- khalednasr [~k.nasr92@41.69.228.210] has quit [Quit: Leaving] | 01:19 | |
| -!- HeikoS [~heiko@dab-hlw1-h-1-2.dab.02.net] has joined #shogun | 01:32 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 01:32 | |
| @HeikoS | heya | 01:33 |
|---|---|---|
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 01:36 | |
| shogun-notifier- | shogun: abinashpanda :develop * 2318579 / doc/ipython-notebooks/structure/multilabel_structured_prediction.ipynb: https://github.com/shogun-toolbox/shogun/commit/2318579d304cecb4921f3bec4213554f199d7b37 | 01:36 |
| shogun-notifier- | shogun: Modified multilabel_structured_prediction.ipynb according to the shogun template | 01:36 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 15d5dac / doc/ipython-notebooks/structure/multilabel_structured_prediction.ipynb: https://github.com/shogun-toolbox/shogun/commit/15d5dacf085c181bf59b3ff2ee5c5d40a92c33d5 | 01:36 |
| shogun-notifier- | shogun: Merge pull request #2378 from abinashpanda/notebook | 01:36 |
| shogun-notifier- | shogun: | 01:36 |
| shogun-notifier- | shogun: Modified multilabel_structured_prediction.ipynb | 01:36 |
| shogun-buildbot | build #3086 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3086 | 01:42 |
| shogun-buildbot | build #2423 of bsd1 - libshogun is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2423 blamelist: abinashpanda <abinash.panda.ece10@itbhu.ac.in> | 01:44 |
| shogun-buildbot | build #2424 of bsd1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2424 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 01:52 |
| -!- HeikoS [~heiko@dab-hlw1-h-1-2.dab.02.net] has quit [Ping timeout: 240 seconds] | 01:52 | |
| shogun-buildbot | build #402 of deb4 - python3 is complete: Failure [failed test python modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb4%20-%20python3/builds/402 blamelist: abinashpanda <abinash.panda.ece10@itbhu.ac.in> | 02:12 |
| shogun-buildbot | build #2409 of deb3 - modular_interfaces is complete: Failure [failed python modular] Build details are at http://buildbot.shogun-toolbox.org/builders/deb3%20-%20modular_interfaces/builds/2409 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, abinashpanda <abinash.panda.ece10@itbhu.ac.in> | 02:16 |
| shogun-buildbot | build #403 of deb4 - python3 is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb4%20-%20python3/builds/403 | 02:23 |
| -!- zxtx_ [~zv@173.164.89.193] has quit [Ping timeout: 240 seconds] | 02:26 | |
| shogun-buildbot | build #745 of nightly_all is complete: Failure [failed compile test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_all/builds/745 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, abinashpanda <abinash.panda.ece10@itbhu.ac.in>, Saurabh <saurabh.mahindre@gmail.com> | 03:04 |
| shogun-buildbot | build #849 of nightly_default is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/849 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, abinashpanda <abinash.panda.ece10@itbhu.ac.in>, Saurabh <saurabh.mahindre@gmail.com> | 03:12 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 04:36 | |
| -!- soumyaC [uid15286@gateway/web/irccloud.com/x-lyvzgcjepjeamjmu] has quit [Quit: Connection closed for inactivity] | 06:06 | |
| -!- rajul [~rajul@182.68.139.21] has joined #shogun | 08:24 | |
| -!- zxtx_ [~zv@67.51.233.200] has joined #shogun | 08:39 | |
| -!- rajul [~rajul@182.68.139.21] has quit [Ping timeout: 240 seconds] | 08:46 | |
| -!- rajul [~rajul@180.151.18.31] has joined #shogun | 08:46 | |
| -!- zxtx_ [~zv@67.51.233.200] has quit [Ping timeout: 240 seconds] | 09:27 | |
| -!- rajul [~rajul@180.151.18.31] has quit [Ping timeout: 240 seconds] | 10:01 | |
| -!- rajul [~rajul@180.151.18.31] has joined #shogun | 10:06 | |
| -!- rajul [~rajul@180.151.18.31] has quit [Read error: Connection reset by peer] | 10:17 | |
| -!- rajul [~rajul@180.151.18.31] has joined #shogun | 10:18 | |
| -!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has joined #shogun | 11:19 | |
| -!- HeikoS [~heiko@dab-glb1-h-1-5.dab.02.net] has joined #shogun | 11:22 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 11:22 | |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 11:26 | |
| shogun-notifier- | shogun-data: Saurabh :master * 1f9ebc1 / toy/ionosphere.data: https://github.com/shogun-toolbox/shogun-data/commit/1f9ebc120eec62fe2a3d976603aec64d169c1e76 | 11:26 |
| shogun-notifier- | shogun-data: add ionosphere dataset | 11:26 |
| shogun-notifier- | shogun-data: Heiko Strathmann :master * 0e5cebf / toy/ionosphere.data: https://github.com/shogun-toolbox/shogun-data/commit/0e5cebf0e366fdd0d1a7c36cb2a3ceb4875c3d2a | 11:26 |
| shogun-notifier- | shogun-data: Merge pull request #62 from Saurabh7/master | 11:26 |
| shogun-notifier- | shogun-data: | 11:26 |
| shogun-notifier- | shogun-data: add ionosphere dataset | 11:26 |
| -!- rajul [~rajul@180.151.18.31] has quit [Read error: Connection reset by peer] | 11:35 | |
| -!- HeikoS [~heiko@dab-glb1-h-1-5.dab.02.net] has quit [Ping timeout: 240 seconds] | 11:40 | |
| -!- soumyaC [uid15286@gateway/web/irccloud.com/x-jamthzogebzdmkvp] has joined #shogun | 13:56 | |
| -!- Netsplit *.net <-> *.split quits: shogun-notifier- | 14:06 | |
| -!- Netsplit *.net <-> *.split quits: naywhayare, @ChanServ | 14:06 | |
| -!- Netsplit *.net <-> *.split quits: shogun-buildbot, zxtx | 14:07 | |
| -!- Netsplit over, joins: shogun-notifier-, @ChanServ, zxtx, shogun-buildbot, naywhayare | 14:07 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 14:26 | |
| -!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has quit [Ping timeout: 246 seconds] | 16:59 | |
| -!- jiaolong [9e6d1f01@gateway/web/freenode/ip.158.109.31.1] has joined #shogun | 17:01 | |
| -!- HeikoS [~heiko@82.132.219.146] has joined #shogun | 17:50 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 17:50 | |
| -!- kislay [~Abhijeet@103.240.205.23] has joined #shogun | 18:13 | |
| kislay | hey HeikoS | 18:13 |
| @HeikoS | kislay: hey | 18:25 |
| @HeikoS | how are things? | 18:25 |
| kislay | HeikoS, been busy with ANPR lately | 18:26 |
| @HeikoS | kislay: whats that? | 18:26 |
| kislay | sorry for being inactive.. | 18:26 |
| kislay | oh.. | 18:26 |
| kislay | automatic no. plate recognition :) | 18:26 |
| kislay | A notebook basically. | 18:26 |
| @HeikoS | i see | 18:27 |
| @HeikoS | kislay: cool, looking forward to see the result | 18:27 |
| kislay | yup. | 18:27 |
| @HeikoS | kislay: the lda thing is almost ready to go | 18:27 |
| @HeikoS | just one integration test failing | 18:28 |
| kislay | yeah..I am rechecking it now | 18:28 |
| -!- HeikoS [~heiko@82.132.219.146] has quit [Ping timeout: 240 seconds] | 18:35 | |
| -!- kislay [~Abhijeet@103.240.205.23] has quit [Ping timeout: 240 seconds] | 18:36 | |
| -!- kislay [~Abhijeet@103.240.205.23] has joined #shogun | 18:37 | |
| -!- lisitsyn [~qdrgsm@80.252.20.67] has quit [Quit: Leaving.] | 19:06 | |
| -!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has joined #shogun | 19:30 | |
| -!- HeikoS [~heiko@dab-ntm1-h-30-7.dab.02.net] has joined #shogun | 19:41 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 19:41 | |
| lambday | HeikoS: hey | 19:44 |
| @HeikoS | lambday: hi | 19:46 |
| lambday | HeikoS: hi! | 19:46 |
| lambday | HeikoS: libshogun tests are taking long time on travis! | 19:46 |
| @HeikoS | lambday: yes, annoying | 19:47 |
| @HeikoS | lambday: what to do=? | 19:47 |
| lambday | HeikoS: integration test failure is expected | 19:47 |
| lambday | HeikoS: I am trying out with develop branch to compare locally how much is the difference | 19:47 |
| @HeikoS | lambday: since we have to update things? | 19:47 |
| lambday | but with blocksize 4 for linear time mmd | 19:47 |
| @HeikoS | lambday: okay | 19:47 |
| lambday | there shouldn't be so much difference | 19:47 |
| lambday | except for the extra overhead for recomputing things with shuffling | 19:48 |
| lambday | for variance | 19:48 |
| lambday | maybe I can set WITHIN_BLOCK_DIRECT as default for those ttests | 19:48 |
| lambday | that might be faster | 19:48 |
| lambday | HeikoS: I have been overly occupied lately with release from insti and relocating to a new place :( couldn't be active lately... will try my best to make up for it in coming days :( | 19:49 |
| @HeikoS | lambday: we should aim to test everything in the end | 19:49 |
| @HeikoS | lambday: maybe we can disable some tests on the travis | 19:49 |
| @HeikoS | lambday: and let buildbot take care of it | 19:50 |
| lambday | HeikoS: tests with large number of samples can be disabled | 19:50 |
| lambday | maybe some flag magic as you suggested | 19:50 |
| @HeikoS | lambday: dont worry | 19:50 |
| @HeikoS | lambday: where are you moving to? | 19:50 |
| @HeikoS | bangalore ? :D | 19:50 |
| lambday | HeikoS: to Bangalore... | 19:50 |
| lambday | HeikoS: haha yes... | 19:50 |
| @HeikoS | lambday: when are you doing your internship at ucl ? ;) | 19:51 |
| lambday | HeikoS: but ran into some problem.. my thesis here isn't complete... so will have to come back to Mumbai to finish my degree | 19:51 |
| lambday | HeikoS: just as soon as I get enough money to leave Oracle | 19:51 |
| lambday | :D | 19:51 |
| @HeikoS | lambday: i see :) | 19:51 |
| @HeikoS | lambday: you are welcome to come here for a while, just let me know and i bring you in touch with the right people | 19:52 |
| lambday | HeikoS: my prof changed my topic lately... because earlier the problem I was working on was very open ended research problem... couldn't do much on that | 19:52 |
| @HeikoS | lambday: will you be able to use the hsic based feature selection for your thesis? | 19:52 |
| @HeikoS | lambday: i see | 19:52 |
| lambday | HeikoS: with this new topic - I don't know... currently I am working on feature induction on relation data with relational kernels (kLog to be exact) | 19:53 |
| @HeikoS | wow, no idea about that stuff | 19:53 |
| @HeikoS | lambday: good luck :D | 19:53 |
| @HeikoS | lambday: so but back to the tests ... | 19:53 |
| lambday | earlier attempt didn't yield correct results | 19:53 |
| lambday | yes | 19:53 |
| @HeikoS | lambday: so if we disable the tests for now globally, maybe we can ask viktor to do something that we ignore certain tests on travis | 19:54 |
| @HeikoS | lambday: that should be fine | 19:54 |
| @HeikoS | lambday: then we still cover all the things we want (also when people run locally) | 19:54 |
| @HeikoS | lambday: but travis doesnt need to test all that stuff always | 19:54 |
| @HeikoS | lambday: not optimal, but still better than just dropping them | 19:54 |
| @HeikoS | wiking: ^ | 19:54 |
| lambday | HeikoS: yeah... that's the way to go.... I didn't know travis runs it on a vm with just 1 cpu | 19:55 |
| lambday | with multithreaded applications like sum methods for kernels, that's limiting | 19:55 |
| @HeikoS | lambday: yeah, but well, what can we do | 19:55 |
| @HeikoS | lambday: not a too serious problem | 19:55 |
| @HeikoS | we just need to give the unit tests a flag on travis | 19:56 |
| @HeikoS | that makes shogun ignore them | 19:56 |
| lambday | HeikoS: yeah.. | 19:56 |
| lambday | HeikoS: regarding the plots, they seem to recreate the plots for B-test on the paper.. | 19:56 |
| lambday | which is good | 19:56 |
| lambday | btw, on another topic, do we have support vector clustering in shogun? just wondering.. I have to do something related to this for thesis... | 19:59 |
| @HeikoS | lambday: yes, the plots look good | 20:10 |
| @HeikoS | lambday: cool that we can reproduce this | 20:10 |
| @HeikoS | lambday: no sv clustering | 20:10 |
| @HeikoS | lambday: i dont even know what that is | 20:10 |
| lambday | HeikoS: neither do I... just started to figure it out... apparently it uses one class svm or something to draw clusters... we don't have to give the number of clusters beforehand like kmeans or knn | 20:11 |
| @HeikoS | lambday: i would rather clean up the kmeans, and gmm | 20:12 |
| lambday | HeikoS: regarding the tests, I am trying locally with WITHIN_BLOCK_DIRECT and checking it that saves us any time on travis | 20:12 |
| @HeikoS | lambday: and then implement the VB-GMM first | 20:12 |
| @HeikoS | lambday: thats good, but we want everything to be tested eventiually | 20:12 |
| @HeikoS | lambday: all combinations | 20:12 |
| lambday | HeikoS: hmm :( but testing on travis is not equivalent to testing overall :( due to time limit :( we do need some magic to disable some tests on travis and leave on the buildbot | 20:13 |
| lambday | VB-GMM - now I'm lost :D | 20:13 |
| @HeikoS | lambday: just write all the tests we need, and make sure they pass locally when you do stuff, then disable them before commit | 20:14 |
| @HeikoS | lambday: _DISABLE in test name does that | 20:15 |
| @HeikoS | lambday: and then we ask wiking to offer us an option to disable only on trabis | 20:15 |
| @HeikoS | travis | 20:15 |
| lambday | HeikoS: do you know how do I disable libshogun tests? | 20:15 |
| @HeikoS | lambday: yes via the disable in capital letters in the name | 20:15 |
| @HeikoS | lambday: try it :) | 20:15 |
| lambday | in what name? for unit-tests I tried that :( | 20:16 |
| @HeikoS | lambday: VB-GMM = variational bayes gaussian mixture models - allows to do gmm and learn the number of clusters from data | 20:16 |
| @HeikoS | lambday: in the unit test name | 20:16 |
| @HeikoS | lambday: they will be not run then | 20:16 |
| @HeikoS | lambday: and googletest says "you have n disabled tests" | 20:16 |
| lambday | HeikoS: umm the problem here is caused by two libshogun tests (not unit-tests - they take long but eventually passes on travis) | 20:16 |
| lambday | in examples/undocumented/libshogun | 20:17 |
| @HeikoS | lambday: you meran not unit tests but examples? | 20:17 |
| @HeikoS | lambday: i see | 20:17 |
| @HeikoS | lambday: sorry | 20:17 |
| lambday | yeah | 20:17 |
| @HeikoS | lambday: these are not really tests | 20:17 |
| @HeikoS | lambday: in that case, i suggest to make them unit tests | 20:17 |
| @HeikoS | lambday: since the examples should just demonstrate API | 20:17 |
| lambday | libshogun_statistic_linear_time_mmd.cpp and libshogun_mmd_kernel_selection.cpp | 20:17 |
| lambday | HeikoS: alright.. | 20:18 |
| @HeikoS | lambday: i just did that back then since we did not hav eunit tests | 20:18 |
| lambday | HeikoS: then I guess these tests already exist as unit-tests... in libshogun examples we just use larges number of samples | 20:18 |
| @HeikoS | lambday: just api examples that show how to use each feature are enough | 20:18 |
| @HeikoS | lambday: and then unit tests do the rest | 20:18 |
| @HeikoS | lambday: and notebooks exmplain things | 20:18 |
| @HeikoS | lambday: then add the unit tests with large number of samples, and maybe disable for now until wiking figured out how to exclude in travis? | 20:19 |
| @HeikoS | lambday: does that make any sense? | 20:19 |
| lambday | HeikoS: okay... alright! so removing these two tests from libshogun - adding them as unit-tests... and in case they cause trouble, disabling them currently | 20:19 |
| lambday | HeikoS: haha same pinch! :D ye I got it | 20:19 |
| @HeikoS | lambday: http://scikit-learn.org/stable/modules/generated/sklearn.mixture.VBGMM.html | 20:19 |
| @HeikoS | lambday: btw | 20:19 |
| @HeikoS | lambday: its also all described in bishops book | 20:20 |
| lambday | HeikoS: wow man I can try that too for thesis... but its not any kernel based approach... my prof is obsessed with kernels | 20:20 |
| @HeikoS | lambday: ok, mmmh | 20:20 |
| lambday | HeikoS: cool stuff! | 20:20 |
| @HeikoS | lambday: ah funny, see this | 20:20 |
| @HeikoS | http://www.cs.ubc.ca/~murphyk/Software/VBEMGMM/index.html | 20:20 |
| @HeikoS | lambday: written by emt, the variational gp learning gsopc mentor :) | 20:21 |
| @HeikoS | back 7 years ago | 20:21 |
| lambday | ubc :D | 20:21 |
| lambday | wow! | 20:21 |
| lambday | checking | 20:21 |
| @HeikoS | lambday: he did his msc in bangalore | 20:21 |
| @HeikoS | haha did an intern at xerox before doing phd in the states | 20:22 |
| lambday | HeikoS: wow!... and I know one of my college senior who did Ms in UBC... emt might be knowing him :D | 20:22 |
| @HeikoS | lambday: yeah probably, everyone knows everyone anyways | 20:22 |
| @HeikoS | small cummunity :) | 20:22 |
| lambday | haha :D | 20:22 |
| @HeikoS | lambday: http://en.wikipedia.org/wiki/Spectral_clustering | 20:23 |
| lambday | HeikoS: the domain I am working on is interesting btw.. relational data is kind of like a prolog knowledge base | 20:23 |
| @HeikoS | lambday: cool stuff! | 20:23 |
| lambday | so the idea is... to cluster the examples in the knowledge base.... learn features... learn rules... classify | 20:23 |
| @HeikoS | lambday: kernel kmeans might also be cool to have | 20:24 |
| @HeikoS | lambday: i see | 20:24 |
| @HeikoS | lambday: interesting | 20:24 |
| lambday | but since the use of relational model in the data... we need some method that can handle these sort of feature mapping | 20:24 |
| lambday | like : movie_superhit:- is_directed_by(Christopher_Nolam), acted_in(Heath_Leger), music_by(Hans_Zimmer) .. | 20:25 |
| -!- khalednasr [~k.nasr92@41.69.170.139] has joined #shogun | 20:25 | |
| lambday | we learn these sort of rules.. and use them as features in svm | 20:26 |
| lambday | HeikoS: I wonder whether VB-GMM sort of idea can be applied to relational data... maybe worth exploring | 20:26 |
| lambday | HeikoS: if I work on kernel based k-means I'll add this to shogun... maybe an interface to handle relational data can also be cool! | 20:27 |
| lambday | khalednasr: hi! | 20:29 |
| khalednasr | lambday, hi | 20:29 |
| lambday | khalednasr: sorry for my long absence :( ran into some problems | 20:29 |
| lambday | khalednasr: what's the status update on linalg? | 20:29 |
| khalednasr | lambday, I'm addressing the issues we talked about earlier, gonna update the PR later today | 20:30 |
| lambday | khalednasr: so you're going ahead with the idea that's discussed on the PR discussion thread, right? did you update anything in the design? | 20:30 |
| khalednasr | lambday, which one do you mean? the backend-dependent matrix? | 20:31 |
| lambday | khalednasr: really cool that you thought this all the way through... performance compromising is the last thing we wanna do (y) | 20:31 |
| lambday | khalednasr: yes... lisitsyn said that you had some more ideas | 20:31 |
| lambday | khalednasr: if I understood the issues correctly, then using your idea eventually solves the problem of data-transfer from cpu <--> gpu when using different bakcends, right? | 20:33 |
| khalednasr | lambday, yeah | 20:33 |
| khalednasr | lambday, the library doesn't even need to know about that matrix class | 20:33 |
| lambday | khalednasr: great! :) that's, IMO, is the ideal solution! unifying all matrix/vector classes under one common shed | 20:34 |
| khalednasr | lambday, It might be useful as a return type though | 20:34 |
| lambday | khalednasr: what do you mean? | 20:34 |
| lambday | khalednasr: using these new classes, we don't have to pass things as arguments? | 20:35 |
| lambday | as preallocated matrices/vectors? | 20:35 |
| khalednasr | using it as a return type in the colwise_sum() method would solve that issue | 20:35 |
| lambday | super cool then! | 20:35 |
| khalednasr | GPU overloads will return the GPU version of that matrix | 20:35 |
| lambday | awesome! | 20:35 |
| khalednasr | and likewise for the CPU backends | 20:36 |
| lambday | since we dont expose things to other interfaces and these are all internals, this is the ideal solution | 20:36 |
| lambday | preallocating is old school if we talk about style :( | 20:36 |
| khalednasr | what should we call that class though? :) | 20:36 |
| lambday | khalednasr: how about Matrix and Vector :D | 20:37 |
| khalednasr | lambday, yeah but it's more efficient | 20:37 |
| lambday | khalednasr: is it possible to define these under linalg namespace, so that we can later differentiate? | 20:37 |
| lambday | shogun::linalg::Matrix | 20:37 |
| khalednasr | lambday, yeah, but won't we get name clashes with the template argument names? | 20:38 |
| lambday | khalednasr: err... | 20:38 |
| lambday | DMatrix DVector (D=dense) :-/ | 20:39 |
| * lambday showing off his worst naming skills | 20:39 | |
| khalednasr | lambday, yeah, that sounds good :) | 20:39 |
| lambday | khalednasr: let's start with matrix.. vector then would be easy | 20:40 |
| lambday | matrix thing we can test with linalg::square | 20:40 |
| khalednasr | lambday, I'm gonna do the other modification first, then send another PR with that class | 20:43 |
| khalednasr | modifications* | 20:43 |
| lambday | khalednasr: alright... just reorder the tasks as suitable for ease of testing things iteratively :) | 20:43 |
| khalednasr | lambday, alright | 20:44 |
| -!- HeikoS [~heiko@dab-ntm1-h-30-7.dab.02.net] has quit [Quit: Leaving.] | 20:44 | |
| lambday | anyone watching football? | 20:48 |
| -!- rajul [~rajul@180.151.18.31] has joined #shogun | 20:52 | |
| -!- HeikoS [~heiko@82.132.230.184] has joined #shogun | 20:53 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 20:53 | |
| @HeikoS | lambday: i have no idea about relational features, but i guess one can represent all that as graphs ;) | 20:53 |
| lambday | HeikoS: yes that's pretty much the idea - and then use graph kernels :D | 20:54 |
| @HeikoS | lambday: cool | 20:54 |
| @HeikoS | lambday: would be nice to have graph kernels in shogun | 20:54 |
| @HeikoS | lambday: in fact i am thinking of doing a two sample test example using a graph kernel with dino | 20:54 |
| lambday | HeikoS: yeah! I have been checking out kLog which does just that! | 20:54 |
| lambday | HeikoS: really!! | 20:55 |
| @HeikoS | lambday: yeah for the big testing paper | 20:55 |
| @HeikoS | lambday: some protein networks or so | 20:55 |
| @HeikoS | samples are graphs | 20:55 |
| lambday | HeikoS: btw there is this characteristic kernel properly that the kernel function should satisfy in order to be used in these tests | 20:55 |
| @HeikoS | lambday: doesnt have to | 20:56 |
| @HeikoS | lambday: only tell if this is true then mmd=0 iff p=q | 20:56 |
| lambday | HeikoS: cool!... then we can use number of string kernels as well | 20:57 |
| @HeikoS | lambday: totally | 20:57 |
| @HeikoS | lambday: if you could code up a toy example for the noteobok report, that would be in fact amazing | 20:57 |
| lambday | HeikoS: just out of nowhere, can one thing about using these tests to detect plagiarism ? | 20:57 |
| @HeikoS | like two distributions of strings | 20:57 |
| lambday | think** | 20:57 |
| @HeikoS | which each have a discrete distribution for the letters | 20:58 |
| @HeikoS | lambday: that is hard i think | 20:58 |
| @HeikoS | but you could do the following example for independence | 20:58 |
| @HeikoS | lambday: one distribution is a distribution of words, the other distribution is in the real numbers | 20:58 |
| @HeikoS | lambday: you generate the dataset like this | 20:58 |
| @HeikoS | lambday: pick some random number r | 20:59 |
| @HeikoS | do x=sin(r*const) | 20:59 |
| @HeikoS | and b=cos(r*const2) and then the sign of b selects one of two topics of words, from which you sample one | 21:00 |
| @HeikoS | then you have a dependence between words and numbers | 21:00 |
| @HeikoS | i have some matlab code to generate this somewhere | 21:00 |
| @HeikoS | let me send it to you | 21:00 |
| lambday | HeikoS: alright.. this would be cool for the notebook! | 21:00 |
| @HeikoS | lambday: exactly | 21:01 |
| @HeikoS | lambday: nice notebook example | 21:01 |
| @HeikoS | lambday: and for two sample, just come up with a distribution of strings | 21:01 |
| @HeikoS | lambday: where a histogram would look the same for each distribution | 21:02 |
| @HeikoS | lambday: (histogram over letters) | 21:02 |
| @HeikoS | lambday: but some structure in the letters is different | 21:02 |
| lambday | HeikoS: alright | 21:02 |
| @HeikoS | lambday: we could also do a two sample test on images of cats and dogs and a description of cats and dogs | 21:05 |
| lambday | HeikoS: the matlab code is for this two-sample test it seems... | 21:05 |
| @HeikoS | if x_1 is an image of a dog, y_1 is a description of a dog | 21:05 |
| @HeikoS | lambday: no its for kernel correlation, called COCO | 21:05 |
| @HeikoS | lambday: thats a preliminary version of hsic | 21:05 |
| @HeikoS | lambday: forgot the other file | 21:06 |
| lambday | HeikoS: okies... what group_dataset does? | 21:06 |
| lambday | HeikoS: oh :D | 21:06 |
| @HeikoS | lambday: yes | 21:07 |
| @HeikoS | lambday: note this code is very ugly ;) | 21:07 |
| @HeikoS | but the idea is nice | 21:07 |
| @HeikoS | dependence is not obvious | 21:07 |
| @HeikoS | from looking at the data | 21:07 |
| @HeikoS | lambday: where one is in the circle tells you the topic where the string is from | 21:07 |
| lambday | HeikoS: alright... getting it a bit | 21:09 |
| @HeikoS | lambday: getting food see you later :) | 21:17 |
| -!- HeikoS [~heiko@82.132.230.184] has quit [Quit: Leaving.] | 21:17 | |
| lambday | HeikoS: alright... ciao :) | 21:18 |
| khalednasr | lambday, quick question: | 21:22 |
| khalednasr | lambday, the DMatrix class would be defined as: template <class T, Backend backend> class DMatrix | 21:22 |
| khalednasr | lambday, the default value for backend should probably be the global backend | 21:22 |
| lambday | khalednasr: yes | 21:22 |
| khalednasr | lambday, can that be accessed? | 21:22 |
| lambday | khalednasr: let me check | 21:23 |
| lambday | khalednasr: linalg_traits<Redux>::backend | 21:24 |
| lambday | (or, appropriate module-name instead of Redux) | 21:24 |
| khalednasr | lambday, but that's just for the redux module | 21:24 |
| -!- rajul [~rajul@180.151.18.31] has quit [Read error: Connection reset by peer] | 21:25 | |
| lambday | khalednasr: other modules are are supposed to define it the same way | 21:25 |
| lambday | please check https://github.com/shogun-toolbox/shogun/blob/feature/linalg/src/shogun/mathematics/linalg/linalg.h | 21:25 |
| khalednasr | but the matrix class should default to the backend defined for a specific module | 21:25 |
| khalednasr | shouldn't* | 21:26 |
| khalednasr | it doesn't make sense to define it as: template <class T, Backend backend=linalg_traits<Redux>::backend> class DMatrix | 21:26 |
| lambday | khalednasr: checking if there is currently a way to do thsi | 21:28 |
| lambday | khalednasr: maybe we should use a module here (https://github.com/shogun-toolbox/shogun/blob/feature/linalg/src/shogun/mathematics/linalg/linalg.h#L101) that applies for all modules | 21:29 |
| khalednasr | lambday, so a GLOBAL or DEFAULT module maybe? | 21:30 |
| lambday | khalednasr: GLOBAL sounds good.. | 21:30 |
| lambday | DEFAULT is something else | 21:30 |
| khalednasr | lambday, cool, thanks | 21:31 |
| lambday | khalednasr: maybe define this GLOBAL and add it here https://github.com/shogun-toolbox/shogun/blob/feature/linalg/src/shogun/mathematics/linalg/linalg.h#L115 | 21:31 |
| lambday | then we can do linalg_traits<Global>::backend | 21:32 |
| khalednasr | lambday, so: SET_MODULE_BACKEND(Global, BACKEND) | 21:32 |
| lambday | khalednasr: yep! | 21:32 |
| lambday | this will solve it right> | 21:32 |
| khalednasr | lambday, yeah | 21:32 |
| khalednasr | lambday, what if neither USE_EIGEN3 or USE_VIENNACL is defined? | 21:33 |
| lambday | khalednasr: haha then we're doomed... HAVE_LINALG_LIB is not defined then and the whole linalg is missing | 21:33 |
| khalednasr | lambday, one of them has to be defined? | 21:34 |
| lambday | khalednasr: the idea was, we *got* to have at least one supported linalg backend | 21:34 |
| lambday | khalednasr: we're not a linalg library on our own and its not possible for us to provide native implementation for all linalg operations | 21:35 |
| lambday | so at least one of them *has* to be here | 21:35 |
| khalednasr | lambday, then why the #else here? https://github.com/shogun-toolbox/shogun/blob/feature/linalg/src/shogun/mathematics/linalg/linalg.h#L126 | 21:35 |
| lambday | USE_EIGEN3 == use eigen3 for *ALL* modules | 21:35 |
| lambday | USE_VIENNACL = use viennacl for *ALL* modules | 21:36 |
| lambday | USE_EIGEN3_REDUX = use eigen3 for redux modules | 21:36 |
| lambday | and so | 21:36 |
| lambday | HAVE_LINALG_LIB == HAVE_EIGEN3 | HAVE_VIENNACL | 21:36 |
| lambday | that's something else | 21:36 |
| lambday | khalednasr: does it make sense? | 21:37 |
| khalednasr | lambday, what I mean is, we added this: SET_MODULE_BACKEND(Global, BACKEND) to SET_GLOBAL_BACKEND | 21:37 |
| lambday | khalednasr: yes... | 21:37 |
| khalednasr | lambday, which is only called if USE_EIGEN3 or USE_VIENNACL is defined | 21:37 |
| lambday | khalednasr: yes but how does that work for module specific setups? | 21:38 |
| lambday | umm gotta rethink this a bit :/ | 21:39 |
| lambday | sorry for the mess up! not everything is on the top of my head right now :( | 21:39 |
| -!- rajul [~rajul@182.68.184.120] has joined #shogun | 21:39 | |
| khalednasr | lambday, it's alright | 21:39 |
| khalednasr | lambday, how about: SET_MODULE_BACKEND(Global, Eigen3) in the #else? | 21:40 |
| lambday | khalednasr: does this solve the issue? | 21:40 |
| lambday | how about we have eigen3 module backend set for redux and viennacl backend set for some other module | 21:41 |
| lambday | ? | 21:41 |
| khalednasr | lambday, I'm not sure | 21:41 |
| lambday | Global then would be set as per the last one in the code which is unpredictable | 21:41 |
| -!- lisitsyn [~qdrgsm@80.252.20.67] has joined #shogun | 21:41 | |
| lambday | or worse - compilation error | 21:41 |
| lambday | khalednasr: is it necessary that we provide default template arg? | 21:42 |
| lisitsyn | lambday: khalednasr: aha! | 21:43 |
| lisitsyn | discussing gpu things here | 21:43 |
| lisitsyn | ;) | 21:43 |
| khalednasr | lambday, yup, or we'd go back to the same problem of the developer having to specify a backend | 21:43 |
| lambday | lisitsyn: worse - discussing API changes here :( | 21:43 |
| lambday | khalednasr: yes I see the point | 21:44 |
| lambday | ummm.... | 21:44 |
| * lambday thinking | 21:44 | |
| lambday | so lets lay down the requirements | 21:44 |
| lambday | we want the matrix class to be GPU when *ALL* modules use GPU | 21:44 |
| lambday | right? | 21:44 |
| lambday | but that's bad | 21:45 |
| khalednasr | I'm not sure.. | 21:45 |
| lambday | khalednasr: how about, we use a backend *AND* module specific matrix class? | 21:45 |
| lambday | 3 template args | 21:46 |
| lambday | is that possible? | 21:46 |
| khalednasr | lambday, I'm not sure I get what you mean | 21:46 |
| lambday | khalednasr: template<typename Scalar, enum Backend, class Module> DMatrix | 21:47 |
| lambday | if backend for redux module is set as GPU, the matrix class for redux should inherit from CGPUMatrix | 21:47 |
| lambday | is it possible? | 21:47 |
| khalednasr | lambday, seems too complicated | 21:49 |
| lambday | khalednasr: yes... but if we *don't* use module specific matrix, then module specific cpu/gpu settings would lead to a massive overhead :( | 21:50 |
| lambday | maybe there is an easier solution out there | 21:50 |
| lambday | khalednasr: do you see the point? I mean, in compile-time, our DMatrix is set to inherit from CGPUMatrix, but in all the modules we use CPU things using cmake option | 21:53 |
| khalednasr | lambday, ahh I see | 21:55 |
| khalednasr | lambday, but if we make it module-backend dependent, what exactly should happen when a developer declares DMatrix<float64_t> in their algorithm? | 21:57 |
| khalednasr | which class will it derive from? | 21:58 |
| lambday | khalednasr: we *got* to have a global module for default things... and it should work if global backend settings are specified using cmake via USE_EIGEN3 or USE_VIENNACL... but there should be a way via which a user can specify this | 21:59 |
| lambday | so, using DMatrix<float64_t> would inherit that linalg_traits<Global>::backend depends on... | 22:00 |
| lambday | but it can also do DMatrix<float64_t, NeuralNets> which inherits from the backend specified for NeuralNets module | 22:00 |
| khalednasr | lambday, ahh, that makes sense | 22:02 |
| lambday | khalednasr: I am just saying - unless I myself can code this thing I am never sure if it can be done :( | 22:03 |
| lambday | ah 3 mins and netherlands scored a goal | 22:04 |
| khalednasr | lambday, yeah it's getting really messy | 22:04 |
| lambday | khalednasr: ok taking a short break... may be some new ideas pop up in our heads | 22:05 |
| khalednasr | lambday, good idea :) | 22:06 |
| lambday | khalednasr: you're always the best in terms of finding out awesome solutions to these problems.. :D so let's think a bit | 22:06 |
| khalednasr | lambday, haha :) | 22:07 |
| -!- lisitsyn [~qdrgsm@80.252.20.67] has quit [Quit: Leaving.] | 22:18 | |
| lambday | khalednasr: how about we put these under linalg_traits? as in, inside our code we'd just be using linalg_traits<Module>::DMatrix... | 22:20 |
| lambday | which then would mean to inherit from the appropriate base matrix class (SGMatrix/CGPUMatrix) based on the module specific backend | 22:20 |
| lambday | inside the struct Module we use a typedef for that | 22:21 |
| lambday | possible? | 22:21 |
| lambday | there would always be a linalg_traits<Global>::DMatrix .... | 22:22 |
| khalednasr | lambday, inside which code? the algorithms? | 22:22 |
| lambday | khalednasr: yeah | 22:22 |
| lambday | I mean, having the complex definition for module specific setups, just hide it from the API via linalg_traits thing | 22:23 |
| khalednasr | and when one declares a matrix in some algorithm, what would that look like? | 22:23 |
| khalednasr | linalg_traits<Redux>::DMatrix ? | 22:24 |
| lambday | khalednasr: yeah... in each module, we write code for DMatrix defined for that module via this traits thing | 22:24 |
| lambday | then when cmake option is set for that module, it by default chooses to inherit from the necessary base | 22:25 |
| lambday | and using typedefs as much as we can to make the code readable | 22:26 |
| lambday | I mean, I cannot think of any other solution except having these matrix/vector classes set module specific :( because otherwise we're back to square one | 22:27 |
| khalednasr | lambday, seems like this could work. I'm just not sure if it won't cause some unforeseen problems later | 22:36 |
| lambday | khalednasr: neither can I... so I'd rather do a small prototype of this... just a small snippet of code that works with this... so that we can get a sense of what problems might be hidden in disguise | 22:39 |
| lambday | because many many problems actually reveals at the time of implementing it | 22:40 |
| khalednasr | yeah | 22:40 |
| -!- rajul [~rajul@182.68.184.120] has quit [Ping timeout: 240 seconds] | 22:44 | |
| -!- lisitsyn [~lisitsyn@37.139.2.75] has joined #shogun | 22:47 | |
| -!- lisitsyn1 [~qdrgsm@80.252.20.67] has joined #shogun | 22:49 | |
| -!- lisitsyn1 [~qdrgsm@80.252.20.67] has left #shogun [] | 22:50 | |
| -!- rajul [~rajul@180.151.18.31] has joined #shogun | 22:56 | |
| -!- lisitsyn [~lisitsyn@37.139.2.75] has quit [Quit: ZNC - http://znc.in] | 23:10 | |
| -!- lisitsyn [~lisitsyn@37.139.2.75] has joined #shogun | 23:10 | |
| -!- mode/#shogun [+o lisitsyn] by ChanServ | 23:10 | |
| -!- kislay [~Abhijeet@103.240.205.23] has quit [Quit: Leaving] | 23:10 | |
| -!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has quit [Ping timeout: 246 seconds] | 23:32 | |
| -!- jiaolong [9e6d1f01@gateway/web/freenode/ip.158.109.31.1] has quit [Quit: Page closed] | 23:56 | |
| --- Log closed Sun Jul 13 00:00:12 2014 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!