--- Log opened Mon Jun 13 00:00:37 2016 | ||
-!- GandalfTheWizard [~Eva@112.10.170.90] has joined #shogun | 02:58 | |
shogun-buildbot | build #1019 of nightly_none is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_none/builds/1019 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 03:04 |
---|---|---|
shogun-buildbot | build #17 of clang - thread analysis is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20thread%20analysis/builds/17 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 03:44 |
shogun-buildbot | build #16 of clang - undefined behaviour analysis is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20undefined%20behaviour%20analysis/builds/16 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 03:48 |
shogun-buildbot | build #18 of memleak - valgrind is complete: Failure [failed memory check] Build details are at http://buildbot.shogun-toolbox.org/builders/memleak%20-%20valgrind/builds/18 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 05:29 |
shogun-buildbot | build #1149 of nightly_default is complete: Failure [failed test notebooks] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1149 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com>, Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 06:08 |
@wiking | Saurabh7: helloo hello | 07:44 |
-!- sonne|work [~sonnenbu@88.134.176.135] has quit [Quit: Leaving.] | 09:35 | |
-!- besser82 [~besser82@fedora/besser82] has joined #shogun | 10:02 | |
-!- mode/#shogun [+o besser82] by ChanServ | 10:02 | |
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 260 seconds] | 10:12 | |
-!- sanuj [~sanuj@117.204.250.149] has joined #shogun | 10:41 | |
-!- besser82 [~besser82@fedora/besser82] has joined #shogun | 11:13 | |
-!- mode/#shogun [+o besser82] by ChanServ | 11:13 | |
sanuj | lisitsyn, hey | 11:22 |
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds] | 11:29 | |
@wiking | Saurabh7: sanuj it's about half monday gone.... no standup lines | 11:30 |
@wiking | time to put it in | 11:30 |
@wiking | along with the weekly report | 11:30 |
-!- besser82 [~besser82@fedora/besser82] has joined #shogun | 11:33 | |
-!- mode/#shogun [+o besser82] by ChanServ | 11:33 | |
sanuj | wiking, today i have been working on macros in swig for tags and related functions | 11:38 |
sanuj | last week i did only 1 cookbook | 11:39 |
sanuj | currently there are 3 cookbook PRs which are yet to be merged | 11:39 |
sanuj | so i think it is better to merge them before starting a new cookbook | 11:39 |
sanuj | will send my monday report soon | 11:40 |
@wiking | thnx | 11:40 |
@wiking | anything that you'd need help with? | 11:40 |
sanuj | wiking, this is a list of all base classes in shogun https://gist.github.com/sanuj/56f03cd242473137fad851e68fa0f2c1 | 11:41 |
sanuj | lisitsyn has told me to instantiate templates for each in swig | 11:41 |
@wiking | mmm yeah i'm just wondeirng CEigenSolver and such but ok | 11:42 |
sanuj | but template instantiation won't work for base classes | 11:42 |
sanuj | because of pure virtual functions | 11:42 |
@wiking | ? | 11:42 |
@wiking | i mean you can have swig type for abstract methods | 11:42 |
@wiking | (hence the whole story for director classes) | 11:43 |
sanuj | %template(set ## name) CSGObject::set<type, void>; | 11:43 |
sanuj | i think this makes a new object using "new" | 11:43 |
sanuj | for abstract classes | 11:43 |
sanuj | so it errors | 11:44 |
sanuj | name and type are macro arguments in ^^ line of code | 11:44 |
sanuj | this line is to enable things like ==> gauss_kernel.setInt("width", 20) | 11:45 |
lisitsyn | hmm ok | 11:45 |
lisitsyn | sanuj: what is the error you get | 11:45 |
lisitsyn | it looks like we have to employ some pointers for that | 11:46 |
lisitsyn | or even some 'some' pointers :) | 11:46 |
-!- lambday [0551433c@gateway/web/freenode/ip.5.81.67.60] has joined #shogun | 11:47 | |
-!- mode/#shogun [+o lambday] by ChanServ | 11:47 | |
sanuj | lisitsyn, heyyy | 11:48 |
sanuj | error is really long | 11:48 |
sanuj | but important line is | 11:48 |
sanuj | modshogunPYTHON_wrap.cxx:23311:11: error: cannot declare variable ‘result’ to be of abstract type ‘shogun::CKernel’ | 11:48 |
lisitsyn | ok we need pointers | 11:49 |
sanuj | lisitsyn, need more information | 11:49 |
lisitsyn | sanuj: I think we need to stop fulfilling this list | 11:49 |
sanuj | okay | 11:49 |
lisitsyn | but make it to work with SGObject | 11:49 |
sanuj | lisitsyn, don't fully understand | 11:50 |
sanuj | make what work with SGObject? | 11:50 |
lisitsyn | try implementing Some<CSGObject> get<CSGObject>(...) | 11:50 |
sanuj | okay | 11:51 |
lisitsyn | sanuj: other words - try to use Some<T> | 11:51 |
sanuj | lisitsyn, btw i'm using this macro http://pastebin.com/CBKMXRCN | 11:51 |
lisitsyn | fro all types inherited CSGObject (including) | 11:51 |
sanuj | lisitsyn, okay | 11:51 |
sanuj | lisitsyn, and do i need to expose sgvector? | 11:52 |
lisitsyn | sanuj: yes | 11:52 |
sanuj | lisitsyn, and what all primitive types | 11:52 |
sanuj | right now i have int, string, bool, float | 11:52 |
lisitsyn | not sure, lets change that later | 11:53 |
sanuj | lisitsyn, not sure about macro? | 11:53 |
lisitsyn | sanuj: no, primitive types | 11:53 |
sanuj | okay | 11:53 |
sanuj | lisitsyn, i don't think there is any need to expose "any" via swig | 11:56 |
lisitsyn | sanuj: not sure | 11:57 |
sanuj | asInt, asFloat | 11:57 |
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 12:02 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 12:02 | |
sanuj | lisitsyn, when i do %include <shogun/base/some.h> | 12:09 |
sanuj | some.h:29: Error: Syntax error in input(3). | 12:10 |
sanuj | line 29 is Some() = delete; | 12:10 |
lisitsyn | sanuj: looks like swig doesn't get C++11 syntax | 12:11 |
sanuj | lisitsyn, http://www.swig.org/Doc3.0/CPlusPlus11.html | 12:11 |
lisitsyn | SWIG handles explicitly defaulted functions, that is, = default | 12:12 |
lisitsyn | is it possible that you have a bit old swig? | 12:12 |
sanuj | i have swig2.0 | 12:12 |
lisitsyn | yeah I guess you have to update | 12:13 |
sanuj | okay | 12:13 |
sanuj | let me update | 12:13 |
sanuj | lisitsyn, do i need to check for mem leak for the nn PR in python? | 12:25 |
Saurabh7 | wiking: hihi, finished updating LARS to better state, removed loops now using eigen matrices and blocks to access intersting columns | 12:37 |
Saurabh7 | this lead to problems when dropping variables tho, i fixed it now | 12:38 |
Saurabh7 | jsut finishing a cookbook now | 12:38 |
Saurabh7 | HeikoS: hi | 12:38 |
@wiking | Saurabh7: awesome | 12:39 |
@wiking | ! | 12:39 |
Saurabh7 | wiking: i pushed it here https://github.com/shogun-toolbox/shogun/pull/3243 | 12:40 |
@HeikoS | Saurabh7: hi | 12:44 |
@HeikoS | nice one | 12:44 |
@HeikoS | Saurabh7: and the times changed when you did this? | 12:45 |
Saurabh7 | yes | 12:45 |
Saurabh7 | quite better | 12:45 |
@HeikoS | share :) | 12:46 |
Saurabh7 | I tired to do this for inactive columns too using mat.swap when an variable is added | 12:46 |
Saurabh7 | but had to cahnge lot other things and the results were changing so dropped it fo rnow | 12:46 |
@HeikoS | Saurabh7: sure | 12:47 |
Saurabh7 | HeikoS: i put the times in there | 12:47 |
@HeikoS | ah ok checking | 12:47 |
Saurabh7 | https://github.com/shogun-toolbox/shogun/pull/3243 athe bottom | 12:47 |
@wiking | Saurabh7: some comments are in again | 12:52 |
@wiking | :) | 12:52 |
@HeikoS | Saurabh7: about the active | 12:53 |
@HeikoS | X_active | 12:53 |
@HeikoS | Saurabh7: any reason why you allocate it with malloc? | 12:53 |
Saurabh7 | wiking: yessry didnt replace teh map | 12:53 |
Saurabh7 | HeikoS: no | 12:53 |
@HeikoS | Saurabh7: better use SGVector | 12:54 |
Saurabh7 | I think i can use sgmatrix too if tis good | 12:54 |
@HeikoS | or SGMatrix | 12:54 |
Saurabh7 | ok ill replace | 12:54 |
@HeikoS | you eigen3 maps can still only cover parts of the memory | 12:54 |
@HeikoS | but then you dont have to free later | 12:54 |
@HeikoS | save a line of code and a potential leak | 12:54 |
@HeikoS | and confusion when others read it :) | 12:54 |
Saurabh7 | yes yes good idea | 12:55 |
@HeikoS | Saurabh7: any reason why you use vector? | 12:56 |
@HeikoS | and make_vector? | 12:56 |
Saurabh7 | HeikoS: it was there form before | 12:57 |
Saurabh7 | I tried to replace some | 12:57 |
@HeikoS | Saurabh7: are these growing and shrinking? | 12:57 |
Saurabh7 | one is | 12:57 |
@HeikoS | Saurabh7: ah ok | 12:57 |
Saurabh7 | beta path | 12:57 |
@HeikoS | then it is ok | 12:57 |
Saurabh7 | where we append a beta | 12:57 |
Saurabh7 | so in shogun we ahve to use dynamic array ? | 12:58 |
@HeikoS | yes | 12:58 |
@HeikoS | you can | 12:58 |
@HeikoS | but you dont have to | 12:58 |
@wiking | what is growing dynamicaally? | 12:58 |
@HeikoS | as vector is in stdlib | 12:58 |
@HeikoS | and if you only use it in the .cpp it is ok | 12:58 |
Saurabh7 | vector of vector | 12:58 |
Saurabh7 | is growing | 12:58 |
@HeikoS | Saurabh7: your results look pretty good btw, I mean the times | 12:59 |
Saurabh7 | HeikoS: for many relevant variables its good | 12:59 |
@HeikoS | Saurabh7: I dont get why SG is sometimes faster with same number of iterations though | 13:00 |
@HeikoS | slower soory | 13:00 |
Saurabh7 | if the relevant features are less it becomes a bit lower | 13:00 |
@HeikoS | Saurabh7: yes seeing that | 13:00 |
@HeikoS | ideas where that comes from? | 13:00 |
Saurabh7 | so basically when num acitve variables is low | 13:01 |
Saurabh7 | we calcualte the correlations from scratch in every iter | 13:01 |
Saurabh7 | that might be the reason i thought of | 13:01 |
@wiking | could we cache taht? | 13:01 |
@wiking | makes sense to cache it? | 13:01 |
Saurabh7 | instead of that updating them is a way | 13:01 |
@wiking | or updating it? | 13:02 |
Saurabh7 | i tried doing that with inactive variables and swap as i siad | 13:02 |
@HeikoS | Saurabh7: it gets messy right? | 13:02 |
@HeikoS | Saurabh7: can I suggest: we fix this up, merge it. And then you can start a new PR to investigate this? | 13:03 |
Saurabh7 | wiking: like the updating the ones already calcuated | 13:03 |
@HeikoS | Saurabh7: because it will probably help | 13:03 |
Saurabh7 | HeikoS: yes its a bit mmessy I couldnt see why the results were changing , so its something algo related | 13:03 |
@HeikoS | Saurabh7: yeah, lets do in a second step ok? | 13:04 |
@HeikoS | Saurabh7: if you can address all the comments we made | 13:04 |
@HeikoS | and polish, squash | 13:04 |
@HeikoS | then we can merge and go for next iteration | 13:04 |
@HeikoS | that should be feasible today no? | 13:04 |
Saurabh7 | yes ok | 13:04 |
Saurabh7 | also about the impl class | 13:05 |
Saurabh7 | sec brb | 13:05 |
@HeikoS | ok | 13:05 |
Saurabh7 | HeikoS: the impl class rigt now has only one method , is it fine ? | 13:06 |
Saurabh7 | only other we can add are the cholesky delet and the rotation stuff | 13:06 |
@HeikoS | Saurabh7: yes no point in having a class for a single static method | 13:09 |
@HeikoS | if you have 3, then it might be better | 13:10 |
@HeikoS | but you can also just hide them from SWIG and leave them in the main class | 13:10 |
@HeikoS | you can unit test it via creating a mock class | 13:10 |
@HeikoS | simplest way: overload it in unit test and define the method public, wrap the protected method | 13:11 |
@HeikoS | Saurabh7: good? | 13:11 |
@HeikoS | Saurabh7: btw, the benchmark in zoq is still wrong, or? | 13:11 |
Saurabh7 | HeikoS: yes I will remove the class | 13:11 |
@HeikoS | it compares against a different algo? | 13:11 |
Saurabh7 | HeikoS: yes its wrong | 13:11 |
@HeikoS | or is that fixed? | 13:11 |
@HeikoS | good idea to also get that cleaned up soon | 13:12 |
Saurabh7 | so they have 2 benchmarks | 13:12 |
Saurabh7 | one is lars and lasso | 13:12 |
@HeikoS | yeah, we want lars | 13:12 |
Saurabh7 | lars uses larslasso | 13:12 |
Saurabh7 | and lasso uses lasso :) | 13:12 |
@HeikoS | the other one, we can check later, but should not be in there | 13:12 |
Saurabh7 | so none is actually using scikits lars class | 13:12 |
@HeikoS | Saurabh7: ah | 13:12 |
@HeikoS | no good | 13:12 |
@HeikoS | doesnt Lassoolars use lars? | 13:13 |
Saurabh7 | yes its uses larspath | 13:13 |
Saurabh7 | so we can compare our lasso version of lars with their lassolars | 13:13 |
@HeikoS | ok | 13:13 |
@HeikoS | that should be done then | 13:13 |
@HeikoS | and all the rest should be disabled | 13:13 |
Saurabh7 | that should be a bit fair | 13:13 |
Saurabh7 | ok | 13:13 |
@HeikoS | as it gives wrong impressions | 13:13 |
@HeikoS | Saurabh7: so the plan for today then is | 13:14 |
@HeikoS | 1.) clean up PR and merge | 13:14 |
@HeikoS | 2.) clean up kmeans PR and merge | 13:14 |
@HeikoS | 3.) update benchmark for lars | 13:14 |
@HeikoS | 4.) start another PR for the further optimization | 13:14 |
@HeikoS | good? | 13:14 |
Saurabh7 | yep | 13:14 |
@HeikoS | Saurabh7: cool | 13:15 |
@HeikoS | lets try to get all this done today, as this week should be used for a further algo | 13:15 |
@HeikoS | you can already think of one you would like to touch next | 13:15 |
@HeikoS | I thought maybe rf might be good... | 13:16 |
@HeikoS | random forest | 13:16 |
@HeikoS | but also up for suggestions from your side | 13:16 |
Saurabh7 | hm random forest with the CART ? | 13:16 |
Saurabh7 | cart was reallyyyyy slow in my intital test | 13:17 |
@HeikoS | yes :) | 13:17 |
@wiking | Saurabh7: hehhe yeah all the decision trees needs love | 13:17 |
@HeikoS | CART is kind of old school as well ;) | 13:17 |
@HeikoS | but we should have that one fast | 13:17 |
@HeikoS | there will be lots of things to play with | 13:17 |
@HeikoS | but lots of things to gain as well | 13:17 |
@wiking | Saurabh7: all decesion tree implementations are very very vanilla | 13:17 |
@wiking | there's room for improvement there | 13:18 |
@wiking | a lot | 13:18 |
Saurabh7 | wiking: i see havent checked impl | 13:18 |
Saurabh7 | cool | 13:18 |
@HeikoS | KNN could also be next Saurabh7 | 13:29 |
@HeikoS | your call | 13:29 |
@HeikoS | with covertree | 13:29 |
@HeikoS | Saurabh7: oh one more question, did you compare to mlpack's lars yet? | 13:30 |
sanuj | lisitsyn, | 13:33 |
sanuj | modshogunPYTHON_wrap.cxx:28917:3: error: ‘Some’ is not a member of ‘shogun’ | 13:33 |
sanuj | shogun::Some< CKernel > *result = 0 ; | 13:34 |
sanuj | ? | 13:34 |
@HeikoS | c++11 | 13:42 |
@HeikoS | some is guarded | 13:42 |
sanuj | HeikoS, how to make it visible? | 13:43 |
sanuj | remove the guard? | 13:43 |
@HeikoS | nooooo | 13:43 |
@HeikoS | :) | 13:43 |
sanuj | :D | 13:44 |
@HeikoS | need to find out how swig plays with c++11 | 13:44 |
@HeikoS | 13:44 | |
@HeikoS | then ask lisitsyn | 13:44 |
-!- mizari [~mizari@95-174-213-100.nts.su] has joined #shogun | 13:44 | |
sanuj | yeah | 13:44 |
sanuj | he told me to install latest swig | 13:45 |
sanuj | i did that | 13:45 |
sanuj | HeikoS, swig plays well with c++11 | 13:45 |
sanuj | http://www.swig.org/Doc3.0/CPlusPlus11.html | 13:45 |
@HeikoS | sanuj: check some.h | 13:45 |
@HeikoS | if some is not defined | 13:46 |
@HeikoS | then it is because of the guard | 13:46 |
@HeikoS | #ifdef HAVE_CXX11 | 13:46 |
sanuj | btw my tags code has some c++11 stuff | 13:46 |
sanuj | and i just realized it is not guarded | 13:46 |
@HeikoS | better guard it :) | 13:48 |
@HeikoS | otherwise the buildbot will be angry | 13:48 |
sanuj | HeikoS, essential code | 13:49 |
Saurabh7 | HeikoS: no havent compared runtimes with mlpack yet, but i checked thier impl | 13:50 |
sanuj | i checked cmakelist | 13:50 |
sanuj | HAVE_CXX11 is set when _HAS_CXX11_FLAG is set | 13:50 |
@HeikoS | Saurabh7: only check implementations if things are fast :) | 13:51 |
@HeikoS | sanuj: it is different in swig | 13:51 |
@HeikoS | as you can use some from within c++, no? | 13:51 |
@HeikoS | gotta ask yourself why it is not set when swig interface is compiled | 13:51 |
@HeikoS | I gotta run now | 13:52 |
@HeikoS | but be back laster | 13:52 |
@HeikoS | later | 13:52 |
@HeikoS | see you | 13:52 |
@wiking | laster laster | 13:52 |
@wiking | :) | 13:52 |
-!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 13:52 | |
sanuj | wiking, laster? | 13:53 |
@wiking | sanuj: just joking | 13:53 |
sanuj | didn't understand the joke :P | 13:53 |
sanuj | wiking, shall i set HAVE_CXX11 manually in SGBase.i | 13:54 |
sanuj | i want to use some | 13:54 |
sanuj | some.h | 13:54 |
@wiking | mmmm | 14:01 |
@wiking | no | 14:01 |
@wiking | config.h should be there somewhere | 14:02 |
@wiking | (in the Some.h) | 14:02 |
@wiking | to have HAVE_CXX11 set | 14:02 |
@wiking | if it's not included in some.h | 14:02 |
@wiking | then that shoudl be fixed | 14:02 |
sanuj | wiking, it's there in some.h | 14:03 |
sanuj | and config.h has #define HAVE_CXX11 1 | 14:03 |
sanuj | but i haven't included config.h in SGBase.i | 14:04 |
sanuj | shall i do that? | 14:04 |
@wiking | but you dont do that | 14:04 |
@wiking | why would you do that | 14:04 |
sanuj | yeah | 14:05 |
sanuj | just asking | 14:05 |
@wiking | if some.h has shogun/lib/config.h | 14:05 |
@wiking | included | 14:05 |
@wiking | then you have HAVE_CXX11 set | 14:05 |
sanuj | then something else is causing the problem | 14:05 |
@wiking | btw why do we need #include <memory> | 14:05 |
@wiking | ahh nullptr | 14:06 |
@wiking | kk | 14:06 |
@wiking | well dunno | 14:06 |
sanuj | shared_ptr | 14:06 |
sanuj | modshogunPYTHON_wrap.cxx:28917:3: error: ‘Some’ is not a member of ‘shogun’ | 14:06 |
sanuj | shogun::Some< CKernel > *result = 0 ; | 14:06 |
sanuj | wiking, this is the error ^^ | 14:06 |
@wiking | is shogun/base/some.h included somewhere? | 14:06 |
@wiking | i.e. in modshogunPYTHON_wrap.cxx | 14:07 |
@wiking | do you see such an include? | 14:07 |
sanuj | wiking, it wasn't there | 14:07 |
sanuj | i had added %include <shogun/base/some.h> | 14:07 |
@wiking | is it there or not | 14:08 |
@wiking | grep some.h modshogunPYTHON_wrap.cxx | 14:08 |
@wiking | what's the output | 14:08 |
@wiking | modshogunPYTHON_wrap.cxx is somewhere under build/src/interfaces/python_modular/ | 14:09 |
sanuj | wiking, it's there | 14:10 |
@wiking | can you paste here the grep's output plz | 14:10 |
@wiking | do the grep with -n | 14:11 |
sanuj | wiking, okay, i just rebuilt it | 14:11 |
@wiking | why? | 14:11 |
sanuj | after adding #include <shogun/base/some.h> | 14:12 |
sanuj | i had only added %include <shogun/base/some.h> last time | 14:12 |
sanuj | it built successfully now | 14:12 |
sanuj | wiking, thanks :D | 14:14 |
-!- HeikoS [~heiko@nat-177-97.internal.eduroam.ucl.ac.uk] has joined #shogun | 14:45 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 14:45 | |
arianepaola | hello everyone | 14:49 |
-!- HeikoS [~heiko@nat-177-97.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 14:52 | |
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 250 seconds] | 14:53 | |
-!- HeikoS [~heiko@nat-177-97.internal.eduroam.ucl.ac.uk] has joined #shogun | 14:53 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 14:53 | |
@HeikoS | arianepaola: hihi | 14:59 |
@HeikoS | arianepaola: how are things, good weekend? | 14:59 |
arianepaola | hi HeikoS | 15:01 |
arianepaola | busy weekend, reviewing lecture content for exams | 15:02 |
arianepaola | otherwise ok | 15:02 |
arianepaola | and yours? | 15:02 |
@HeikoS | all good! :) | 15:09 |
@HeikoS | arianepaola: gardening mostly ;) | 15:09 |
sanuj | HeikoS, gardening? | 15:09 |
sanuj | you were at home? | 15:09 |
sanuj | lisitsyn, there? | 15:09 |
arianepaola | HeikoS: when the weather was good :-) | 15:09 |
arianepaola | here it has been raining almost non stop since spring and June is more like extremely rainy September | 15:10 |
-!- [Chris] [~Chris]@deadtime.informatik.uni-tuebingen.de] has joined #shogun | 15:14 | |
[Chris] | Hi, I have a question regarding combined kernels and Multiple Kernel Learning. Any experts on this around ? | 15:17 |
arianepaola | hi wiking | 15:24 |
@wiking | what exactly would you need help with | 15:24 |
arianepaola | ^^ wiking: just in time :-) | 15:24 |
@wiking | hello arianepaola | 15:24 |
@wiking | ping you some stuff on the python thing | 15:24 |
arianepaola | I saw your comment on the PR | 15:24 |
@wiking | for the order of things | 15:25 |
arianepaola | version is not ideal to run cmake for, that can be removed | 15:25 |
arianepaola | but the rest needs to run cmake | 15:25 |
arianepaola | it is run by setup.py | 15:25 |
@wiking | yeah but wait | 15:26 |
@wiking | first of all | 15:26 |
@wiking | see that error when i run it | 15:26 |
@wiking | second what is the order in your head | 15:26 |
@wiking | for running setup.py? | 15:26 |
@wiking | does it require a cmake run prior running setup.py? | 15:26 |
arianepaola | the error is probably cmake setup on mac | 15:26 |
-!- HeikoS [~heiko@nat-177-97.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 15:26 | |
@wiking | nmmm it works perfectly | 15:26 |
arianepaola | wiking: it does not require a cmake run prior running setup.py | 15:26 |
@wiking | with cmake | 15:26 |
arianepaola | setup.py runs it for you | 15:26 |
@wiking | ok | 15:27 |
arianepaola | wiking: I tested it on Ubuntu and Fedora and it worked out of the box | 15:27 |
@wiking | so there's something then with python (setup.py) | 15:27 |
@wiking | because for me as you can see it's foobar | 15:27 |
@wiking | and otherwise cmake works perfectly | 15:27 |
@wiking | with shogun | 15:27 |
@wiking | on osx | 15:27 |
arianepaola | it says: CMAKE_OSX_DEPLOYMENT_TARGET is '10.10' but CMAKE_OSX_SYSROOT: | 15:27 |
arianepaola | is not set to a MacOSX SDK with a recognized version. Either set CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to empty. | 15:27 |
@wiking | arianepaola: which is all good | 15:27 |
@wiking | until the fact | 15:27 |
arianepaola | ^^ CMake Error at /usr/local/Cellar/cmake/3.5.2/share/cmake/Modules/Platform/Darwin.cmake:76 | 15:27 |
@wiking | that if i manually run | 15:28 |
@wiking | cmaek .. | 15:28 |
@wiking | cmake .. | 15:28 |
@wiking | no such error | 15:28 |
@wiking | (from build directory) | 15:28 |
arianepaola | wiking: I did test it on clean setup without having anything in build | 15:28 |
arianepaola | I will have a look on Mac | 15:28 |
@wiking | yeah for me the setup.py only started to give such errors | 15:28 |
@wiking | when i rm -rf the build dir | 15:28 |
@wiking | i.e. clean checkout | 15:29 |
@wiking | which is again: weird because it runs fine if i run cmake from cli | 15:29 |
[Chris] | Basically I just want to use two WeightedDegreeRBF kernels with different encodings. I had a look at the examples given at http://shogun-toolbox.org/doc/en/latest/python_modular_examples.html#python_modular_mkl_examples. But as far as I understand in the example different kernels with the same features are used. So I am not sure how to initialize the combined kernel. | 15:29 |
arianepaola | wiking: how did you install cmake? brew, ports, etc? | 15:29 |
@wiking | that one is from brew | 15:29 |
arianepaola | the setup.py just uses cmake | 15:29 |
arianepaola | it could be that it does not read your user environment variable setttings, e.g. PATH | 15:30 |
@wiking | create your combined features | 15:30 |
@wiking | and the corresponding combined kernels | 15:30 |
[Chris] | so one combined features object for both 'RealFeatures' ? | 15:32 |
@wiking | no | 15:32 |
@wiking | i guess there's a reason you wanna use mkl | 15:32 |
@wiking | so i would create a 2 RealFeatures | 15:33 |
@wiking | that i would add to a CombinedFeatures | 15:33 |
@wiking | and create a CombinedKernel | 15:33 |
@wiking | with 2 kernels init | 15:33 |
@wiking | in it | 15:33 |
[Chris] | I guess that's what I did but I get the following error since the features don't have the same length: shogun-4.0.0/src/shogun/features/CombinedFeatures.cpp line 149: Number of feature vectors does not match (expected 180, obj has 201) | 15:34 |
@wiking | yeah i mean | 15:34 |
@wiking | if you wanna have | 15:34 |
@wiking | 2 features | 15:34 |
@wiking | then 2 kernels are needed | 15:34 |
@wiking | btw why do you use 4.0.0 ?: ) | 15:34 |
[Chris] | because it was already installed ;) | 15:35 |
@wiking | heheh | 15:36 |
@wiking | i see | 15:36 |
@wiking | but anyhow that object hasn't changed for al onger time | 15:36 |
@wiking | but still | 15:36 |
@wiking | you should have as many kernels in CombinedKernel as much in CombinedFeatures | 15:37 |
[Chris] | I do | 15:37 |
@wiking | mmmm | 15:37 |
[Chris] | it's two features and two kernels | 15:37 |
[Chris] | I mean two feature encodings | 15:38 |
@wiking | mmm | 15:38 |
@wiking | but ah | 15:38 |
@wiking | yeah the problem is | 15:38 |
@wiking | that in one of the features | 15:38 |
@wiking | you have 180 examples | 15:38 |
@wiking | while in the other 201 | 15:38 |
@wiking | btw note | 15:38 |
@wiking | that in shogun the columsn are the feature vectors | 15:39 |
@wiking | i.e. 1 example | 15:39 |
@wiking | rows are the features itself | 15:39 |
@wiking | so you might need to transpose your input | 15:39 |
[Chris] | yeah that might be the problem | 15:39 |
-!- HeikoS [~heiko@nat-177-97.internal.eduroam.ucl.ac.uk] has joined #shogun | 15:39 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 15:39 | |
@wiking | [Chris]: as i suppose one feature set has 180 features the other 201 | 15:40 |
@wiking | and not the amount of examples | 15:40 |
@wiking | (samples) | 15:40 |
[Chris] | it's 90 samples actually | 15:41 |
[Chris] | one feature encoding has a length of 180, the other one has a length of 201 | 15:41 |
[Chris] | so 90* vectors of length 180, 90* vectors of length 201 | 15:42 |
[Chris] | does that make sense ? | 15:42 |
arianepaola | wiking: did you test setup.py on a Linux? | 15:45 |
@HeikoS | lisitsyn: jo | 15:53 |
@HeikoS | lisitsyn: how are progress bars done? | 15:53 |
@HeikoS | libcurl? | 15:53 |
@HeikoS | lisitsyn: can we somehow have this here? | 15:53 |
@HeikoS | https://github.com/tqdm/tqdm | 15:53 |
arianepaola | HeikoS: there's also a nice progress bar in npm, but this one looks better | 15:55 |
@HeikoS | arianepaola: question is: can we use SG_PROGRESS | 15:55 |
@wiking | arianepaola: there's no cmake anywhere else :) | 15:55 |
@HeikoS | and then the bar is displayed in python | 15:56 |
sanuj | can someone tell me | 15:56 |
@HeikoS | but this is off topic, so nevermind | 15:56 |
@HeikoS | lisitsyn: whats all the spaces in some.h? | 15:56 |
arianepaola | wiking: ? | 15:56 |
@wiking | [Chris]: yesah so just transpose your input then | 15:56 |
@wiking | arianepaola: "As Viktor mentioned, cmake was installed using brew. The setup.py script uses the default system cmake and might not have picked up the updated user's PATH. | 15:56 |
arianepaola | wiking: what do you mean? | 15:56 |
@wiking | " | 15:56 |
@wiking | i only have the one cmake by brew | 15:56 |
arianepaola | ah ok | 15:56 |
arianepaola | ok | 15:56 |
sanuj | how to debug when i don't see functions in python that i implemented via swig | 15:57 |
arianepaola | wiking: did you get to test it on a Linux distro? | 15:57 |
@HeikoS | sanuj: ? | 15:57 |
@wiking | sanuj: check your modshogun....cxx | 15:57 |
sanuj | yeah | 15:57 |
sanuj | it's huge | 15:57 |
@wiking | arianepaola: not yet | 15:57 |
@HeikoS | sanuj: what do you want do to? | 15:57 |
sanuj | i have %template(someKernel) Some<shogun::CKernel>; | 15:58 |
sanuj | and %template(TagKernel) Tag<someKernel>; | 15:58 |
sanuj | but in python | 15:58 |
sanuj | TagKernel is not there | 15:59 |
arianepaola | wiking: ok | 15:59 |
sanuj | it builds successfully | 15:59 |
@HeikoS | sanuj: 1. make sure your python is using the correct modshogun.py | 15:59 |
sanuj | yes it is | 15:59 |
@HeikoS | 2.) grep modshoguncxx | 15:59 |
@HeikoS | and grep modshogun.py | 15:59 |
@HeikoS | 3. check swig output | 15:59 |
sanuj | for TagKernel? | 16:00 |
sanuj | which swig output | 16:00 |
@HeikoS | sanuj: I dont know, have a look in the file to see how wrapped classes look like | 16:00 |
@HeikoS | sanuj: maybe swig complains about something missing while running? | 16:00 |
@HeikoS | Ill be back after the talk we have here now | 16:00 |
sanuj | okay, let me see | 16:00 |
@wiking | fuuuuuuuuuuuuuuuuuuuuuck | 16:01 |
@wiking | "“$196 per share for LinkedIn (LNKD, Tech30), a 50% premium over the stock's closing price on Friday”" | 16:01 |
@wiking | linkedin employees must have been on coke for the whole weekend :) | 16:01 |
sanuj | microsoft bought linkedin | 16:01 |
arianepaola | wiking: you are missing some uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuus | 16:01 |
sanuj | haha | 16:02 |
arianepaola | wiking: depends if they get to sell the shares fast before they drop | 16:02 |
@wiking | i mean m$ bought it from them | 16:02 |
@wiking | in double price | 16:02 |
@wiking | so it's all cool | 16:03 |
arianepaola | wiking: news :-) | 16:04 |
arianepaola | wiking: looks like photoshop http://news.microsoft.com/2016/06/13/microsoft-to-acquire-linkedin/#sm.00003skp96pg5d8911tddaak1v6tv | 16:07 |
@wiking | loooooooooooooooooooooool | 16:09 |
@wiking | https://www.google.com.sg/search?q=LNKD&oq=LNKD&aqs=chrome..69i57.142j0j7&sourceid=chrome&ie=UTF-8 | 16:09 |
arianepaola | specially the non existing shadows of the three anywhere on the photo | 16:09 |
@wiking | hahaha price just jumped | 16:10 |
@wiking | well yeah | 16:11 |
@wiking | hope somebody on this channel had some linkedin shares :) | 16:11 |
-!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has joined #shogun | 16:12 | |
sanuj | wiking, have you been to NUS? | 16:12 |
@wiking | sanuj: as in? | 16:13 |
sanuj | visited it for some reason | 16:13 |
@wiking | yeah i mean i visited it once .... but i have not went there to study or something | 16:13 |
sanuj | okay | 16:13 |
@wiking | why? | 16:13 |
sanuj | how's it? | 16:13 |
sanuj | i'm planning to apply for a research intern there | 16:14 |
@wiking | aaah dunno | 16:14 |
sanuj | okie | 16:14 |
@wiking | sorry | 16:14 |
sanuj | man i hate debugging :D | 16:14 |
OXPHOS | wiking: hey | 16:16 |
OXPHOS | wiking: wanna check the linalg I updated? | 16:16 |
@wiking | mmm link plz | 16:16 |
@wiking | too many shit is around | 16:16 |
@wiking | sorry my machine died | 16:17 |
@wiking | my current devenv is like shitz | 16:17 |
OXPHOS | wiking: https://github.com/shogun-toolbox/shogun/pull/3277 thx. | 16:20 |
OXPHOS | wiking: my machine is on the edge of dying too..hope it won't die too fast | 16:21 |
OXPHOS | HeikoS, lambday: there? | 16:21 |
@lambday | OXPHOS: yo | 16:22 |
OXPHOS | lambday: hey! wanna check the update? https://github.com/shogun-toolbox/shogun/pull/3277 | 16:22 |
@lambday | OXPHOS: yeah sure.. let me have a look | 16:23 |
@wiking | mmm | 16:23 |
@wiking | ok so | 16:23 |
@wiking | can i ask still why do we need | 16:23 |
@wiking | gpuvectro and cpu vector | 16:23 |
@wiking | and what is linalgvector | 16:24 |
@wiking | we have like 5 vectors now :) | 16:24 |
@wiking | dont really get why | 16:24 |
@lambday | wiking: haha true.. we don't need that cpuvector and gpuvector anymore | 16:24 |
@lambday | OXPHOS: just name it Vector :D | 16:24 |
@wiking | what is linalgvector and sgvector diff? | 16:24 |
@lambday | nobody likes too much typing | 16:24 |
@lambday | btw wiking could you please comment on the discussion of the vector class in https://github.com/shogun-toolbox/shogun/pull/3278? | 16:25 |
@wiking | i mean why do we need linalgvector? | 16:25 |
@lambday | wiking: I mean,this is what you had in mind> | 16:25 |
OXPHOS | wiking: there's no cpuvector and gpuvector anymore, just linalgvector(or vector) | 16:25 |
@lambday | wiking: so you wanted that we make these changes in SGVector? | 16:25 |
@wiking | well i mean would be good to have the ONE vector | 16:25 |
@lambday | wiking: true | 16:26 |
@wiking | no need for all these different names | 16:26 |
@wiking | it's gonna be confusing | 16:26 |
@wiking | as it is already for many | 16:26 |
@wiking | class GPUVectorImpl = supposed to be the opaque ? | 16:26 |
OXPHOS | yes | 16:26 |
@lambday | wiking: well, SG one is for modular interfaces,.. this Vector class is supposed to be only linalg internal | 16:26 |
@wiking | lambday: but you gonna be using this | 16:27 |
@wiking | as well from python interface no? | 16:27 |
@wiking | or if not why not? | 16:27 |
@wiking | and then if yes why the differentiation? | 16:27 |
@lambday | wiking: python typemap horror? SG one already works with numpy and java.. | 16:28 |
@wiking | lambday: so should linalg no? | 16:28 |
@wiking | btw bool m_onGPU | 16:28 |
@wiking | you should | 16:28 |
@wiking | alignas(64) bool m_onGPU; | 16:28 |
@wiking | as you depend on c++11 | 16:28 |
@wiking | same for index_t m_len; | 16:28 |
@wiking | for T* m_data | 16:29 |
@lambday | wiking: alright.. | 16:29 |
@wiking | typedef typename std::aligned_storage<sizeof(T), std::alignment_of<T>::value>::type aligned_t; | 16:29 |
@lambday | holy shit! :d | 16:29 |
@wiking | and and T* should be that irght? | 16:29 |
@wiking | *right | 16:29 |
@lambday | yeah | 16:30 |
@wiking | because you wanna work with aligned memory | 16:30 |
@wiking | in vectors/matrices | 16:30 |
@wiking | and use alignas | 16:30 |
@lambday | wiking: true.. this is great idea! | 16:30 |
@wiking | http://en.cppreference.com/w/cpp/language/alignas | 16:30 |
@wiking | and since you guys depend on c++11 | 16:30 |
@wiking | you can use these things | 16:30 |
@lambday | wiking: but should we make all these changes in SGVector itself? | 16:31 |
@wiking | i would do it yeah | 16:31 |
@wiking | i mean | 16:31 |
@wiking | now we have | 16:31 |
@wiking | SGVECTor | 16:31 |
@wiking | and GPUvector | 16:31 |
@lambday | I thought it would be too messy for now.. so suggested that we should have | 16:31 |
@wiking | that needs to be anyways merged | 16:31 |
@wiking | because that's already way too massy | 16:31 |
@wiking | and then sgvector doesn't use aligned things | 16:31 |
@wiking | that is again a performance issue | 16:31 |
@wiking | the memory being used there should be at least | 16:31 |
@wiking | 16byte aligned | 16:32 |
@wiking | same goes for sgmatrix | 16:32 |
@wiking | and the class properties taht are being accessed a lot | 16:32 |
@lambday | wiking: can we use eigen3 maps with those? I mean, aligned_t ? | 16:32 |
@wiking | should be prefixed with alignedas | 16:33 |
@wiking | lambday: just have to specify the alignment | 16:33 |
@wiking | lambday: eigen supports all these things | 16:33 |
@lambday | wiking: great then! | 16:33 |
@wiking | lambday: the other name for this is 'stride' | 16:34 |
@lambday | yeah | 16:34 |
@wiking | so yeah you can map these to eigen | 16:34 |
@wiking | and should add some performance gain | 16:34 |
@lambday | yeah that't true | 16:35 |
@lambday | I am just worried about making all these changes into SGVector already.. things will be broken | 16:35 |
@lambday | but yeah it's good to have just one class anyway | 16:36 |
@lambday | gotta find an iterative way of doing this.. | 16:36 |
@wiking | and the alignas should be with the size of cpu cache to avoid false caching (64 byte usually) | 16:37 |
@lambday | okay | 16:37 |
@wiking | those things can hurt us a lot | 16:37 |
@wiking | but then again | 16:37 |
@wiking | on gpu things are different :P | 16:38 |
@lambday | one thing of concern if we use this alignas in SGVector.. the whole thing will be unavailable if c++11 is not there! | 16:38 |
@wiking | lambday: posix_memalign | 16:38 |
@wiking | lambday: you can do the same | 16:38 |
@wiking | the only thing is that it's not so elegant | 16:38 |
@wiking | but afaik | 16:38 |
@wiking | we'll require c++11 | 16:38 |
@wiking | with the post gsoc release | 16:39 |
@wiking | so you shouldn't be concerned about that | 16:39 |
@wiking | :) | 16:39 |
@lambday | haha finally we agreed on this :D | 16:39 |
@wiking | yeah that was agreed a long time ago | 16:39 |
@wiking | but for post gsoc | 16:39 |
@wiking | but what OXPHOS is working on | 16:39 |
@wiking | can be all c++11 only | 16:39 |
@wiking | so dont worry about how to do it w/o c++11 | 16:40 |
@lambday | wiking: so what do you suggest? should she go ahead with this separate vector class for now? or make changes in SGVector already? | 16:40 |
@wiking | mm lets see how this works | 16:41 |
@wiking | fix all the lalalas | 16:41 |
@wiking | (mentioned above) | 16:41 |
@wiking | and then merge back things to sgvector | 16:41 |
@lambday | wiking: cool then | 16:41 |
@wiking | and get rid of gpuvector | 16:41 |
@lambday | yeah this sounds better for me too.. not touching too many things at once is good | 16:41 |
@lambday | wiking: surely! | 16:41 |
@lambday | OXPHOS: did you follow? ^ | 16:42 |
OXPHOS | the first step is to add aligned stuff right | 16:42 |
OXPHOS | if that works, merge the Vector back to SGVector | 16:42 |
@lambday | OXPHOS: yeah and have the members in proper order.. | 16:42 |
@lambday | now you have the unique_ptr for gpu vector as the first member | 16:43 |
@wiking | lambday: order should not matter | 16:43 |
@lambday | which should not be the case | 16:43 |
@wiking | if you align things in the class | 16:43 |
@wiking | hence the alignas(64) | 16:43 |
@lambday | wiking: yeah but doesn't it make sense to have the "hot" data first? | 16:44 |
@wiking | yeah i mean you can put it there | 16:44 |
@wiking | but still | 16:44 |
@wiking | make those aligned | 16:45 |
@lambday | wiking: totally agree! | 16:45 |
@wiking | because a class can get messy | 16:45 |
@lambday | yeah | 16:45 |
@wiking | so not only the allocated mem should be aligned | 16:45 |
@wiking | but the position of the class variable | 16:45 |
OXPHOS | just prefix alignas(64) to everything (sort of) | 16:45 |
@wiking | mmm more or less yeah | 16:46 |
OXPHOS | if that works, i'll move forward and dump stuff in SGVector | 16:46 |
@wiking | although | 16:46 |
@wiking | i would do this | 16:46 |
@lambday | OXPHOS: yeah that gives you cache-line friendly loading I guess | 16:46 |
@wiking | +/** CPU cache line size */ | 16:46 |
@wiking | +#define CPU_CACHE_LINE_SIZE 64 | 16:46 |
@wiking | add this to src/shogun/lib/common.h | 16:46 |
@wiking | (note the + as it comes from a local change of mine) | 16:47 |
@wiking | and then use | 16:47 |
@wiking | alignas(CPU_CACHE_LINE_SIZE) | 16:47 |
@lambday | yep | 16:47 |
OXPHOS | okay | 16:47 |
@wiking | instead of burning there magical consts | 16:47 |
@wiking | who knows what the future will bring :P | 16:47 |
OXPHOS | i saw we can do class alignas(CPU_CACHE_LINE_SIZE) | 16:47 |
OXPHOS | still checking but will this restrict the whole class to the size? | 16:47 |
@wiking | nono | 16:48 |
@wiking | this is all abou | 16:48 |
@wiking | the memory layout | 16:48 |
@wiking | of the class itself | 16:48 |
OXPHOS | i see | 16:48 |
@wiking | regardles the variable's size in bytes | 16:49 |
@wiking | it'll be padded | 16:49 |
@wiking | so that way it'll be nicely aligned | 16:49 |
@wiking | and that is for example important | 16:49 |
@wiking | on multi-core machines | 16:49 |
@wiking | https://en.wikipedia.org/wiki/False_sharing | 16:49 |
@wiking | if you are interested about the phenomenon | 16:50 |
OXPHOS | thx! | 16:50 |
@wiking | this is a more in depth thingy: http://www.drdobbs.com/parallel/eliminate-false-sharing/217500206 | 16:51 |
@wiking | anyhow | 16:51 |
@wiking | just make sure that you nicely align your class layout in memory :) | 16:51 |
@wiking | and then about why it is generally good to align nicely a memory chunk | 16:52 |
@wiking | (see sgvector) | 16:52 |
@wiking | you should read about SIMD operations | 16:52 |
@wiking | if you are interested | 16:52 |
@wiking | but yeah in general even moving memory is faster when it is aligned | 16:53 |
@lambday | wiking: nice article | 16:53 |
@wiking | so much about optimizations | 16:54 |
@wiking | i'm off to sleep | 16:54 |
@wiking | ttyl | 16:55 |
@lambday | haha alright have some rest | 16:55 |
@lambday | OXPHOS: how are you? :D | 16:55 |
@lambday | OXPHOS: all good? | 16:55 |
OXPHOS | lambday: jeje | 16:56 |
OXPHOS | wiking: thx! good night! | 16:56 |
arianepaola | bye wiking | 16:56 |
@wiking | btw i wonder | 16:57 |
@wiking | for (int i = 0; i < N; ++i) x[i] = y[i]/scalar | 16:58 |
@wiking | will this be optimized into | 16:58 |
@wiking | s = 1/scalar | 16:58 |
@wiking | for (int i = 0; i < N; ++i) x[i] = y[i]*s | 16:58 |
@lambday | tough to say.. if scalar was const then maybe.. but can't tell unless we check | 17:00 |
@wiking | there was something like this in Saurabh7's kmeans pr | 17:01 |
@wiking | anyhow enforcing that woudl be good | 17:01 |
@wiking | as it's really unnecessary | 17:02 |
@wiking | multiplication is much cheaper | 17:02 |
@lambday | yep | 17:02 |
@lambday | wiking: you started to talk like herb sutter :D | 17:03 |
@wiking | who's taht? | 17:03 |
@lambday | haha nice one | 17:03 |
arianepaola | lmao | 17:04 |
@wiking | aaah i see | 17:04 |
@wiking | mmm never heard his name :) | 17:04 |
@wiking | mmm good stuff | 17:06 |
@wiking | heheh http://www.drdobbs.com/architecture-and-design/know-when-to-use-an-active-object-instea/227500074?pgno=3 | 17:07 |
@wiking | love that lambda expression | 17:07 |
[Chris] | wiking: thanks for your help | 17:08 |
@wiking | [Chris]: nw | 17:08 |
[Chris] | unfortunately when I call mkl.train() now I get a Floating point exception :) | 17:09 |
@wiking | mmmm that is weird | 17:10 |
@wiking | ask the people here | 17:10 |
@wiking | somebody who's still awake will be able to help | 17:10 |
@wiking | but if u dont get an answer | 17:10 |
@wiking | just write to the mailing list | 17:10 |
@wiking | somebody will get back to u | 17:10 |
@wiking | promize | 17:10 |
[Chris] | alright, thank you | 17:11 |
OXPHOS | wanna ask, what was this for? typedef typename std::aligned_storage<sizeof(T), std::alignment_of<T>::value>::type aligned_t | 17:13 |
@wiking | OXPHOS: when you do a malloc | 17:14 |
@wiking | or a new | 17:14 |
@wiking | so say you have T* whatever | 17:14 |
@wiking | T* whatever = new aligned_t[size] | 17:15 |
OXPHOS | wiking: okay lemme try. thx! | 17:15 |
@wiking | i reckon you'll have to do a reinterpret_cast<T*> | 17:15 |
@wiking | so T* whatever = reinterpret_cast<T*>(new aligned_t[size]) | 17:15 |
OXPHOS | and the unique ptr suppose to be involved in the stuff too right.. | 17:16 |
@lambday | OXPHOS: that's easy.. | 17:16 |
@wiking | well that's just an extra addon around the mem | 17:16 |
OXPHOS | okay lemme just play around.. | 17:17 |
@lambday | wiking: I wonder whether std::copy would work with T* and alighed_t* | 17:18 |
@lambday | should be fine I guess | 17:18 |
@lambday | it takes two different iterators | 17:18 |
@lambday | OXPHOS: make sure you do deep copy for now when constructing a Vector from SGVector | 17:20 |
OXPHOS | lambday: got it | 17:21 |
-!- sanuj [~sanuj@117.204.250.149] has quit [Ping timeout: 252 seconds] | 17:23 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 17:31 | |
shogun-notifier- | shogun: lambday :feature/bigtest * d52850f / / (5 files): https://github.com/shogun-toolbox/shogun/commit/d52850f4b01f684571a327f16c2c4c81031461e6 | 17:31 |
shogun-notifier- | shogun: moved compute_distance to twodistributiontest, added unittest | 17:31 |
shogun-notifier- | shogun: lambday :feature/bigtest * 2b156a3 / / (13 files): https://github.com/shogun-toolbox/shogun/commit/2b156a34e6b31c56fd3ea318bc4967fd10651078 | 17:31 |
shogun-notifier- | shogun: added first draft of multi kernel MMD | 17:31 |
-!- HeikoS [~heiko@nat-177-97.internal.eduroam.ucl.ac.uk] has quit [Ping timeout: 264 seconds] | 17:37 | |
lisitsyn | you've got thousands of messages here | 17:38 |
-!- besser82 [~besser82@fedora/besser82] has joined #shogun | 17:41 | |
-!- mode/#shogun [+o besser82] by ChanServ | 17:41 | |
-!- besser82_ [~besser82@fedora/besser82] has joined #shogun | 17:43 | |
-!- mode/#shogun [+o besser82_] by ChanServ | 17:43 | |
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 240 seconds] | 17:47 | |
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun | 17:54 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 17:54 | |
-!- besser82_ [~besser82@fedora/besser82] has quit [Ping timeout: 276 seconds] | 18:01 | |
OXPHOS | lambday: | 18:02 |
OXPHOS | hey | 18:02 |
OXPHOS | was trying to construct Vector like: m_data = SG_MALLOC(T, vector.vlen); memcpy(m_data, vector.vector, sizeof(T)*vector.vlen); | 18:03 |
OXPHOS | how can i put that aligned stuff in? | 18:04 |
@lambday | OXPHOS: why not simply use what wiking wrote? | 18:11 |
@lambday | just replace new with SG_MALLOC if you want to use that | 18:11 |
@lambday | OXPHOS: but I'd just do the copy first and then do reinterpret_cast | 18:12 |
@lambday | somehting like | 18:12 |
OXPHOS | lambday I'm doing m_data = reinterpret_cast<T>(SG_MALLOC(aligned_t, vector.vlen)); | 18:12 |
@lambday | malloc returns a ptr | 18:13 |
@lambday | you're casting it to T :D | 18:13 |
@lambday | OXPHOS: but do the copy first then assign it to m_data | 18:13 |
OXPHOS | aaah | 18:13 |
@lambday | have a temporary variable, call it just "data".. | 18:13 |
@lambday | std::copy to data | 18:14 |
@lambday | then reinterpret_cast that to T* | 18:14 |
OXPHOS | i don't think copy works actually, can only use memcpy | 18:14 |
OXPHOS | why is that? | 18:14 |
@lambday | std::copy doesn't work? | 18:14 |
@lambday | I said this because while copying, you'll have to cast it back to aligned_t* anyway.. otherwise copy will fail | 18:15 |
OXPHOS | lambday: yes there's a std::copy in benchmark and it returns an empty vector | 18:15 |
@lambday | OXPHOS: err what? | 18:15 |
@lambday | which benchmakr? | 18:15 |
-!- besser82_ [~besser82@fedora/besser82] has joined #shogun | 18:15 | |
-!- mode/#shogun [+o besser82_] by ChanServ | 18:15 | |
@lambday | OXPHOS: trust std:: ;) | 18:15 |
OXPHOS | lambday: matrix_product_benchmark | 18:15 |
@lambday | OXPHOS: then it's using it wrong! | 18:16 |
OXPHOS | lambday: yeah.. I thought there's no iterator in SGVector | 18:16 |
@lambday | OXPHOS: the reason I am asking to use std::copy because it can handle two different iterator types | 18:16 |
@lambday | although I don't know whether std::aligned_storage can be used with ++ | 18:17 |
@lambday | let me check | 18:17 |
@lambday | mhm | 18:18 |
@lambday | not possible | 18:18 |
OXPHOS | SGVector is not aligned right? I didn't see any sign of align there | 18:19 |
@lambday | OXPHOS: not aligned | 18:19 |
OXPHOS | lambday: er..why is m_data T* type not align_T type? | 18:20 |
@lambday | OXPHOS: that is what your job is : to make it aligned_t* | 18:20 |
@lambday | but in Vector, not yet in SGVector | 18:21 |
@lambday | we'll see that later | 18:21 |
OXPHOS | so it should be like aligned_t* m_data | 18:22 |
OXPHOS | and in constructor we can malloc(aligned_t, ...) | 18:22 |
OXPHOS | and cast SGVector to aligned_t | 18:22 |
OXPHOS | lambday ^ | 18:22 |
@lambday | OXPHOS: yeah | 18:23 |
@lambday | OXPHOS: but wait.. we need to make std::copy with with this | 18:23 |
@lambday | OXPHOS: checking | 18:23 |
@lambday | OXPHOS: not cast SGVector to aligned_t.. rather deep copy SGVector's "vector" to our "m_data" | 18:24 |
-!- sanuj [~sanuj@117.204.250.149] has joined #shogun | 18:25 | |
OXPHOS | lambday: i mean in std::copy() we cannot just copy SGVector, but casted SGVector? | 18:25 |
sanuj | lisitsyn, got time? | 18:26 |
OXPHOS | even if there is a temp container to hold deep-copied SGVector | 18:26 |
OXPHOS | lambday: there's still a convert step right? | 18:26 |
@lambday | OXPHOS: what do you mean by casted SGVector? | 18:28 |
@lambday | see, SGVector has an array of T, we need to deep copy that, but as an array of aligned_t instead | 18:28 |
@lambday | OXPHOS: one obvious way to do this is to copy things element-by-element | 18:29 |
@lambday | OXPHOS: but that's slow as shit! so would be better if we could copy a chunk.. | 18:29 |
OXPHOS | lambday: yeah I was just wondering how to copy from T to aligned_t.. | 18:29 |
@lambday | OXPHOS: yeah so I am just checking what does it take for std::copy to work | 18:30 |
@lambday | OXPHOS: hang on | 18:30 |
OXPHOS | lambday: haha okay sry | 18:30 |
@lambday | OXPHOS: nah seems like you have to store it at T* only | 18:45 |
-!- besser82_ [~besser82@fedora/besser82] has quit [Ping timeout: 276 seconds] | 18:46 | |
@lambday | OXPHOS: so just do m_data = reinterpret_cast<T*>(SG_MALLOC(aligned_t, vector.vlen)); | 18:47 |
@lambday | and then copy | 18:47 |
OXPHOS | lambday: okay so m_data is still T* type | 18:48 |
@lambday | OXPHOS: yep.. but by creation you made it aligned | 18:48 |
OXPHOS | lambday: yeah | 18:49 |
@lambday | OXPHOS: let me know whether copy works | 18:50 |
@lambday | OXPHOS: oh make sure you delete this thing in destructor properly! | 18:50 |
OXPHOS | lambday: sure | 18:51 |
@lambday | you may need to cast it back to be able to delete properly | 18:52 |
arianepaola | ccccccevhrjdnuevertkjddcdcihveurfecbtgfbukkl | 18:53 |
arianepaola | ccccccevhrjdtdlctvvjbgjtrvnichblddcfirrurigd | 18:53 |
arianepaola | sorry | 18:53 |
@lambday | arianepaola: how many cats do you have? | 18:53 |
@lambday | :P | 18:53 |
-!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Read error: Connection reset by peer] | 18:54 | |
-!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun | 18:57 | |
arianepaola | lambday: :p | 19:02 |
OXPHOS | @lambday: std::copy worked | 19:14 |
-!- mizari [~mizari@95-174-213-100.nts.su] has quit [Quit: Leaving] | 19:14 | |
OXPHOS | how can i know whether the destructor is functioning properly? | 19:14 |
-!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Quit: Leaving.] | 19:15 | |
-!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun | 19:16 | |
OXPHOS | lambday: or we'll use unref()? | 19:16 |
@lambday | OXPHOS: ref unref will only work if it is a subclass of CSGObject or SGReferenceData | 19:21 |
@lambday | OXPHOS: just valgrind it :) | 19:21 |
-!- GandalfTheWizard [~Eva@112.10.170.90] has quit [Quit: Leaving.] | 19:21 | |
OXPHOS | lambday: i mean finally it's gonna be ~SGVector() right. im now using free() | 19:22 |
OXPHOS | and trying align_unique_ptr now | 19:22 |
@lambday | OXPHOS: yeah but we're not quite there yet :) | 19:22 |
CaBa | hi | 19:26 |
sanuj | lisitsyn, got time? :) | 19:39 |
lisitsyn | sanuj: yeah a little bit | 19:40 |
sanuj | lisitsyn, Some<shogun::CKernel> i have manged to build | 19:40 |
sanuj | but it is not showing in python | 19:40 |
sanuj | like TagKernel | 19:40 |
sanuj | etc | 19:40 |
lisitsyn | why? | 19:41 |
sanuj | and what are the next steps for swig interface | 19:41 |
sanuj | lisitsyn, dunno, modshogunpython looks fine | 19:41 |
lisitsyn | well what next steps if it doesn't work yet :P | 19:41 |
sanuj | haha | 19:41 |
sanuj | i dunno how to debug this | 19:41 |
lisitsyn | sanuj: well have you declared it? like TagInt | 19:42 |
sanuj | lisitsyn, yes, i also see the wrapper functions in modshogunpython | 19:43 |
sanuj | the big file that is generated | 19:43 |
lisitsyn | so you have some definition of TagKernel? | 19:44 |
sanuj | yeah | 19:44 |
sanuj | lisitsyn, stuff like SWIGINTERN int _wrap_new_TagKernel__SWIG_0(PyObject *self, PyObject *args) { | 19:44 |
lisitsyn | then are you sure it is not other shogun you're using? | 19:44 |
sanuj | path is correct | 19:44 |
OXPHOS | lambday: the pimpl points to a class so i guess it is fine keeping it intact without aligned_storage stuff? | 19:47 |
OXPHOS | i updated the PR if you'd like to check | 19:47 |
sanuj | lisitsyn, do you have time to try it on your local? | 19:47 |
sanuj | i can push it on my branch | 19:47 |
OXPHOS | lambday: also the ViennaCL ptr.. I didt touch it yet | 19:47 |
lisitsyn | sanuj: yeah I could | 19:47 |
sanuj | okay, i'll give you the link | 19:47 |
sanuj | lisitsyn, https://github.com/sanuj/shogun/tree/tags-swig | 19:50 |
sanuj | lisitsyn, did you clone? | 19:54 |
sanuj | lambday, did you go to deepmind? | 20:13 |
@HeikoS | sanuj: not yet | 20:16 |
sanuj | okay | 20:16 |
@HeikoS | but just asked them when is good :) | 20:16 |
sanuj | so when? :) | 20:17 |
sanuj | just came across Dark Blue Labs on the web | 20:17 |
sanuj | funny name :D | 20:17 |
@HeikoS | sanuj: dont know hopefully this week | 20:21 |
@HeikoS | Dark Blue labs? | 20:21 |
@HeikoS | what is that? | 20:21 |
sanuj | HeikoS, http://www.cs.ox.ac.uk/people/nando.defreitas/ | 20:22 |
sanuj | http://darkbluelabs.com/ | 20:22 |
sanuj | acquired by deepmind | 20:22 |
@HeikoS | ah yeah | 20:22 |
@HeikoS | I forgot | 20:22 |
sanuj | HeikoS, too much ai going on | 20:24 |
@HeikoS | yeah | 20:24 |
@HeikoS | too much money | 20:24 |
sanuj | $$ | 20:24 |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 20:31 | |
sanuj | going to sleep | 20:35 |
sanuj | goodnight folks | 20:35 |
@lambday | OXPHOS: yeah should be fine.. | 20:36 |
@lambday | OXPHOS: I'll check a bit | 20:36 |
@lambday | sanuj: no I haven't yet | 20:36 |
sanuj | lambday, okay | 20:37 |
sanuj | busy with intern? | 20:37 |
@lambday | sanuj: hehe not that much | 20:38 |
sanuj | how's the gujarati family :D | 20:38 |
sanuj | okay | 20:38 |
@lambday | sanuj: they cooked chicken yesterday, if you can believe that! | 20:38 |
sanuj | haha | 20:38 |
sanuj | lambday, bye :) | 20:40 |
@lambday | sanuj: bye! see you! | 20:40 |
-!- sanuj [~sanuj@117.204.250.149] has quit [Quit: Leaving] | 20:41 | |
-!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Ping timeout: 244 seconds] | 21:34 | |
arianepaola | bye everyone, until tomorrow | 21:54 |
lisitsyn | bazdmeg! | 22:32 |
-!- sonne|osx [~sonne@x4e31fd0a.dyn.telefonica.de] has joined #shogun | 23:01 | |
--- Log closed Tue Jun 14 00:00:39 2016 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!