Open in new window / Try shogun cloud
--- Log opened Mon Jul 13 00:00:50 2015
-!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has joined #shogun00:02
-!- mode/#shogun [+o thoralf] by ChanServ00:02
-!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has quit [Quit: Konversation terminated!]00:19
-!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has joined #shogun00:24
-!- mode/#shogun [+o thoralf] by ChanServ00:24
-!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has quit [Quit: Konversation terminated!]01:13
-!- HeikoS [~heiko@05419e79.skybroadband.com] has quit [Read error: No route to host]01:20
-!- HeikoS [~heiko@05419e79.skybroadband.com] has joined #shogun01:21
-!- mode/#shogun [+o HeikoS] by ChanServ01:21
-!- HeikoS [~heiko@05419e79.skybroadband.com] has quit [Client Quit]01:21
shogun-buildbotbuild #1023 of nightly_default is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1023  blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com>, Bj?rn Esser <bjoern.esser@gmail.com>04:09
-!- shaochuan [~shaochuan@c-50-184-81-180.hsd1.ca.comcast.net] has joined #shogun06:41
-!- shaochuan [~shaochuan@c-50-184-81-180.hsd1.ca.comcast.net] has quit [Remote host closed the connection]06:59
-!- shaochuan [~shaochuan@2601:647:4600:fac5:71c9:6bdb:8191:ecb8] has joined #shogun07:30
-!- shaochuan [~shaochuan@2601:647:4600:fac5:71c9:6bdb:8191:ecb8] has quit [Ping timeout: 248 seconds]07:34
-!- vortex_ape [~vortex_ap@120.59.75.202] has joined #shogun10:16
-!- vortex_ape [~vortex_ap@120.59.75.202] has quit [Client Quit]10:20
-!- vortex_ape [~vortex_ap@120.59.75.202] has joined #shogun10:20
-!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has joined #shogun10:22
-!- vortex_ape [~vortex_ap@120.59.75.202] has quit [Ping timeout: 256 seconds]10:28
-!- HeikoS [~heiko@05419e79.skybroadband.com] has joined #shogun10:55
-!- mode/#shogun [+o HeikoS] by ChanServ10:55
-!- HeikoS [~heiko@05419e79.skybroadband.com] has quit [Ping timeout: 246 seconds]11:10
-!- HeikoS [~heiko@host-92-28-127-28.as13285.net] has joined #shogun11:41
-!- mode/#shogun [+o HeikoS] by ChanServ11:41
-!- HeikoS [~heiko@host-92-28-127-28.as13285.net] has quit [Quit: Leaving.]11:53
-!- HeikoS [~heiko@nat-162-94.internal.eduroam.ucl.ac.uk] has joined #shogun12:23
-!- mode/#shogun [+o HeikoS] by ChanServ12:23
-!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3]13:46
-!- Netsplit *.net <-> *.split quits: @besser8217:37
-!- Netsplit *.net <-> *.split quits: shogun-buildbot17:37
-!- Netsplit over, joins: shogun-buildbot17:37
-!- Netsplit over, joins: besser8217:38
-!- mode/#shogun [+o besser82] by ChanServ17:38
-!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has joined #shogun18:17
@wikingping19:13
-!- HeikoS [~heiko@nat-162-94.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.]19:21
-!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3]19:29
@wikingstamm stamm19:33
@wikingnobody stma?19:33
@wiking:D19:33
-!- lambday [6a3386ac@gateway/web/freenode/ip.106.51.134.172] has joined #shogun19:41
-!- mode/#shogun [+o lambday] by ChanServ19:41
-!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has joined #shogun19:44
-!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3]19:54
@besser82wiking, I'm hier for Stamm ^_^19:56
* besser82 hands some virtual steins out to other folks19:56
-!- yorkerlin [b8af2f1e@gateway/web/freenode/ip.184.175.47.30] has joined #shogun19:58
-!- HeikoS [~heiko@05419e79.skybroadband.com] has joined #shogun20:00
-!- mode/#shogun [+o HeikoS] by ChanServ20:00
-!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has joined #shogun20:00
-!- mode/#shogun [+o thoralf] by ChanServ20:01
@thoralfHeyho.20:01
@HeikoSthoralf: yo20:01
@HeikoSthoralf: hey man good to see you!20:01
-!- iglesiasg [~iglesias@524B8E0B.cm-4-4c.dynamic.ziggo.nl] has joined #shogun20:02
-!- mode/#shogun [+o iglesiasg] by ChanServ20:02
@iglesiasgHello!20:02
@HeikoSiglesiasg: hey!20:02
@lambdayhello!20:02
@HeikoSiglesiasg: long time no see20:02
@HeikoSlambday: hey man!20:03
yorkerlinhello20:03
@HeikoSyorkerlin: hi!20:03
@iglesiasgHeikoS: definitely :)20:03
@thoralfFull house :)20:03
@iglesiasghow are you guys doing?20:03
@lambdayHeikoS: hey! :)20:03
@lambdayiglesiasg: over-eating :(20:03
@lambdayyorkerlin: congrats man! :)20:03
yorkerlinHi, guys! :)20:04
@HeikoSbesser82: you are here too?20:04
@iglesiasglambday: good food? :)20:04
@besser82HeikoS, sure20:04
@HeikoSbesser82: cool, hi20:04
@lambdayiglesiasg: self-made Indian dishes ;)20:04
@HeikoSlambday: mjam20:04
@besser82hi, HeikoS20:04
@HeikoSBTW guys, I put up a small list of things we could talk about here: https://github.com/shogun-toolbox/shogun/wiki/Stammtisch-2015-07-1520:05
* besser82 has some german wheat-beer :P20:05
yorkerlincool20:05
@HeikoSbesser82: haha nice. I have German homemade bread20:05
@iglesiasglambday: that sounds good. There is an Indian guy in my dorm and I am trying some of his Indian food from time to time. I like it!20:05
@HeikoSwiking: around?20:05
@besser82thoralf, hey!  =)20:06
@lambdayiglesiasg: haha :D great man!20:06
@lambdaylisitsyn: there?20:06
@HeikoSso guys, first thing I wanted to say is a welcome to yorkerlin (in case your spam filter blocks shogun-list ;) )20:07
@besser82yorkerlin, Welcome on board!  :D20:07
@HeikoSyorkerlin will probably be cursing us for having added him after he realises all the stuff he has to do now ;)20:08
@besser82d'oh, yes!  :P20:08
@iglesiasgwelcome, Wu!20:08
yorkerlinthanks for all of you guys:)20:08
@HeikoSApart from that, it's probably a good idea to update everyone on whats going on (or WAS going on until spring) on all the construction sites of Shogun20:09
@HeikoSsee the list in the wiki20:09
@HeikoSdont know wheter kevin will be around20:09
@HeikoSBut I guess one good thing would be if everyone commented on his new website draft20:09
@HeikoShttps://github.com/shogun-toolbox/shogun-web220:10
@HeikoSin particular here: http://shogun-web.herokuapp.com/20:10
@HeikoSthere are already lots of discussions in the issues of the repo20:11
yorkerlinlook cool :)20:12
@iglesiasgthe site looks pretty awesome20:12
@lambdaywow this is responsive!20:12
@thoralf+120:12
@HeikoSyorkerlin: still a draft so needs lots of feedback20:12
@lambdaybootstrap?20:13
@HeikoSlambday: I think partly20:13
@lambdaythe red fonts on the bottom probably can be a bit more readable with some other color?20:13
@HeikoSkevin made a lot of effort for this, so lets be responsive and give feedback so that this grows into something mature20:13
@HeikoSlambday: issue! ;)20:13
@iglesiasglambday: https://github.com/shogun-toolbox/shogun-web2/issues/2020:14
@iglesiasg;)20:14
@HeikoSiglesiasg: haha20:14
@lambdayiglesiasg: haha20:14
@HeikoSiglesiasg: brewed mustard brown!20:14
yorkerlinic haha20:14
@HeikoSlambday: could you give some updates on the linalg? I have no idea what was the last thing that was worked on20:15
@HeikoSyorkerlin: you probably have some requirements to that thing, could be good to get this going20:16
@lambdayHeikoS: elementwise unary operation..20:16
@HeikoSlambday: ah yes, people are using that now I think20:16
@lambdayHeikoS: we planned for binary ones but then I got lazy20:16
@HeikoSlambday: I thought it might be cool to put a roadmap for linalg somewhere20:16
@HeikoSmaybe in the wiki page your wrote for it20:16
@lambdayHeikoS: yeah that thing is helpful.. we had some impressive benchmark with GPU for element-wise ops20:17
@HeikoSlambday: I remember that20:17
@HeikoSlambday: really liked that and that swhy I think it would be good to keep that going20:17
@lambdayHeikoS: yeah that would be good20:17
@HeikoShttps://github.com/shogun-toolbox/shogun/wiki/README_linalg20:17
@HeikoSyorkerlin: needs linear solve like operations all the time20:17
@lambdayHeikoS: okay I'll get back to linalg20:17
@HeikoSlambday: maybe the best way is to add things that are needed most, yorkerlin can probably tell you20:18
yorkerlinI will post some features/operations required for GP inference20:18
@HeikoSI think there were some issues related to that somewhere20:19
@lambdayyorkerlin: sounds great, Now you can assign the task to me (or anybody)20:19
@lambdayI remember having a bunch of issues I assigned to myself but didn't quite finish them20:20
@HeikoSlambday: we could also rework the kernel framework using that20:20
@HeikoSin particular kernels that are based on pairwise distances20:20
@HeikoSthe matrix computations can be done on GPU: both pairwise distances and the unary operations20:21
@HeikoSesben had some ideas20:21
yorkerlinlet me look at my codes first. @HeikoS, we need to decide which inference methods are required to use GPU speedup20:21
@HeikoSyorkerlin: I would go for matrix factorisations and multiplications20:21
@lambdayHeikoS: that sounds really great! would be cool if we can GPUize this20:22
@HeikoSyorkerlin: but you know what operations are needed most20:22
@HeikoSyorkerlin: computing kernel matrices on GPU is also interesting for GP20:22
yorkerlinyes20:22
lisitsynoh20:22
@HeikoSso cann pull that out into a base class (I think it already is partly) and then overload the kernel matrix methods20:22
lisitsynhey guys20:22
@HeikoSlisitsyn: hi!20:22
@iglesiasglisitsyn: hey!20:23
@lambdayI don't recall what happened to Esben's PR that spawn this element-wise idea20:23
@lambdaylisitsyn: hello :D20:23
@HeikoSlisitsyn: hey man how are things20:23
yorkerlinGaussianARDKernel is used linalg now.20:23
@HeikoSlambday: let me dig it out20:23
lisitsynHeikoS: just got home and forgot about our party :)20:23
@HeikoSlambday:  https://github.com/shogun-toolbox/shogun/pull/281820:24
@HeikoSlisitsyn: just starting ;)20:24
lisitsynok cool20:24
lisitsynHeikoS: have you seen I pushed that range thing I promised?20:24
@lambdayHeikoS: okay thanks..20:24
lisitsynyou can now use python-like loops20:25
yorkerlincool!20:25
@lambdaylisitsyn: cool stuff man20:25
lisitsynlambday: use it! :)20:25
@lambdaylisitsyn: just watch for my next PR ;)20:26
lisitsynlambday: what is it?20:26
@lambdaylisitsyn: I mean you'll see that I'm using range :D20:26
lisitsynahh20:27
lisitsynok guys I am now following your discussion before20:27
lisitsynnot*20:27
lisitsynso let me talk on myself haha20:27
@thoralflisitsyn: :D20:27
lisitsynIm going to push one more thing soon20:27
lisitsynthat's generic get/set for sgobject using tags20:27
@lambdaylisitsyn: what's the idea?20:28
lisitsynlet me talk C++20:28
@lambdayyes sir20:28
lisitsynT get(Tag<T> tag);20:28
lisitsynvoid set(Tag<T> tag, T value);20:28
lisitsynthat's it20:28
@thoralflisitsyn: How would we use it?20:28
@HeikoSlisitsyn: what about some grepped auto-refactoring of auto? :)20:28
lisitsynsay you have object20:28
lisitsynobj20:28
lisitsynoh say its kernel20:29
lisitsyngaussian kernel20:29
@lambdaylisitsyn: this would work in the modular interface?20:29
lisitsyngk.set(gk.width, 3.0)20:29
lisitsynyes I think any language should support it20:29
@thoralfAh.20:29
lisitsynwith one restriction20:29
lisitsynwe have to restrict possible types of parameters20:30
lisitsynbut I think it is double, int, SGObject* and some base types20:30
@HeikoSlisitsyn: like all the types for swig right?20:30
lisitsynno20:30
lisitsynI think we should use a few20:30
lisitsynwe need really base classes20:31
@HeikoSlisitsyn: for types?20:31
lisitsynthe same types would be visible from plugins20:31
lisitsynits the next step20:31
@HeikoSlisitsyn: maybe examples would help, I am lost ;)20:31
lisitsynhmm ok20:31
lisitsynclass GaussianKernel { static Tag<double> width; }20:32
lisitsynthat's how we declare parameter20:32
lisitsynTag<?> could be basically anything but if we want speed and plugins20:32
lisitsynwe should restrict what T is20:32
lisitsynsay Tag<LinearMachine> is ok20:33
lisitsynbut Tag<SVM> is not20:33
lisitsynotherwise SVM is not a plugin20:33
lisitsynbut a part of the core20:33
lisitsynanyone following? :)20:33
@HeikoSlisitsyn: would that be part of aer?20:33
lisitsynHeikoS: I'll kill aer and will push ideas from it into shogun gradually20:33
lisitsynthat's how I think it would work20:34
@lambdaylisitsyn: I remember you saying that we must need all the base classes in the core - so kinda following :/20:34
@HeikoSlisitsyn: ok also good20:34
@HeikoSlisitsyn: just want to say, I met a couple of people who needed a library that does Shogun's swig magic for their project, so could be good to pull that out20:34
@HeikoSand the getter/Setter stuff is part of that20:34
lisitsynah20:34
lisitsynyou mean sublibrary is better?20:35
@HeikoSlisitsyn: yeah20:35
lisitsynhmm why not20:35
@HeikoSlike something independent of Shogun that allows to expose any class framework to all modular languages20:35
lisitsynyeah I like this idea20:35
@lambday+120:35
@HeikoSsonney2k also wanted to do this ages ago20:35
@HeikoSwe talked about it GSoC 2013 summit ;)20:35
@HeikoSwhile hiking through the desert20:35
lisitsynI like it naming wise20:36
lisitsynshogun rules a few libs20:36
lisitsynand decoupling is good20:36
@HeikoSyeah exactly20:37
lisitsynso my plan is20:37
lisitsynto add tags20:37
lisitsynto add generic class that supports tags20:37
lisitsynand inherit sgobject from it20:37
lisitsynso we get kool thing20:38
lisitsynthen maybe we should think really really hard20:38
@lambdaycan we get rid of manual refcounting in the process of that?20:38
lisitsynhmm yeah20:38
lisitsyn^ .. really really hard to select base classes20:39
lisitsynthat's *stable* API of shogun20:39
lisitsynit could lead to some frustration actually20:39
lisitsynonce pluginized you can't produce many methods20:39
lisitsynit is rather data driven20:39
lisitsynyou pull some kind of task20:40
lisitsynand parameters20:40
@iglesiasgsorry guys, got to leave. Will catch you later!20:40
-!- iglesiasg [~iglesias@524B8E0B.cm-4-4c.dynamic.ziggo.nl] has quit [Quit: leaving]20:40
lisitsynok we will miss you :)20:40
lisitsynanyone? :)20:40
@lambdayyeah20:40
-!- curiousguy13 [~curiousgu@59.177.199.41] has joined #shogun20:41
@lambdayI'd really like to work on that - so maybe we should discuss this a bit more20:41
@HeikoSigbye20:41
@lambdaylisitsyn: I read somewhere some issues regarding binary compatibility20:41
lisitsynah about binary20:41
lisitsynif we talk about C++ there is no binary thing20:42
@HeikoSlisitsyn: I dont get that20:42
lisitsynC++ is doomed abi-wise20:42
@lambdayso someone suggested to use C for some parts - since in terms of binary C is better than C++20:42
lisitsynyes20:42
lisitsynC ABI is rock stable20:42
@lambdayyeah20:42
lisitsynHeikoS: what needs explanation?20:42
@lambdayso if we aim for platform independence then that is also a matter of concern20:42
lisitsynlambday: yeah we should develop C++ API20:43
lisitsynthen C layer20:43
@lambdaylisitsyn: exactly20:43
@HeikoSlisitsyn: Im not the c/C++ expert20:43
lisitsynthat's the best way I believe20:43
lisitsynHeikoS: yeah I just don't get what you missed20:43
@HeikoSlisitsyn: what does that mean in practice20:43
@HeikoSok20:43
@HeikoSso why the seperation?20:43
@HeikoSwhat would each layer do?20:43
@lambdaylisitsyn: I'll read that article in details - it had some serious good stuffs20:43
@HeikoSlisitsyn: would that not be complicated?20:43
lisitsynhmm20:43
lisitsynquite a few questions ;)20:43
lisitsynwhat separation?20:43
@HeikoSc/C++20:44
lisitsynah20:44
lisitsynok C++ supports function overloading20:44
@HeikoSlisitsyn: does that also get rid of the swig madness in terms of memory etc?20:44
lisitsynHeikoS: hmm not sure20:44
lisitsynmaybe yes20:44
lisitsynif we get with plugins yes20:45
lisitsynI mean if we use plugin structure20:45
lisitsynit would be like a few seconds to compile I think20:45
lisitsynit won't be that big20:45
@HeikoSthats good20:45
lisitsynbut API would be quite strict20:45
@HeikoSwhat does that mean?20:45
lisitsynyou won't be able to do same things20:45
@HeikoSconcrete?20:45
lisitsynsay you want to develop a new class20:45
lisitsynthat supports FooBar()20:45
lisitsynI don't see good way to support FooBar() with plugins unless there is a base class in our stable API20:46
lisitsynthat supports FooBar()20:46
@HeikoS???20:46
@HeikoShaha20:46
@HeikoSI am so lost20:46
lisitsynok20:46
lisitsynsay you have SVM20:46
@HeikoSwhat is FooBar() ? an instance? a method?20:46
lisitsynmethod20:46
@HeikoSmethod of a new class?20:46
@lambdayyou can only do things that can be overridden?20:46
lisitsynyes20:46
lisitsynyes20:46
@lambdayokay20:47
lisitsynyou can provide only methods from the API20:47
lisitsynor it would be some trick20:47
lisitsynto call it20:47
lisitsynok let me talk code20:47
lisitsynsvm = shogun.machine("SVM");20:47
lisitsynbam20:47
lisitsynwe get svm20:47
lisitsynwe can train svm20:47
lisitsynsvm.train();20:47
lisitsynbut we can't get support vectors20:48
@lambdayah20:48
lisitsynbecause support vectors are not in our *generic* API20:48
lisitsynwhat we would have to do is20:48
@HeikoSlisitsyn: but why is that good then?20:48
lisitsynsv = svm.get("support_vectors");20:48
lisitsynlike that20:48
@HeikoSif one cannot add custom methods, thats quite a restriction20:49
lisitsynHeikoS: because it is the only way for plugins20:49
@lambdayhave some generic thing in the base which would allow to do subclass specific things in overridden way20:49
@HeikoSwhat about void precompute_alpha()20:49
lisitsynHeikoS: it would be svm.call("precompute_alpha"); or so20:49
lisitsynor20:49
lisitsynsvm.do(svm.operations.precompute_alpha);20:49
@HeikoSnot sure whether I like that to be honest20:49
lisitsynthis is also possible20:49
@HeikoSconvoluted20:49
lisitsynHeikoS: yes but no swig problems and very dynamic20:50
@HeikoSlisitsyn: sure agreed20:50
@lambday2nd one sounds better20:50
lisitsynyes20:50
@lambdayI hate string tags20:50
lisitsynyes strings suck20:50
@HeikoSShogun is a ML toolbox though, we want users and developers to be able to put things in the code that allow for custom computations20:50
@HeikoSso at the bottom of the class tree I expect there to be tons of custom operatilons20:51
@HeikoSoperations20:51
lisitsynyeah20:51
lisitsynbut they should not be exposed20:51
lisitsynthat enforces a good practice actually20:51
@HeikoSexposed?20:51
lisitsynbut too strict20:51
@lambdaylisitsyn: why classname.do(...) cannot be exposed?20:51
@HeikoSto swig? or to public20:51
lisitsynyeah I mean you do custom operation just to train machine20:51
lisitsynor something like that20:52
@HeikoSlisitsyn: think about all the stuff one can do after trainnig20:52
@HeikoSlisitsyn: SVs, get_w, labels_to_prbabilities20:52
lisitsynyou mean like various inference things?20:52
@HeikoSyeah20:52
@HeikoSget_inducing_points20:52
lisitsynwell20:52
@HeikoSget_posterior_covariance20:52
@HeikoSetc20:52
lisitsynwhat I propose ruins syntax20:52
lisitsynthat's true20:52
lisitsynbut you get other things20:53
lisitsynyou can compile your plugin standalone20:53
lisitsynit is a second and you run it20:53
lisitsynwith such development cycle you can be quite fast20:53
@HeikoStrue,20:53
@HeikoSbut in practice?20:53
@HeikoSI use ccache and this is also very fast20:53
@HeikoSccache-swig also seems to work nowadays20:53
@HeikoSI like the getter/stter thing though20:54
lisitsynwell I don't know20:54
@HeikoSand of course that things are modular20:54
@HeikoSany other projects having experience on such a design?20:54
@HeikoSwiking: mentioned something a while ago20:54
-!- vortex_ape [~vortex_ap@120.59.76.228] has joined #shogun20:54
lisitsynhmm I didn't do any research on that20:54
@HeikoSlisitsyn: I think best thing would be to get an estimate on effort and improvement20:55
@HeikoSits quite a major change20:55
lisitsynthat's pretty hard20:55
@lambdaylisitsyn: could you please explain a bit about why the do() method that you propose cannot be exposed to modular interface?20:55
lisitsynlambday: they can20:55
@lambdaylisitsyn: so are we actually losing anything with that? I mean it's mostly syntactics20:56
lisitsynyes mostly syntax20:56
-!- vortex_ape [~vortex_ap@120.59.76.228] has quit [Remote host closed the connection]20:56
@HeikoSlisitsyn: maybe prototype is a good idea, but dont know20:56
lisitsynit could be pretty ugly syntax  to be honest20:56
@HeikoSlisitsyn: hey, since I have to leave soon20:57
lisitsynHeikoS: its controversial I don't know if it is good20:57
@lambdayI don't think then that it would stand in the way of our iterating addition model of dev20:57
@HeikoSlisitsyn: also wanted to talk a bit about manual project20:57
lisitsynah20:57
lisitsynyeah20:57
yorkerlinOne cmake question: Can we choose compile a modular (say, GP modular) without compiling all irrelevant ones (eg, SVM)?20:57
lisitsynyorkerlin: pretty hard20:58
@HeikoSyorkerlin: good point20:58
@HeikoSwe have a demo for that20:58
@HeikoSthoralf: did that20:58
@HeikoSI think this might be good alternative in fact20:58
lisitsynguys I have to leave for 15 minutes20:58
lisitsynHeikoS: will you be gone then?20:59
@HeikoSlisitsyn: yeah20:59
lisitsynargh20:59
@HeikoSwell20:59
lisitsynok so20:59
@HeikoSIm online most days20:59
lisitsynah20:59
lisitsynok20:59
@HeikoSjust good to get the talking going20:59
lisitsynyeah20:59
@HeikoSyorkerlin, thoralf did a bash based version of that20:59
@HeikoSok20:59
lisitsynHeikoS: can you push me a bit on the manual thing then20:59
@HeikoSI leave you guys to it20:59
@HeikoSlisitsyn: yeah will do ;)21:00
@HeikoSthats almost done so good to fnish21:00
@HeikoSand then let people populate21:00
yorkerlin\ping @HeikoS any link?21:00
lisitsynlambday: ok when I am back we can discuss api :)21:00
@HeikoSyorkerlin: searching21:01
@lambdaylisitsyn: alright.. see you21:01
yorkerlinanother question  /ping @lambday, if we use SGMatrix, can we choose use GPUMatrix and CPUMatrix on-the-fly or on compilation time21:02
-!- HeikoS [~heiko@05419e79.skybroadband.com] has quit [Quit: Leaving.]21:02
@lambdayyorkerlin: I'm afraid not - I remember discussing about this but we dumped that idea for some valid reasons - SG is always CPU21:03
@lambdayyorkerlin: or maybe I didn't understand your question?21:04
-!- vortex_ape [~vortex_ap@120.59.76.228] has joined #shogun21:04
yorkerlinso we have to GPU matix in codes.21:04
@lambdayyorkerlin: as of now, yes.21:05
@lambdayyorkerlin: since the use-case is pretty application specific, I think it is good that way21:05
yorkerlinif we do not have supported GPU, the GUP matrix will use eigen3?21:06
yorkerlinif we have GPU matrix and we use linalg,21:06
@lambdayyorkerlin: nope. GPU is basically ViennaCL matrixbase syntactic sugar - so in absence of GPU, it will use CPU just like ViennaCL does21:06
yorkerlinok. seems good.21:07
@lambdayif you don't have ViennaCL, you miss the entire GPUMatrix class21:07
yorkerlinabout kernel part. For GPU speedup, currently kernel returns SGMatrix.21:08
yorkerlinif we want to use GPU matrix, currently we have to copy SGMatrix to GPUMatrix21:09
yorkerlinright?21:09
@lambdayyorkerlin: yeah that's awful.21:09
@lambdayyorkerlin: but you don't wanna change that in the base21:09
@lambdaysince not always we'll use GPU for kernel computation (so far I understood from the discussion)21:10
yorkerlinyes. GPU speed up for kernel computation is a next step21:10
@lambdayor maybe I miss something here21:10
@lambdayyorkerlin: can we do that for *ALL* the kernels?21:11
-!- vortex_ape [~vortex_ap@120.59.76.228] has quit [Ping timeout: 246 seconds]21:11
yorkerlinI am not familiar with many kernels.21:12
@lambdayneither am I.. Heiko is the guy to ask then21:12
yorkerlinthe issue is if viennaCL is missing, what can we do21:13
@lambdayyorkerlin: well - since we decided to go with ViennaCL for our GPU stuffs, we'll miss all of that21:13
@lambdayother solution is to write all those linalg ops using OpenCL or CUDA ourselves which is bad21:14
@lambdayyorkerlin: why are you concerned about viennacl being missing?21:15
yorkerlinsince kernel computation is essnetial for shogun, if we use viennaCL for kernel computation, what can we do?21:16
yorkerlinand viennaCl is missing21:16
@lambdayyorkerlin: hmm ok.. gotta have some fallback mechanism21:17
@lambdayyorkerlin: I don't think that's gonna be hard - just some additional code21:18
yorkerlinok. seems good21:18
yorkerlin I will soon send PRs about the stochastic inference methods for regression.  For now, these methods use eigen3.  We can use linalg to replace eigen3 used in these methods. Because these methods can train millions of data points, I think /ping @lambday we can start from here.21:18
@lambdayyorkerlin: what kind of linalg operations do you need there?21:19
@lambdayyorkerlin: yeah that sounds good21:20
yorkerlincholesky21:20
@lambdayokay - hmm we don't have that yet21:20
@lambdayI think getting linalg in a matured state is gonna take a while21:20
@lambday:(21:21
yorkerlinok.21:21
yorkerlinonce linalg is stable, we can start work on it21:21
@lambdayyorkerlin: yeah! if you keep pushing me for new stuffs, then I'll get motivated a bit more :D21:22
yorkerlincool! :)  I leave now. I will post a issue about this.21:22
@lambdayyorkerlin: what you're doing BTW? Masters?21:22
@lambdayyorkerlin: okay man ttyl :)21:23
-!- yorkerlin [b8af2f1e@gateway/web/freenode/ip.184.175.47.30] has quit [Quit: Page closed]21:23
lisitsynlambday: ok I am backz21:27
@lambdaylisitsyn: hey..21:27
@lambdayso about aer21:28
lisitsynyes21:28
lisitsynlambday: anything you want to clarify?21:30
@lambdaylisitsyn: Heiko had some valid point about usability - I'm not sure how to manage it properly21:33
@lambdayfrom what I understood, with the do() stuffs we can pretty much achieve anything custom21:34
lisitsynyeah probably yes21:35
@lambdaylisitsyn: how does this go with d-ptrs ?21:35
@lambdaydo() thing is in the outer class then custom methods are in the inner21:35
lisitsynyes21:36
lisitsynall would be in .cpp files I think21:36
@lambdayyeah21:36
@lambdayand there will be enums?21:36
lisitsynfor operations?21:36
lisitsynhmm I just realized21:37
lisitsynwe have to use strings21:37
@lambdaysince functors are not accessible from modular :/21:37
lisitsynsay svm provides support_vectors21:37
@lambdayok21:37
lisitsynwe'd have to svm.get("support_vectors")21:37
lisitsynor add a tag for that21:38
@lambdaytag thing is faster21:38
lisitsynyeah and it is typed21:38
@lambdaybut ugly if mapped to modular21:39
@lambdayfor all T you have to give them new names21:39
@lambdayright?21:39
lisitsynno21:39
lisitsynoverloading would work21:39
@lambdayhow one creates Tag<T> from python modular then?21:39
lisitsynyes21:39
lisitsynthat's the point21:40
lisitsynhere you'd need new names21:40
lisitsyn*but*21:40
lisitsynyou can provide them out of box21:40
lisitsynlike gaussian kernel width is a member of gaussian kernel21:40
lisitsynwidth tag*21:40
@lambdayoh i see21:40
lisitsynbut no plugins then haha21:41
@thoralfSomeone mentioned my bash-hack to compile a incomplete version of SHOGUN.21:41
@thoralfhttps://github.com/tklein23/shogun-partial-build21:41
lisitsynoh21:41
lisitsynwu is gone21:41
lisitsynbut thanks21:41
@lambdaylisitsyn: because gaussian goes to core then? :/21:42
lisitsynyeaas21:42
lisitsynlambday: I broke my head with that already21:42
lisitsynwhatever you do you meet some other restriction :D21:42
@lambdayargh21:42
@lambdayI am starting to wonder if plugin is really for the development model we have here at Shogun :/21:43
lisitsynI don't know21:43
@lambdaylisitsyn: okay we can forget tag then - strings are fine21:43
lisitsynno we should still use tags I think21:44
lisitsynif you use strings you'd have to case anyway21:44
lisitsynso its cheaper to create tag from string once21:44
lisitsyns/case/cast21:44
@lambdayhmm21:45
@lambdaylisitsyn: going to sleep man.. I'll see if I can think of something useful.. in any case, we'll have to do small poc for an idea..21:54
@lambdaylisitsyn: see you soon21:56
-!- lambday [6a3386ac@gateway/web/freenode/ip.106.51.134.172] has quit [Quit: Leaving.]21:56
lisitsynlambday: ok see you22:25
@thoralfBye.22:37
-!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has left #shogun ["Konversation terminated!"]22:37
-!- lupinix [~quassel@fedora/lupinix] has quit [Ping timeout: 246 seconds]23:33
-!- lupinix [~quassel@fedora/lupinix] has joined #shogun23:36
--- Log closed Tue Jul 14 00:00:52 2015