| --- Log opened Tue Jun 21 00:00:49 2016 | ||
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 00:13 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 00:13 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 01:49 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 01:56 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 01:56 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Remote host closed the connection] | 01:56 | |
| -!- OXPHOS [c68f0c0c@gateway/web/freenode/ip.198.143.12.12] has joined #shogun | 02:13 | |
| -!- OXPHOS [c68f0c0c@gateway/web/freenode/ip.198.143.12.12] has quit [Ping timeout: 250 seconds] | 02:37 | |
| -!- GandalfTheWizard [~Eva@112.10.171.169] has joined #shogun | 03:09 | |
| -!- Saurabh7 [~Saurabh7@117.248.211.162] has joined #shogun | 05:06 | |
| shogun-buildbot | build #25 of memleak - valgrind is complete: Failure [failed memory check] Build details are at http://buildbot.shogun-toolbox.org/builders/memleak%20-%20valgrind/builds/25 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 05:25 |
|---|---|---|
| shogun-buildbot | build #1026 of nightly_none is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_none/builds/1026 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 05:29 |
| -!- sonne|osx [~sonne@x4e358804.dyn.telefonica.de] has joined #shogun | 05:52 | |
| shogun-buildbot | build #1156 of nightly_default is complete: Failure [failed test test_1 notebooks] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1156 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 06:15 |
| shogun-buildbot | build #533 of deb1 - libshogun - PR is complete: Failure [failed cookbook] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun%20-%20PR/builds/533 blamelist: OXPHOS | 06:15 |
| shogun-buildbot | build #534 of deb1 - libshogun - PR is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun%20-%20PR/builds/534 | 06:15 |
| -!- sonne|osx [~sonne@x4e358804.dyn.telefonica.de] has quit [Quit: sonne|osx] | 06:40 | |
| -!- Saurabh7 [~Saurabh7@117.248.211.162] has quit [Read error: Connection reset by peer] | 08:11 | |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has joined #shogun | 08:26 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 08:31 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 08:31 | |
| -!- GandalfTheWizard [~Eva@112.10.171.169] has quit [Quit: Leaving.] | 09:09 | |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has quit [Ping timeout: 260 seconds] | 09:18 | |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 260 seconds] | 09:24 | |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has joined #shogun | 09:25 | |
| -!- sanuj [~sanuj@59.89.144.102] has joined #shogun | 10:30 | |
| -!- OXPHOS [c68f0c0c@gateway/web/freenode/ip.198.143.12.12] has joined #shogun | 10:30 | |
| sanuj | lisitsyn, what warning do you want for the %newobject PR? | 10:30 |
| sanuj | OXPHOS, hey, you are online? :o | 10:31 |
| OXPHOS | sanuj: hello:) I'm in China now | 10:32 |
| sanuj | OXPHOS, i see :) | 10:32 |
| OXPHOS | sanuj have to connect to irc via vpn ;( | 10:32 |
| sanuj | OXPHOS, where do you live in china? | 10:33 |
| OXPHOS | sanuj: in a city 300km to Beijing | 10:33 |
| lisitsyn | sanuj: say one wants to add another layer | 10:33 |
| lisitsyn | sanuj: we've got to warn people to update swig as well | 10:33 |
| sanuj | lisitsyn, you mean, if someone adds a new layer in NeuralNetwork.h then swig has to be also updated with %newobject? | 10:35 |
| lisitsyn | yes | 10:35 |
| sanuj | okay | 10:35 |
| sanuj | lisitsyn, did you talk to heiko about templates in swig | 10:35 |
| lisitsyn | sanuj: yeah but it is quite difficult anyway | 10:35 |
| sanuj | lisitsyn, he wants to merge tags first in the feature branch and then look at swig | 10:36 |
| lisitsyn | I agree | 10:36 |
| sanuj | i think the only thing missing are unit-test for any | 10:36 |
| sanuj | i can't make the coverage thing work | 10:36 |
| lisitsyn | details? | 10:37 |
| sanuj | lisitsyn, well heiko said wiking will update the cmakelist for coverage to work | 10:37 |
| sanuj | lisitsyn, he had asked me to try gconv | 10:38 |
| sanuj | but for that i need to compile the source code with some flags for gconv to work | 10:39 |
| sanuj | lisitsyn, here is the flag https://github.com/shogun-toolbox/shogun/blob/develop/CMakeLists.txt#L195 | 10:40 |
| sanuj | but i don't know what am i supposed to do after building with this flag | 10:41 |
| sanuj | and i think it does not work | 10:41 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 10:41 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 10:41 | |
| -!- lisitsyn is now known as bazdmeg | 11:00 | |
| bazdmeg | CAN'T TOUCH THIS | 11:01 |
| bazdmeg | shogun-buildbot: dance | 11:01 |
| shogun-buildbot | <(^.^<) | 11:01 |
| shogun-buildbot | <(^.^)> | 11:01 |
| shogun-buildbot | (>^.^)> | 11:01 |
| sanuj | haha | 11:01 |
| shogun-buildbot | (7^.^)7 | 11:01 |
| shogun-buildbot | (>^.^<) | 11:01 |
| sanuj | bazdmeg !!!! | 11:02 |
| bazdmeg | YOLO | 11:02 |
| -!- bazdmeg is now known as YOLO | 11:02 | |
| -!- YOLO is now known as bazdmeg | 11:02 | |
| sanuj | XD | 11:02 |
| sanuj | bazdmeg, aren't you in office? | 11:02 |
| bazdmeg | not yet | 11:03 |
| -!- [Chris] [~Chris]@deadtime.informatik.uni-tuebingen.de] has quit [Ping timeout: 276 seconds] | 11:03 | |
| sanuj | okay bazdmeg | 11:03 |
| sanuj | :D | 11:03 |
| -!- sanuj [~sanuj@59.89.144.102] has quit [Ping timeout: 250 seconds] | 11:35 | |
| @HeikoS | OXPHOS: hihi | 12:09 |
| OXPHOS | HeikoS: hey! | 12:11 |
| @HeikoS | OXPHOS: we are about to finish the linalg draft | 12:11 |
| @HeikoS | Ill send a link and you can check a bit | 12:11 |
| @HeikoS | we are in the final changes | 12:11 |
| @HeikoS | OXPHOS: sent you a pm | 12:11 |
| @HeikoS | let me know whether it wporked | 12:12 |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has joined #shogun | 12:12 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 12:12 | |
| OXPHOS | HeikoS: thx! checking | 12:12 |
| OXPHOS | lambday: hello | 12:12 |
| -!- sanuj [~sanuj@223.231.61.124] has joined #shogun | 12:14 | |
| @lambday | OXPHOS: hello! | 12:27 |
| @HeikoS | OXPHOS: sooooo | 12:29 |
| @HeikoS | we are done | 12:29 |
| @HeikoS | OXPHOS: shall we walk you through this a bit? | 12:29 |
| @HeikoS | OXPHOS: key points | 12:30 |
| OXPHOS | HeikoS: coooool! I'm thinking about some questions but plz go ahead | 12:30 |
| @HeikoS | 1.) runtime change of backend possible | 12:30 |
| @HeikoS | 2.) runtime addition of backend possible | 12:31 |
| @HeikoS | 3.) simple API | 12:31 |
| @HeikoS | 4.) GPU algorithms can always be executed on CPU backend if no GPU backend is available | 12:31 |
| @HeikoS | OXPHOS: you see, there is no #ifdefs or any backend specific code in SGVector or the base classes | 12:31 |
| @HeikoS | or the linalg methods, e.g. linalg::dot | 12:32 |
| @HeikoS | they all just call backends | 12:32 |
| @HeikoS | OXPHOS: so I will just point to some line numbers with a few comments | 12:32 |
| OXPHOS | yes | 12:32 |
| @HeikoS | line 10-19: use cases: how this is used from shogun algos | 12:32 |
| @HeikoS | should be pretty clear | 12:32 |
| @HeikoS | line 23ff: changes /additions to SGVector, we decided to putGPU memory things in there to make everything a bit more compact | 12:33 |
| @HeikoS | note it is only one constructor, and a new member in line 43 | 12:33 |
| OXPHOS | yep | 12:33 |
| @HeikoS | Also note: | 12:34 |
| @HeikoS | transfering to GPU always creates a NEW SGVector | 12:34 |
| @HeikoS | where the vector field is NULL, and gpu_vector is non-null | 12:34 |
| @HeikoS | transfering back as well | 12:34 |
| @HeikoS | ok, now a tricky one | 12:34 |
| @HeikoS | line 53 | 12:34 |
| @lambday | there can only be CPU data OR GPU data in SGVector.. not both at the same time.. | 12:34 |
| @lambday | this is to have the proper refcount | 12:35 |
| @HeikoS | OXPHOS: line 49ff is the backend base, that is, it defines all the methods that are implemented in sublcasses | 12:35 |
| @HeikoS | the subclasses can use eigen3/vienna/cuda, etc | 12:35 |
| @HeikoS | so the base class containts some virtual methods | 12:35 |
| @HeikoS | since we cannot template virtual methods (google it if you are confused), we need to explicitly write these methods for all types we want | 12:36 |
| @HeikoS | OXPHOS: we do this automatically via these macros | 12:36 |
| @HeikoS | please make sure you understand that :) | 12:36 |
| @HeikoS | OXPHOS: good? | 12:36 |
| OXPHOS | HeikoS: yes I got the idea..can work on details by myself | 12:36 |
| @HeikoS | OXPHOS: now check line 83ff, which defines the dot product | 12:37 |
| @HeikoS | you see, this thing checks whether both inputs live on gpu, and then calls gpu_backend's dot, otherwise cpu backend's dot | 12:37 |
| -!- sanuj [~sanuj@223.231.61.124] has quit [Read error: Connection reset by peer] | 12:37 | |
| @HeikoS | again, there is NO #ifdef/Vienna or whatsoever | 12:37 |
| @HeikoS | so it is possible to change the pointer that get_gpu_backend() returns at runtime | 12:38 |
| @HeikoS | same for cpu | 12:38 |
| OXPHOS | sure onGPU() == registered | 12:38 |
| @HeikoS | OXPHOS: on_gpu == to_gpu() was called | 12:38 |
| @HeikoS | i.e. the SGVector memory lives on GPU | 12:38 |
| @HeikoS | registered == get_gpu_backend() != NULL | 12:38 |
| @HeikoS | see e.g. line 095 | 12:39 |
| @HeikoS | 95 | 12:39 |
| @HeikoS | it checks whether the GPU backend is available | 12:39 |
| @HeikoS | and then transfers | 12:39 |
| @HeikoS | if not, doesnt transfer | 12:39 |
| @HeikoS | so in dot in line 83, we know that vector.on_gpu() is true, there *is* a backend registered | 12:39 |
| @HeikoS | OXPHOS: the backend pointers are stored in line 127ff | 12:40 |
| @HeikoS | OXPHOS: and then we wrote some mini example backend implementations in eigen3 and Vienna | 12:40 |
| @HeikoS | line 137ff | 12:40 |
| @HeikoS | not again, that we are overloading virtual methods, so we cannot template but need to use this macro trick | 12:40 |
| @HeikoS | the actual code for dot product is in line 154ff | 12:41 |
| @HeikoS | for eigen case | 12:41 |
| @HeikoS | OXPHOS: so far so good, please let us know any questions you have | 12:41 |
| @HeikoS | OXPHOS: now the plan | 12:41 |
| @HeikoS | OXPHOS: this needs to be implemented before midterm next week. that is this week | 12:42 |
| @HeikoS | OXPHOS: as we drafted most thing, it should be just a matter of translating this into compiling code | 12:42 |
| @HeikoS | so a week is more than enough I think | 12:42 |
| @HeikoS | should only take 2 days, so if you get stuck, ask us immediately | 12:42 |
| @HeikoS | it is a good goal for midterm to have this done | 12:42 |
| @HeikoS | in feature branch | 12:42 |
| @HeikoS | OXPHOS: thoughts? | 12:43 |
| OXPHOS | HeikoS: sure! make sense | 12:43 |
| @HeikoS | OXPHOS: ok then, make sure you understand every line of this draft | 12:43 |
| @HeikoS | OXPHOS: and also, more importantly, the high level idea | 12:43 |
| @HeikoS | i.e. the 4 points I started with | 12:43 |
| @HeikoS | at 11:29 | 12:43 |
| OXPHOS | yep that is clear | 12:44 |
| @HeikoS | OXPHOS: ok then | 12:44 |
| @HeikoS | I also suggest: we start a new feature branch | 12:44 |
| OXPHOS | thinking about the ref_counts of to_GPU() but no gpu backend - should be a shallow copy? | 12:44 |
| @HeikoS | OXPHOS: check line | 12:45 |
| @HeikoS | 104 | 12:45 |
| @lambday | to_gpu creates a new SGVector with ref-count 0 | 12:45 |
| @HeikoS | it returns the same vector | 12:45 |
| @HeikoS | lambday: no new vector | 12:45 |
| @lambday | oh if no gpu backend, same vector | 12:45 |
| @HeikoS | OXPHOS: same in line 117 | 12:46 |
| @HeikoS | OXPHOS: so lambday will create a branch for you | 12:46 |
| @HeikoS | spawned from develop | 12:46 |
| @HeikoS | and then the order of things to be added should be | 12:46 |
| @HeikoS | 1.) SGVector changes / additions | 12:46 |
| @HeikoS | 2.) base classes of backend and memory | 12:47 |
| @HeikoS | sorry, actually | 12:47 |
| @HeikoS | 1.) gpu memory base class | 12:47 |
| @HeikoS | 2.) SGVector changes | 12:47 |
| @HeikoS | 3.) LinalgBackendBase | 12:47 |
| @HeikoS | (with to_gpu and from_gpu first) | 12:47 |
| @HeikoS | 4.) add dot to LinalgBackendBase | 12:48 |
| @HeikoS | 5. add subclasses for eigen3 and vienna | 12:48 |
| @HeikoS | 6. unit test for dot and to/from_gpu | 12:48 |
| @HeikoS | 7. polish | 12:48 |
| @HeikoS | 8. refactor old methods | 12:48 |
| OXPHOS | I see | 12:48 |
| @HeikoS | 8 takes time | 12:49 |
| @HeikoS | so that we can do next week | 12:49 |
| @HeikoS | but 1-7 is quite simple with this draft | 12:49 |
| @HeikoS | so this week it should have priority over anything else | 12:49 |
| @HeikoS | OXPHOS: cool then | 12:50 |
| @HeikoS | I gotta go | 12:50 |
| OXPHOS | HeikoS: sure! ready to work | 12:50 |
| @HeikoS | OXPHOS: just ask if anything is unclear, it took us a while to figure this out ourselves ;) | 12:50 |
| OXPHOS | HeikoS: np. thx! | 12:50 |
| Saurabh7 | HeikoS, yo | 12:51 |
| @HeikoS | Saurabh7: hi! | 12:51 |
| @HeikoS | Sorry, I have to leave soon, you still there in a few hours? | 12:51 |
| Saurabh7 | HeikoS, rre | 12:51 |
| Saurabh7 | ok i wll be here | 12:51 |
| @HeikoS | Saurabh7: cool, thanks! | 12:52 |
| Saurabh7 | I will write a mail ? | 12:52 |
| @HeikoS | yes good! :) | 12:52 |
| Saurabh7 | k | 12:52 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 12:55 | |
| -!- sanuj [~sanuj@223.231.59.248] has joined #shogun | 12:58 | |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has quit [Ping timeout: 260 seconds] | 13:00 | |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has joined #shogun | 13:12 | |
| -!- sanuj [~sanuj@223.231.59.248] has quit [Ping timeout: 276 seconds] | 13:18 | |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has quit [Quit: Leaving] | 13:24 | |
| -!- sanuj [~sanuj@117.203.16.252] has joined #shogun | 13:39 | |
| -!- OXPHOS [c68f0c0c@gateway/web/freenode/ip.198.143.12.12] has quit [Ping timeout: 250 seconds] | 14:02 | |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [Quit: Page closed] | 14:19 | |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has joined #shogun | 14:31 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 14:31 | |
| @lambday | bazdmeg: | 14:32 |
| bazdmeg | bazdmeg | 14:32 |
| bazdmeg | lambday: what's up | 14:32 |
| @lambday | bazdmeg: you know any other one? | 14:32 |
| bazdmeg | bazdmeg? | 14:32 |
| @lambday | suggest me something in russian | 14:32 |
| @lambday | oh wait | 14:32 |
| bazdmeg | lambday: blyad | 14:32 |
| @lambday | i think i remember | 14:32 |
| -!- lambday is now known as blyad | 14:33 | |
| bazdmeg | lambday: although this is not really good for you | 14:33 |
| -!- sanuj [~sanuj@117.203.16.252] has quit [Ping timeout: 260 seconds] | 14:33 | |
| @blyad | what's blyad ? | 14:33 |
| bazdmeg | blyad: bitch! sorry :D | 14:33 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has joined #shogun | 14:33 | |
| @blyad | haha | 14:33 |
| bazdmeg | blyad: use ebat | 14:33 |
| bazdmeg | this is bazdmeg | 14:33 |
| -!- blyad is now known as bitch | 14:33 | |
| @bitch | oh fuck this is already registered | 14:33 |
| -!- bitch is now known as ebat | 14:33 | |
| @ebat | bazdmeg: you saw the design? | 14:34 |
| @ebat | with macro? | 14:34 |
| bazdmeg | ebat: yes this is what I suggested | 14:35 |
| bazdmeg | yesterday | 14:35 |
| @ebat | alright | 14:35 |
| bazdmeg | when Heiko tried to bazdmeg my brains out | 14:35 |
| bazdmeg | :D | 14:35 |
| c4goldsw | Lol who are you guys bazdmeg ebat? | 14:35 |
| @ebat | we both were pretty bazdmeg-ged for last 2 days with this thing! | 14:35 |
| bazdmeg | yeah bazdmegged out | 14:35 |
| @ebat | c4goldsw: surprise! :D | 14:36 |
| c4goldsw | okay I have better things to do time to work | 14:36 |
| @ebat | haha | 14:36 |
| -!- TanNguyen [~dra@89.162.139.29] has joined #shogun | 14:41 | |
| -!- sanuj [~sanuj@117.204.249.63] has joined #shogun | 15:09 | |
| -!- ebat [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [Ping timeout: 250 seconds] | 15:13 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 15:50 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 15:50 | |
| -!- sanuj [~sanuj@117.204.249.63] has quit [Ping timeout: 252 seconds] | 16:28 | |
| -!- sanuj [~sanuj@117.204.249.63] has joined #shogun | 16:29 | |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has joined #shogun | 16:59 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 16:59 | |
| -!- HeikoS [~heiko@nat-161-217.internal.eduroam.ucl.ac.uk] has joined #shogun | 17:00 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 17:00 | |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 17:05 | |
| shogun-notifier- | shogun: lambday :develop * 5f4b032 / / (6 files): https://github.com/shogun-toolbox/shogun/commit/5f4b0320b1941757d9101bc5a36a4c6ef8edd0e5 | 17:05 |
| shogun-notifier- | shogun: Refactored EuclideanDistance to work with any CDotFeatures | 17:05 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 616b4f9 / / (6 files): https://github.com/shogun-toolbox/shogun/commit/616b4f93769ad98dbd646d5696ac4261da609308 | 17:05 |
| shogun-notifier- | shogun: Merge pull request #3295 from lambday/develop | 17:05 |
| shogun-notifier- | shogun: | 17:05 |
| shogun-notifier- | shogun: Refactored EuclideanDistance to work with any CDotFeatures | 17:06 |
| bazdmeg | uhmm bazdmeg | 17:07 |
| shogun-buildbot | build #733 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/733 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com> | 17:07 |
| @HeikoS | bazdmeg: bazdmeg!!! | 17:10 |
| @HeikoS | bazdmeg: what about sanuj 's PR? | 17:11 |
| @HeikoS | its getting out of controll | 17:11 |
| @HeikoS | can we please merge things before starting to work on swig? | 17:11 |
| bazdmeg | like everything around us | 17:11 |
| bazdmeg | yes | 17:11 |
| bazdmeg | please | 17:11 |
| @HeikoS | sanuj: lets merge the tag parts | 17:11 |
| @HeikoS | and then have a new (small!) PR for swig addition | 17:11 |
| sanuj | HeikoS sure sure | 17:12 |
| @HeikoS | bazdmeg: can we merge things into develop? | 17:12 |
| @HeikoS | tags | 17:12 |
| sanuj | bazdmeg!!! | 17:12 |
| @HeikoS | or does that break things? | 17:12 |
| @HeikoS | like is it additions? | 17:12 |
| @HeikoS | or deep changes? | 17:12 |
| bazdmeg | sorry I am out of touch for a few hours | 17:12 |
| @HeikoS | out of touch? | 17:13 |
| @HeikoS | next hours or last? :) | 17:13 |
| @HeikoS | bazdmeg: what is this badzmeg??? | 17:13 |
| sanuj | HeikoS, inspired from wiking | 17:13 |
| sanuj | i guess | 17:13 |
| @HeikoS | sanuj: ok then, I can merge | 17:13 |
| @HeikoS | it is a feature branch so all good | 17:13 |
| @HeikoS | sanuj: lets stripe this down to minimal size that passes the build | 17:14 |
| @HeikoS | but obviously keep your changes | 17:14 |
| sanuj | okay, i'll shift it to new branch (swig stuff) | 17:14 |
| shogun-notifier- | shogun-data: OXPHOS :master * 403ddb0 / testsuite/meta/binary_classifier/linear_svm.dat: https://github.com/shogun-toolbox/shogun-data/commit/403ddb0e0e6021ce23809e2b1ac12b7127b5de5d | 17:15 |
| shogun-notifier- | shogun-data: add linear_svm test dataset | 17:15 |
| shogun-notifier- | shogun-data: Heiko Strathmann :master * eba3fbe / testsuite/meta/binary_classifier/linear_svm.dat: https://github.com/shogun-toolbox/shogun-data/commit/eba3fbef0c7c116329ac8c39fcb142882763d0d1 | 17:15 |
| shogun-notifier- | shogun-data: Merge pull request #105 from OXPHOS/temp | 17:15 |
| shogun-notifier- | shogun-data: | 17:15 |
| shogun-notifier- | shogun-data: add linear_svm test dataset | 17:15 |
| shogun-notifier- | shogun-data: OXPHOS :master * 3e214f1 / testsuite/meta/ (20 files): https://github.com/shogun-toolbox/shogun-data/commit/3e214f1bde50fcc224fddd06523db3fa69bfc54e | 17:16 |
| shogun-notifier- | shogun-data: separate classifiers | 17:16 |
| shogun-notifier- | shogun-data: Heiko Strathmann :master * ca2c244 / testsuite/meta/ (20 files): https://github.com/shogun-toolbox/shogun-data/commit/ca2c24429cfe9539adab012c8c118b355b8ed36a | 17:16 |
| shogun-notifier- | shogun-data: Merge pull request #104 from OXPHOS/master | 17:16 |
| shogun-notifier- | shogun-data: | 17:16 |
| shogun-notifier- | shogun-data: separate classifiers | 17:16 |
| sanuj | HeikoS, can i put intermediate commits on a separate branch? | 17:24 |
| @HeikoS | sanuj: what do you mean? | 17:24 |
| sanuj | like i have more commits after the swig commits | 17:24 |
| shogun-notifier- | shogun-data: Saurabh7 :master * af30f7a / testsuite/meta/classifier/random_forest.dat: https://github.com/shogun-toolbox/shogun-data/commit/af30f7adf4e3d72c7e9f201528d1fff38457fd7f | 17:25 |
| shogun-notifier- | shogun-data: rf data | 17:25 |
| shogun-notifier- | shogun-data: Heiko Strathmann :master * 7b23694 / testsuite/meta/classifier/random_forest.dat: https://github.com/shogun-toolbox/shogun-data/commit/7b23694342c8954f470da3a861511ed4465a6ced | 17:25 |
| shogun-notifier- | shogun-data: Merge pull request #106 from Saurabh7/rfdata | 17:25 |
| shogun-notifier- | shogun-data: | 17:25 |
| shogun-notifier- | shogun-data: rf data | 17:25 |
| sanuj | but i want to keep the commits that are after swig commits on the same branch | 17:25 |
| sanuj | and move the intermediate swig commits on a different branch | 17:25 |
| @HeikoS | sanuj: yes | 17:25 |
| @HeikoS | git-cherry-pick | 17:26 |
| sanuj | okay | 17:26 |
| -!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Quit: Leaving.] | 17:26 | |
| @HeikoS | allows you to grasp any commit to the current branch | 17:26 |
| @HeikoS | google it | 17:26 |
| @HeikoS | better make a backup before you start | 17:26 |
| sanuj | okay | 17:27 |
| @HeikoS | but its easy | 17:27 |
| @HeikoS | to use | 17:28 |
| -!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun | 17:32 | |
| @HeikoS | bazdmeg: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | 17:49 |
| @HeikoS | bazdmeg: I had to remove your wrap | 17:51 |
| @HeikoS | broke too many things | 17:51 |
| @HeikoS | gotta do that properly | 17:51 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 340d1ce / examples/meta/generator/generate.py: https://github.com/shogun-toolbox/shogun/commit/340d1ce426c13cfae6d09edc23126dccc5f04e69 | 17:53 |
| shogun-notifier- | shogun: raise exception after all | 17:53 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 35f902d / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/35f902db29b14145f890847759a2a155373806fd | 17:53 |
| shogun-notifier- | shogun: remove wrap as it hinders other things, gotta do that properly | 17:53 |
| shogun-buildbot | build #734 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/734 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 17:54 |
| bazdmeg | HeikoS: ? | 18:01 |
| bazdmeg | ??? how can that break anythngi | 18:03 |
| shogun-notifier- | shogun: Heiko Strathmann :feature/meta_vector_matrix * b00b20f / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/b00b20fcef6177a6b203789bd13f60fb6c5e8f72 | 18:08 |
| shogun-notifier- | shogun: add matrix and vector types for cpp | 18:08 |
| shogun-notifier- | shogun: Heiko Strathmann :feature/meta_vector_matrix * 5850ba3 / examples/meta/generator/targets/cpp.json: https://github.com/shogun-toolbox/shogun/commit/5850ba357df06a2d13d5c298d332aeebc683a97b | 18:08 |
| shogun-notifier- | shogun: added long real vector and matrix | 18:08 |
| shogun-notifier- | shogun: Heiko Strathmann :feature/meta_vector_matrix * 4726424 / examples/meta/src/tests/matrix_types.sg,examples/meta/src/tests/vector_types.sg: https://github.com/shogun-toolbox/shogun/commit/47264241deccf88f12b35b7b04b3cac953a6b3fa | 18:08 |
| shogun-notifier- | shogun: meta example tests for vector and matrix types | 18:08 |
| @HeikoS | besser82: joooo | 18:09 |
| c4goldsw | HeikoS ello | 18:12 |
| @HeikoS | c4goldsw: jo | 18:12 |
| c4goldsw | I have more questions in regards to the CRegressionLabels - specifically, how they're used in LARs. Once that's sorted, I should be able to submit a PR. | 18:13 |
| c4goldsw | You said that for our purposes, when doing regression y would be in R. | 18:14 |
| c4goldsw | CRegressionLabels only returns values in float64, and it can't be templated | 18:15 |
| @HeikoS | ok | 18:15 |
| c4goldsw | Hold on | 18:15 |
| c4goldsw | It's taking me a while to type | 18:15 |
| @HeikoS | dont worry | 18:15 |
| c4goldsw | I'll mention your name when I'm done | 18:16 |
| @HeikoS | okok :) | 18:16 |
| c4goldsw | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/regression/LeastAngleRegression.cpp#L130 | 18:17 |
| c4goldsw | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/regression/LeastAngleRegression.cpp#L150 | 18:17 |
| c4goldsw | So, even though I've templated things related to CDenseFeatures, the second line shows where the a generic eigen map and a float64 eigen map are multiplied | 18:18 |
| c4goldsw | What can be done about this? One solution is to template CRegressionLabels, but this would only be suitable for things R. This also leads to the question of whether you'd want this to work for int32 / 64, which is also in R but can run into problems as they can't store fractional parts | 18:19 |
| c4goldsw | So HeikoS, what do you recommend? | 18:19 |
| c4goldsw | I could also cast the eigen map into float64 | 18:20 |
| c4goldsw | On line 150 | 18:20 |
| c4goldsw | Which actually seems like a decent solution | 18:22 |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has joined #shogun | 18:24 | |
| @HeikoS | ok hi | 18:27 |
| @HeikoS | c4goldsw: let me see | 18:27 |
| Saurabh7 | HeikoS, yo | 18:27 |
| c4goldsw | On second thoughts the casting won't work | 18:28 |
| @HeikoS | c4goldsw: soooo | 18:28 |
| @HeikoS | as said yesterday, the first step would be | 18:28 |
| @HeikoS | to accept any CDeanseFeatures<T> as input | 18:28 |
| @HeikoS | no need to template the LARS class itself | 18:29 |
| @HeikoS | right? | 18:29 |
| c4goldsw | Done | 18:29 |
| @HeikoS | because the input data is what counts | 18:29 |
| c4goldsw | yes, that was clear | 18:29 |
| @HeikoS | ok | 18:29 |
| @HeikoS | so for labels | 18:29 |
| @HeikoS | I am not sure what you want to do | 18:29 |
| @HeikoS | I mean labels can just be 64 bit, as there are not that many of them | 18:30 |
| @HeikoS | c4goldsw: so I guess a first step (patch) is just to get rid of the float64_t in CDenseFeatures | 18:30 |
| @HeikoS | and just leave labels as they are | 18:30 |
| @HeikoS | does that make sense? | 18:30 |
| @HeikoS | Saurabh7: jo! | 18:30 |
| c4goldsw | Yes | 18:31 |
| @HeikoS | c4goldsw: so when you are saying that is done | 18:31 |
| @HeikoS | can you share a pr? | 18:31 |
| @HeikoS | to discuss? | 18:31 |
| Saurabh7 | HeikoS, jst saw mails, sending the data again | 18:31 |
| @HeikoS | I think we could change the labels to be templated as well | 18:31 |
| @HeikoS | but not sure whether that is worth the effort | 18:31 |
| @HeikoS | matrices is where it matters | 18:32 |
| @HeikoS | and regression labels are always R anyways | 18:32 |
| @HeikoS | it is just whether they are 32 or 64 bit | 18:32 |
| @HeikoS | c4goldsw: so you just need to do something like | 18:32 |
| @HeikoS | typedef Eigen::Matrix<T, -1, -1> MatrixXT; | 18:33 |
| @HeikoS | and then do Map<MatrixXT>(feats->get_feature_matrix(), num_feats, num_vectors) | 18:33 |
| c4goldsw | That's been done :) | 18:34 |
| @HeikoS | cool | 18:34 |
| @HeikoS | then send the PR :) | 18:34 |
| c4goldsw | But I'm still a little uncertain about how to proceed because of line 150 | 18:34 |
| @HeikoS | and add a test where you make it work with float32 features | 18:35 |
| @HeikoS | checking | 18:35 |
| @HeikoS | map_Xy=map_Xr*map_y; | 18:35 |
| @HeikoS | this one? | 18:35 |
| c4goldsw | Yes. The problem is that map_y is in float_64, whilst map_Xr is templated | 18:35 |
| c4goldsw | That was what I was asking about | 18:35 |
| c4goldsw | Or rather | 18:36 |
| @HeikoS | ah yes | 18:36 |
| @HeikoS | of course | 18:36 |
| @HeikoS | sorry | 18:36 |
| c4goldsw | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/regression/LeastAngleRegression.cpp#L130 | 18:36 |
| c4goldsw | THAT is the problem | 18:36 |
| @HeikoS | well ok | 18:36 |
| c4goldsw | get_lables returns float64 vectors | 18:36 |
| @HeikoS | labels are not changed | 18:36 |
| @HeikoS | only read | 18:37 |
| @HeikoS | so you can create a copy | 18:37 |
| @HeikoS | in the right memory length | 18:37 |
| @HeikoS | let me ask lambday | 18:37 |
| c4goldsw | HeikoS: Or, if you go back to line 150, I could just cast map_Xr to float64 then right? | 18:37 |
| c4goldsw | Because the values are only read, so there would really be no change. | 18:38 |
| c4goldsw | I could cast by doing this on to eigen matrix: http://stackoverflow.com/questions/23946658/error-mixing-types-with-eigen-matrices | 18:38 |
| @HeikoS | lambday is of the opinion that this works | 18:39 |
| @HeikoS | and should just give double | 18:40 |
| @HeikoS | or do you get a compile error? | 18:40 |
| c4goldsw | That what works? The casting idea? | 18:40 |
| @HeikoS | nope sorry | 18:40 |
| @HeikoS | misunderstanding | 18:40 |
| sanuj | HeikoS, i have updated the tags PR and squashed my commits https://github.com/shogun-toolbox/shogun/pull/3221 | 18:41 |
| @HeikoS | c4goldsw: ok the solution is | 18:44 |
| @HeikoS | to add template methods to CLabels | 18:44 |
| @HeikoS | get_labels<T> | 18:44 |
| @HeikoS | this is very similar to CKernel::get_kernel_matrix() | 18:45 |
| c4goldsw | checking that method now | 18:45 |
| @HeikoS | you need to add templated methods get_labels<T>() | 18:45 |
| @HeikoS | and those will return a *copy* of the 64bit labels | 18:45 |
| @HeikoS | for all cases but for float64_t | 18:46 |
| @HeikoS | so that is ONE option | 18:46 |
| @HeikoS | the other one is to template labels | 18:46 |
| @HeikoS | just discussing here | 18:46 |
| @HeikoS | I tend toward the copy | 18:47 |
| @HeikoS | so CLabels::get_labels<float32_t>() | 18:47 |
| @HeikoS | and in there, you do | 18:47 |
| @HeikoS | SGVector<T> labels_copy(num_labels); | 18:48 |
| @HeikoS | for (i in range(num_labels)) { labels_copy[i] = labels[i]; } | 18:48 |
| @HeikoS | something like that | 18:48 |
| @HeikoS | then in the LARS | 18:48 |
| @HeikoS | you call that templated method, that now works with a copy of the labels in 32bit width | 18:48 |
| @HeikoS | sanuj: checking | 18:48 |
| c4goldsw | Hmm, okay | 18:49 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 276 seconds] | 18:49 | |
| c4goldsw | HeikoS: Is it a problem that the labels aren't float64_t? This goes back to my question yesterday of how the labels are used | 18:49 |
| c4goldsw | What if the type we're using for LARs is an int type? | 18:50 |
| @HeikoS | c4goldsw: doesnt make sense | 18:50 |
| c4goldsw | Which can't store fractional parts? | 18:50 |
| c4goldsw | Ah ok | 18:50 |
| @HeikoS | I mean the data can be int | 18:50 |
| c4goldsw | Good. That clears up my understanding | 18:50 |
| @HeikoS | but inside LARS the X*y result needs to be float | 18:51 |
| c4goldsw | HeikoS: Okay, it's good to hear that. When I tried to compile with float64, the class compiles but this error occurs: https://gist.github.com/c4goldsw/a9862903e3bec5be0f09b002bc1b9f6a | 18:53 |
| @HeikoS | there it appears to me that you templated the LARS class | 18:54 |
| @HeikoS | without instantiating the templates | 18:54 |
| @HeikoS | so you need to instantiate the templates to get rid of that | 18:54 |
| @HeikoS | BUT | 18:54 |
| @HeikoS | this is not what we discussed | 18:54 |
| @HeikoS | it makes no sense to template the LARS class itself | 18:55 |
| @HeikoS | we cannot template every algorithm in shogun | 18:55 |
| @HeikoS | explosion of classes | 18:55 |
| @HeikoS | we just want it to work with all template versions for CDesneFeatures | 18:55 |
| c4goldsw | To be more specific, I was just compiling with the instatiation of LARS<float64> | 18:56 |
| c4goldsw | HeikoS in fact here, this is what I have: https://gist.github.com/c4goldsw/fd325503b9b81a2a7f434291732e19e0 | 18:57 |
| c4goldsw | Go to the bottom, I've instatiated LARS<float64_t> at the bottom | 18:57 |
| @HeikoS | CLeastAngleRegression<ST> | 18:58 |
| @HeikoS | you dont want that | 18:58 |
| @HeikoS | you just want CLeastAngleRegression | 18:58 |
| @HeikoS | which deals with CDenseFeatures<T> | 18:58 |
| c4goldsw | Now this is all clear | 18:58 |
| @HeikoS | rather than only CDenseFeatures<float64_t> | 18:58 |
| c4goldsw | So I just need to template the methods that use CDenseFeatures | 18:58 |
| c4goldsw | Right? | 18:58 |
| c4goldsw | Rather than the entire class | 18:58 |
| @HeikoS | yes the helper methods you can template | 18:58 |
| @HeikoS | as they take SGMatrix<T> | 18:58 |
| c4goldsw | Great, that makes sense. Sorry for the misunderstanding | 18:59 |
| @HeikoS | oh and use a typedef for the Eigen::Matrix<T,-1,-1> | 18:59 |
| @HeikoS | no worries | 18:59 |
| @HeikoS | c4goldsw: so my thinking is this: | 19:00 |
| c4goldsw | I was going to do that, I know it's messy / hard to read | 19:00 |
| @HeikoS | modular interfaces dont do templates | 19:00 |
| @HeikoS | python e.g. | 19:00 |
| @HeikoS | there is no template | 19:00 |
| @HeikoS | so we translate templated type as | 19:00 |
| @HeikoS | RealFeatures | 19:00 |
| @HeikoS | LongRealFeatures | 19:00 |
| @HeikoS | IntFeatures | 19:00 |
| @HeikoS | ShortFeatures | 19:00 |
| @HeikoS | ByteFeatures | 19:00 |
| @HeikoS | etc etc | 19:00 |
| @HeikoS | that means 10 new interface types for every templated class | 19:00 |
| @HeikoS | so we want to keep this down | 19:00 |
| @HeikoS | and only template stuff that really needs to be | 19:01 |
| @HeikoS | algorithm classes dont need to be | 19:01 |
| @HeikoS | they just need to be able to deal with features that are templated, but this happens all inside | 19:01 |
| c4goldsw | Good, that makes sense | 19:01 |
| @HeikoS | c4goldsw: cool | 19:01 |
| @HeikoS | c4goldsw: so the tldr is | 19:01 |
| @HeikoS | you want to get rid of | 19:01 |
| @HeikoS | CDenseFeatures<float64_t> feats = (CDenseFeatures<float64_t>*) m_feats | 19:02 |
| shogun-notifier- | shogun: lambday :develop * d43c1cd / src/shogun/distance/EuclideanDistance.cpp: https://github.com/shogun-toolbox/shogun/commit/d43c1cd3a78a76c26de3d8ede832b024a4396264 | 19:03 |
| shogun-notifier- | shogun: fix uninitialized memory read error in CEuclideanDistance and a typo | 19:03 |
| shogun-notifier- | shogun: Soumyajit De :develop * 1fede5d / src/shogun/distance/EuclideanDistance.cpp: https://github.com/shogun-toolbox/shogun/commit/1fede5d95e70fc6eb05b494848ceb786bffb2754 | 19:03 |
| shogun-notifier- | shogun: Merge pull request #3307 from lambday/feature/euclidean_refactor_bugfix | 19:03 |
| shogun-notifier- | shogun: | 19:03 |
| shogun-notifier- | shogun: fix uninitialized memory read error in CEuclideanDistance and a typo | 19:03 |
| shogun-buildbot | build #735 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/735 blamelist: lambday <heavensdevil6909@gmail.com> | 19:04 |
| sanuj | HeikoS, can you also see https://github.com/shogun-toolbox/shogun/pull/3299? | 19:04 |
| shogun-buildbot | build #736 of trusty - libshogun - viennacl is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/736 blamelist: Soumyajit De <heavensdevil6909@gmail.com> | 19:05 |
| @HeikoS | sanuj: question | 19:06 |
| c4goldsw | HeikoS alright, this also makes sense now (I know that's starting to sound like a stock phrase but really, it does). Thanks for the help. I should have the PR in by tomorrow | 19:06 |
| @HeikoS | c4goldsw: cool! | 19:06 |
| @HeikoS | sanuj: so CSGObject::set | 19:06 |
| c4goldsw | Addios | 19:06 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 19:06 | |
| @HeikoS | returns what it got if there was nothing before, otherwise returns the thing that was there before | 19:06 |
| @HeikoS | why? | 19:06 |
| sanuj | HeikoS, bazdmeg told me to do so.....to indicate whether a parameter with a particular name already exists | 19:07 |
| @HeikoS | sanuj: what is the use case? | 19:07 |
| sanuj | i mean ==> is a parameter being overwritten? | 19:07 |
| @HeikoS | why not boolean? | 19:07 |
| @HeikoS | why the value? | 19:08 |
| @HeikoS | bazdmeg: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | 19:08 |
| @HeikoS | what is this bazdmeg??? | 19:08 |
| @HeikoS | #haha | 19:08 |
| @HeikoS | no, seriously, I dont get it | 19:08 |
| sanuj | bazdmeg !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | 19:08 |
| @HeikoS | put a comment in the PR :) | 19:08 |
| @HeikoS | reading more of it | 19:08 |
| sanuj | HeikoS, it returns the overwritten value | 19:08 |
| sanuj | if the user wants to save it somewhere | 19:09 |
| @HeikoS | then the user should call get | 19:09 |
| @HeikoS | in this case, user needs to do a comparison between argument passed and result returned, and the decide to store if they are different | 19:09 |
| sanuj | ask bazdmeg :D | 19:09 |
| @HeikoS | this is slightly ridiulous | 19:09 |
| @HeikoS | nono | 19:09 |
| @HeikoS | sanuj: its your project :D | 19:10 |
| @HeikoS | so I ask you | 19:10 |
| sanuj | :D | 19:10 |
| @HeikoS | you should have an opinion on this | 19:10 |
| sanuj | I'm not sure | 19:10 |
| sanuj | HeikoS, i think when we added this we didn't have has() and hastype() | 19:11 |
| @HeikoS | actually | 19:11 |
| @HeikoS | make it void | 19:11 |
| @HeikoS | user should check himself | 19:11 |
| @HeikoS | whether there is already something | 19:11 |
| @HeikoS | just use has | 19:11 |
| @HeikoS | and then get | 19:11 |
| @HeikoS | if interested in storing | 19:12 |
| @HeikoS | needs to be known at compile time anyways | 19:12 |
| @HeikoS | so point | 19:12 |
| sanuj | HeikoS, i'll make it void right now and update it | 19:13 |
| @HeikoS | sanuj: ok next question >:D | 19:14 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/pull/3221/files#diff-18b103056d529e1098553c5512d7b1d9R104 | 19:14 |
| @HeikoS | sanuj: why this? | 19:14 |
| @HeikoS | does every BaseTag have a hash? | 19:14 |
| @HeikoS | or sometimes only string? | 19:14 |
| @HeikoS | so why do you compare the strings? | 19:15 |
| sanuj | HeikoS, every BaseTag has a hash | 19:15 |
| @HeikoS | operator== is called all the time, e.g. for every get | 19:16 |
| @HeikoS | string comparisons cost | 19:16 |
| @HeikoS | so I think string comparison should go | 19:16 |
| @HeikoS | and only compare hash | 19:16 |
| @HeikoS | string is just for user to identify | 19:16 |
| @HeikoS | readability | 19:16 |
| sanuj | HeikoS, nice suggestion | 19:17 |
| @HeikoS | sanuj: minor: why do you use name_ and _name | 19:17 |
| @HeikoS | any conflict? | 19:17 |
| @HeikoS | which one? | 19:17 |
| sanuj | HeikoS, 'name' raises warnings | 19:18 |
| @HeikoS | we call members m_name | 19:18 |
| @HeikoS | m_member_variable | 19:18 |
| @HeikoS | what warning? | 19:18 |
| @HeikoS | "shadows a member of this"? | 19:18 |
| sanuj | HeikoS, yep | 19:18 |
| sanuj | name() | 19:18 |
| sanuj | i'll change it to m_name | 19:18 |
| @HeikoS | m_name then for member please | 19:18 |
| Saurabh7 | HeikoS, you had some ideas about making multicore ? | 19:19 |
| @HeikoS | Saurabh7: yeah | 19:19 |
| @HeikoS | Saurabh7: lets discuss in 5min | 19:20 |
| @HeikoS | sanuj: another one :) | 19:21 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/pull/3221/files#diff-8cfacc7a0d1355252c12528031d690b5R333 | 19:21 |
| @HeikoS | this "training data" | 19:21 |
| @HeikoS | I dont see why users/devs should be allowed to just add new parameters to instances | 19:22 |
| @HeikoS | but rather we only want to allow to change parameters that are registered in the class itself, right? | 19:22 |
| @HeikoS | with SG_ADD | 19:22 |
| sanuj | HeikoS, you want them to add parameters with fixed names? | 19:23 |
| @HeikoS | but SG_ADD is not there yet, so I guess we can't test otherwise | 19:23 |
| @HeikoS | sanuj: yeah of course | 19:23 |
| @HeikoS | sanuj: like SG_ADD | 19:23 |
| @HeikoS | only those parameters should be possible to add | 19:23 |
| @HeikoS | so to reproduce the unit test you did there, you need to create a mock object | 19:23 |
| @HeikoS | where you in the constructor add a tag parameter | 19:23 |
| @HeikoS | and then we set this in the test | 19:23 |
| @HeikoS | sanuj: understand that? | 19:23 |
| @HeikoS | sanuj: I will explain in PR | 19:25 |
| sanuj | HeikoS, i seeeeeeeeee | 19:33 |
| sanuj | :) | 19:34 |
| sanuj | HeikoS, i need to discuss this with bazdmeg | 19:35 |
| sanuj | HeikoS, why didn't you tell me all this last week when you reviewed the same PR?? | 19:36 |
| @HeikoS | sanuj: I just put a little draft for a test | 19:39 |
| @HeikoS | sanuj: PR was too big | 19:40 |
| @HeikoS | to review | 19:40 |
| sanuj | HeikoS, okay :D | 19:40 |
| @HeikoS | then, its hard to realise such things | 19:40 |
| @HeikoS | also, too many GSoC projects :D | 19:40 |
| sanuj | HeikoS, less than last to last time | 19:40 |
| @HeikoS | and finally, again, this is your project, not mine ;) | 19:40 |
| @HeikoS | so you have to try to check out such things as well | 19:41 |
| sanuj | HeikoS, yesss okay | 19:41 |
| @HeikoS | but dont worry | 19:41 |
| @HeikoS | all good | 19:41 |
| @HeikoS | this is a good patch | 19:41 |
| @HeikoS | we just need to make it better | 19:41 |
| sanuj | HeikoS, thanks :D | 19:41 |
| @HeikoS | sanuj: updated comment | 19:45 |
| @HeikoS | the code I pasted is now a bit different | 19:45 |
| @HeikoS | sanuj: ok then, you got some things to update | 19:48 |
| @HeikoS | let me know when all comments are addressed, and we will see what else we can find in there ;) | 19:48 |
| @HeikoS | I gotta talk to Saurabh7 now | 19:48 |
| sanuj | HeikoS, okay, thanks | 19:49 |
| Saurabh7 | HeikoS, hey | 19:50 |
| Saurabh7 | so what do you think how would we start with the thread safety | 19:51 |
| @HeikoS | so the way to do it | 19:53 |
| @HeikoS | is similar to the way we did it in xvalidation | 19:53 |
| @HeikoS | but without clone | 19:53 |
| @HeikoS | but rather a shallow copy | 19:53 |
| @HeikoS | so everytime you want to thread-safe subset | 19:53 |
| @HeikoS | you create a shallow copy of the CFeature object | 19:54 |
| @HeikoS | lambday in fact did that already :) | 19:54 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/blob/feature/bigtest/src/shogun/statistical_testing/internals/FeaturesUtil.cpp#L46 | 19:54 |
| @HeikoS | you can copy that | 19:54 |
| Saurabh7 | yes thats should be easy with densefeatures attleast | 19:54 |
| @HeikoS | THEN | 19:54 |
| @HeikoS | the sub-set stack is still shared, right? | 19:54 |
| @HeikoS | since it is shallow copy | 19:54 |
| @HeikoS | in fact, lambday already clones the subset stack in his method | 19:55 |
| Saurabh7 | it shouldnt be the same obj right | 19:55 |
| Saurabh7 | the stack | 19:55 |
| @HeikoS | exactly it needs to be a new one | 19:55 |
| @HeikoS | so the way to do it | 19:55 |
| @lambday | Saurabh7: yeah I kinda clone the subset | 19:55 |
| @HeikoS | is to call the method something like | 19:55 |
| @HeikoS | create_subset_shallow_copy | 19:55 |
| @HeikoS | and then in there create a shallow copy of the features | 19:56 |
| @HeikoS | then create a clone of the (collapsed!!!) subset stack | 19:56 |
| @HeikoS | then the new features object can be assigned subsets | 19:56 |
| Saurabh7 | ok | 19:56 |
| @HeikoS | make sure to not clone the full subset stacj | 19:56 |
| @HeikoS | but rather collapse it before, I think there is a method | 19:56 |
| Saurabh7 | what exactly do you mean by collapse | 19:56 |
| @HeikoS | Saurabh7: imagine you have 100 vector on subsetstack | 19:58 |
| @HeikoS | then lookup means looking up 100 vector indices | 19:58 |
| @HeikoS | thats slow | 19:58 |
| @HeikoS | so the subset stack always stores the "collapsed" version | 19:58 |
| @HeikoS | that contains all these 100 mappings | 19:58 |
| @HeikoS | you can get it with get_last_subset | 19:58 |
| @HeikoS | get_last_subset() | 19:58 |
| Saurabh7 | oh yes yes i saw that | 19:59 |
| Saurabh7 | got it | 19:59 |
| @HeikoS | so in this shallow_subset_copy() method | 19:59 |
| @HeikoS | you create a new subset stack | 19:59 |
| @HeikoS | and initialise it with get_last_subset() of the original features | 19:59 |
| @HeikoS | got that? | 19:59 |
| Saurabh7 | yep | 19:59 |
| @HeikoS | Saurabh7: then, when this is done, I want you to make all methods that you use inside the parallel code: const | 19:59 |
| @HeikoS | I guess you use | 20:00 |
| @HeikoS | get_feature_vector()? | 20:00 |
| @HeikoS | get_feature_matrix() returns a copy if subset is active, so that should not be used | 20:00 |
| Saurabh7 | no mat operators | 20:00 |
| Saurabh7 | i mean mat operators are used () | 20:00 |
| @HeikoS | which ones do you use? | 20:00 |
| @HeikoS | get_feature_matrix must not be used when subsets are active | 20:01 |
| @HeikoS | otherwise, c9opy | 20:01 |
| @HeikoS | slow | 20:01 |
| @HeikoS | so how do you access the features? | 20:01 |
| @HeikoS | so basically, you can only use get_feature_vector | 20:02 |
| @HeikoS | since this does not copy the memory | 20:02 |
| Saurabh7 | HeikoS, get_feature_matrix is used | 20:02 |
| Saurabh7 | and then its accesed , right now | 20:02 |
| Saurabh7 | so I will try to change that | 20:03 |
| @HeikoS | check line 89 of CDenseFeatures | 20:03 |
| @HeikoS | template<class ST> ST* CDenseFeatures<ST>::get_feature_vector(int32_t num, int32_t& len, bool& dofree) | 20:03 |
| @HeikoS | and the wrapped one | 20:03 |
| @HeikoS | template<class ST> SGVector<ST> CDenseFeatures<ST>::get_feature_vector(int32_t num) | 20:03 |
| @HeikoS | these guys do not copy | 20:03 |
| @HeikoS | get_feature_matrix() always copies | 20:03 |
| @HeikoS | if you have a subset active | 20:04 |
| @HeikoS | Saurabh7: try it | 20:04 |
| @HeikoS | if you need to to linear algebra operations on the (subsetted) feature matrix, you need to copy | 20:04 |
| Saurabh7 | HeikoS, ok I will cahnge that | 20:04 |
| @HeikoS | but for random forest, I dont think you need to | 20:04 |
| @HeikoS | or? | 20:04 |
| Saurabh7 | so the subset are set on features | 20:04 |
| Saurabh7 | get matrix | 20:05 |
| Saurabh7 | operations | 20:05 |
| Saurabh7 | ^ this is what it is right now | 20:05 |
| @HeikoS | Saurabh7: btw, can you make the existing patch merge ready before you start? | 20:05 |
| @HeikoS | Saurabh7: yes | 20:05 |
| @HeikoS | 1.) create shallow copies of features, each with a new subset stack initialised to the get_active_subset of old features | 20:05 |
| @HeikoS | 2.) only use get_feature_vector | 20:05 |
| Saurabh7 | HeikoS, ok I will see if anything is left to polish in the patch | 20:06 |
| @HeikoS | 3.) make everything inside parallel const | 20:06 |
| @HeikoS | Saurabh7: cool | 20:06 |
| Saurabh7 | so actually it was being copied everytime, interesting | 20:06 |
| @HeikoS | Saurabh7: yes | 20:06 |
| @HeikoS | memcpy is fast | 20:06 |
| @HeikoS | but not doing it is faster | 20:06 |
| Saurabh7 | so the shallow copy method , I add ti to densefeatures ? | 20:07 |
| Saurabh7 | HeikoS, ^ | 20:07 |
| @HeikoS | Saurabh7: no to CFeatures | 20:08 |
| @HeikoS | Saurabh7: and then overload in CDenseFetaures | 20:08 |
| @HeikoS | this also has to work with other features | 20:08 |
| Saurabh7 | ok | 20:08 |
| @HeikoS | will need to make that work for string features as well later | 20:08 |
| Saurabh7 | and what about labels | 20:08 |
| @HeikoS | when we touch x-validation again to also share the data | 20:08 |
| @HeikoS | Saurabh7: same story for labels, yes | 20:08 |
| @HeikoS | have a look, they have the same subset stack things inside | 20:09 |
| Saurabh7 | yep ok | 20:09 |
| Saurabh7 | alright looks clear this one :) | 20:09 |
| shogun-notifier- | shogun: Heiko Strathmann :feature/meta_vector_matrix * 01b9a58 / examples/meta/src/tests/matrix_types.sg,examples/meta/src/tests/vector_types.sg: https://github.com/shogun-toolbox/shogun/commit/01b9a587dd346234c10b1024c7aeae0535c55b3a | 20:10 |
| shogun-notifier- | shogun: not test long real vector for now, travis doesn't like it | 20:10 |
| @HeikoS | Saurabh7: great | 20:10 |
| @HeikoS | I gotta leave now | 20:10 |
| @HeikoS | Saurabh7: will be in France until Monday, I take my computer, so send me emails if things are unclear. I will also try to merge things, dont panic if I dont though. IRC will be limited | 20:10 |
| @HeikoS | sanuj: ^ | 20:10 |
| Saurabh7 | HeikoS, cool , mail frm tmrw ? | 20:11 |
| Saurabh7 | yep cool | 20:11 |
| sanuj | HeikoS, okayy | 20:11 |
| @HeikoS | Saurabh7: yep! | 20:11 |
| @HeikoS | see you guys | 20:12 |
| @HeikoS | keep up the good work :) | 20:12 |
| @HeikoS | bazdmeg: bazdmeg!!!!! | 20:12 |
| @HeikoS | wiking: bazdmeg!!!!! | 20:12 |
| sanuj | HeikoS, take care, have fun in france | 20:12 |
| Saurabh7 | cya | 20:12 |
| @HeikoS | lambday: bazdmeg!!!!! | 20:12 |
| sanuj | bazdmeg!!!!!!!!!!!! | 20:12 |
| sanuj | lol | 20:12 |
| @HeikoS | shogun-buildbot: dance | 20:12 |
| shogun-buildbot | <(^.^<) | 20:12 |
| shogun-buildbot | <(^.^)> | 20:12 |
| Saurabh7 | whats that :D | 20:12 |
| shogun-buildbot | (>^.^)> | 20:12 |
| shogun-buildbot | (7^.^)7 | 20:12 |
| shogun-buildbot | (>^.^<) | 20:12 |
| Saurabh7 | ok gn every1 | 20:13 |
| -!- Saurabh7 [~Saurabh7@1.39.12.41] has quit [Quit: Leaving] | 20:13 | |
| -!- HeikoS [~heiko@nat-161-217.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 20:13 | |
| -!- travis-ci [~travis-ci@ec2-54-161-164-171.compute-1.amazonaws.com] has joined #shogun | 20:14 | |
| travis-ci | it's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/139244431 | 20:14 |
| -!- travis-ci [~travis-ci@ec2-54-161-164-171.compute-1.amazonaws.com] has left #shogun [] | 20:14 | |
| -!- sanuj [~sanuj@117.204.249.63] has quit [Remote host closed the connection] | 20:16 | |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [Quit: Page closed] | 20:23 | |
| -!- TanNguyen [~dra@89.162.139.29] has quit [Ping timeout: 264 seconds] | 21:31 | |
| -!- TanNguyen [~dra@89.162.139.29] has joined #shogun | 21:44 | |
| -!- lambday [569de6b3@gateway/web/freenode/ip.86.157.230.179] has joined #shogun | 21:56 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 21:56 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 22:11 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 22:11 | |
| bazdmeg | bazdmeg | 22:15 |
| @lambday | bazdmeg: | 22:19 |
| bazdmeg | what the fuuzz | 22:20 |
| bazdmeg | lambday: do oyu have any idea | 22:20 |
| bazdmeg | why heiko reverted wrap | 22:20 |
| @lambday | bazdmeg: nope.. what's wrap? | 22:21 |
| bazdmeg | uhmm that's a functions | 22:21 |
| bazdmeg | function | 22:21 |
| bazdmeg | that wraps pointers to some | 22:21 |
| bazdmeg | Some<T> | 22:21 |
| bazdmeg | but returns the object otherwise | 22:21 |
| bazdmeg | so it's like a wrap for pointers to make them delete once used | 22:21 |
| @lambday | bazdmeg: yeah I understand | 22:21 |
| @lambday | bazdmeg: but sorry he didn't discuss anything about that with me | 22:22 |
| -!- travis-ci [~travis-ci@ec2-54-205-149-7.compute-1.amazonaws.com] has joined #shogun | 22:22 | |
| travis-ci | it's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/139278912 | 22:22 |
| -!- travis-ci [~travis-ci@ec2-54-205-149-7.compute-1.amazonaws.com] has left #shogun [] | 22:22 | |
| @lambday | bazdmeg: checked the irc log.. | 22:23 |
| @lambday | bazdmeg: apparently things were broken | 22:23 |
| bazdmeg | fuck my life! | 22:24 |
| @lambday | bazdmeg: whoa | 22:25 |
| -!- HeikoS_web [8028d5f1@gateway/web/freenode/ip.128.40.213.241] has joined #shogun | 22:59 | |
| HeikoS_web | wiking bazdmeg | 23:00 |
| bazdmeg | HeikoS_web: what's wrong | 23:00 |
| bazdmeg | with wrap | 23:00 |
| HeikoS_web | every assignment is wrapped | 23:00 |
| HeikoS_web | see my feature branch | 23:00 |
| bazdmeg | and? | 23:00 |
| HeikoS_web | there i want to assign numbers to vectors | 23:00 |
| bazdmeg | is it aesthetic? | 23:01 |
| bazdmeg | like wrap(3) is ugly? | 23:01 |
| HeikoS_web | no i thought it broke the assignment | 23:01 |
| HeikoS_web | but actually | 23:01 |
| bazdmeg | no way | 23:01 |
| HeikoS_web | i might not have been careful | 23:01 |
| HeikoS_web | i cant check right now | 23:01 |
| HeikoS_web | can you push the json change back to my feature branch_ | 23:01 |
| HeikoS_web | feature/meta_ | 23:02 |
| HeikoS_web | something | 23:02 |
| HeikoS_web | the travis there is currently broken, but we can see what happens if this is added back | 23:02 |
| HeikoS_web | also feel free to add vector instantiation support in the jsons of the language bindings that fail | 23:02 |
| HeikoS_web | ruby | 23:03 |
| HeikoS_web | e.g. | 23:03 |
| HeikoS_web | gotta go | 23:04 |
| HeikoS_web | see you later | 23:04 |
| HeikoS_web | might change that tomorrow | 23:04 |
| HeikoS_web | bazdmeg: | 23:04 |
| bazdmeg | ok will try a bit later | 23:04 |
| HeikoS_web | bazdmeg: I told sanuj to change a few things btw | 23:07 |
| HeikoS_web | bazdmeg: lots of the stuff in there didnt make sense | 23:07 |
| HeikoS_web | kind of involved, but still | 23:07 |
| bazdmeg | what stuff | 23:07 |
| HeikoS_web | bazdmeg: e.g. setters should only work for previously registered tags | 23:08 |
| bazdmeg | why so? | 23:08 |
| HeikoS_web | like i should not be able to set "training_data" of CDenseFeatures | 23:08 |
| HeikoS_web | because I should only be able to write to things that were member variables before | 23:08 |
| bazdmeg | uhmm ok that's the next step | 23:08 |
| HeikoS_web | why next step? can do that now | 23:08 |
| HeikoS_web | can unit test with mock classes | 23:09 |
| HeikoS_web | easy | 23:09 |
| HeikoS_web | there has to be a public setter that checks and a private setter to that replaces SG_ADD | 23:09 |
| HeikoS_web | the other things were | 23:09 |
| HeikoS_web | why does the == operator compare the strings? no need | 23:09 |
| HeikoS_web | just hash | 23:09 |
| HeikoS_web | third was, why does set return things? | 23:09 |
| HeikoS_web | in this weird way | 23:10 |
| HeikoS_web | that if something was there, it is returned | 23:10 |
| HeikoS_web | otherwise argument | 23:10 |
| bazdmeg | well it should be returning Maybe | 23:10 |
| bazdmeg | Maybe<T> | 23:10 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 23:10 | |
| HeikoS_web | why? | 23:10 |
| HeikoS_web | just use has | 23:10 |
| HeikoS_web | before set call | 23:10 |
| HeikoS_web | and then use get if want to save it | 23:10 |
| bazdmeg | well maybe | 23:10 |
| HeikoS_web | there also is question: | 23:11 |
| HeikoS_web | do we merge this to develop? | 23:11 |
| HeikoS_web | and then hack the SG_ADD? | 23:12 |
| bazdmeg | if we start using it like with SG_ADD | 23:12 |
| bazdmeg | then to develop | 23:12 |
| HeikoS_web | and another one is: we dont need member variables anymore right? | 23:12 |
| bazdmeg | yes | 23:12 |
| HeikoS_web | so should this be re-factored? | 23:12 |
| bazdmeg | at some point | 23:12 |
| HeikoS_web | impossible | 23:12 |
| bazdmeg | yes | 23:12 |
| HeikoS_web | haha | 23:12 |
| bazdmeg | HeikoS_web: with some magic in SG_ADD | 23:12 |
| HeikoS_web | and all member variable soccurences are replaced with the get call | 23:12 |
| bazdmeg | we can make them point to the same place | 23:12 |
| HeikoS_web | yeah but definition I mean | 23:12 |
| bazdmeg | so get_something | 23:13 |
| bazdmeg | and get("something") | 23:13 |
| bazdmeg | is the same | 23:13 |
| HeikoS_web | yeah sure, just ::set(m_member, "bla"( | 23:13 |
| HeikoS_web | but in fact | 23:13 |
| HeikoS_web | we dont even need to declare the member anymore, am I right? | 23:13 |
| bazdmeg | HeikoS_web: we have to | 23:13 |
| HeikoS_web | it can just live in the map, being put there in constructor with SG_ADD | 23:13 |
| bazdmeg | like in SG_ADD | 23:13 |
| bazdmeg | yes | 23:13 |
| bazdmeg | just in sg_add | 23:13 |
| HeikoS_web | but I can also do | 23:13 |
| HeikoS_web | ::set(SGVEctor<...>, "member"( | 23:14 |
| HeikoS_web | sorry | 23:14 |
| HeikoS_web | ::set(SGVector<T>(), "member"( | 23:14 |
| HeikoS_web | no? | 23:14 |
| HeikoS_web | and then the thing just lives in the map | 23:15 |
| HeikoS_web | no more declaration | 23:15 |
| bazdmeg | yes | 23:15 |
| HeikoS_web | kinda weird | 23:15 |
| bazdmeg | why | 23:15 |
| HeikoS_web | no member variable declared | 23:15 |
| HeikoS_web | all members added at runtime | 23:15 |
| HeikoS_web | but its cool | 23:16 |
| bazdmeg | so? | 23:16 |
| bazdmeg | why weird | 23:16 |
| bazdmeg | python | 23:16 |
| bazdmeg | :D | 23:16 |
| bazdmeg | is python weird? | 23:16 |
| HeikoS_web | yep | 23:16 |
| HeikoS_web | thats exactly it | 23:16 |
| HeikoS_web | anyway,this refactor is insane anyways | 23:16 |
| HeikoS_web | so first step, we just register the member | 23:16 |
| bazdmeg | absolutely | 23:16 |
| HeikoS_web | using SG_add change | 23:16 |
| bazdmeg | we don't finish it tihs year | 23:16 |
| HeikoS_web | so I want to merge this stuff soon | 23:16 |
| bazdmeg | :D | 23:16 |
| HeikoS_web | I mean the current patch | 23:16 |
| bazdmeg | ok I think I need to do some SG_ADD hackery | 23:17 |
| HeikoS_web | question: to develop? | 23:17 |
| bazdmeg | it would be really tricky | 23:17 |
| HeikoS_web | or not | 23:17 |
| bazdmeg | *with* SG_ADD | 23:17 |
| HeikoS_web | it is not too bad | 23:17 |
| bazdmeg | it can go to develop | 23:17 |
| HeikoS_web | as SG_ADD already takes name | 23:17 |
| HeikoS_web | and reference | 23:17 |
| bazdmeg | yes | 23:17 |
| HeikoS_web | the old one m_parameter->add, is harder | 23:17 |
| bazdmeg | it should go to develop but *with* SG_ADD | 23:17 |
| HeikoS_web | yeah | 23:17 |
| HeikoS_web | so we merge this to feature branch first | 23:17 |
| HeikoS_web | then polish a bit | 23:17 |
| HeikoS_web | then add SG_ADD | 23:18 |
| HeikoS_web | and then merge | 23:18 |
| HeikoS_web | to develop | 23:18 |
| HeikoS_web | while developing SWIg stuff in parallel | 23:18 |
| HeikoS_web | bazdmeg: see my comments on the PR | 23:18 |
| HeikoS_web | after that, I am fine to merge | 23:18 |
| HeikoS_web | bazdmeg: Ill leave that to you | 23:18 |
| bazdmeg | ok | 23:18 |
| HeikoS_web | oh one thing is | 23:18 |
| HeikoS_web | 100% test coverage | 23:18 |
| HeikoS_web | he didnt do that yet right? | 23:19 |
| HeikoS_web | we will see | 23:19 |
| HeikoS_web | gotta go home now | 23:19 |
| HeikoS_web | see you | 23:19 |
| bazdmeg | ok | 23:20 |
| bazdmeg | yeah | 23:20 |
| -!- OXPHOS [c68f0c0c@gateway/web/freenode/ip.198.143.12.12] has joined #shogun | 23:40 | |
| --- Log closed Wed Jun 22 00:00:50 2016 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!