| --- Log opened Mon Jul 13 00:00:50 2015 | ||
| -!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has joined #shogun | 00:02 | |
| -!- mode/#shogun [+o thoralf] by ChanServ | 00:02 | |
| -!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has quit [Quit: Konversation terminated!] | 00:19 | |
| -!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has joined #shogun | 00:24 | |
| -!- mode/#shogun [+o thoralf] by ChanServ | 00: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 #shogun | 01:21 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 01:21 | |
| -!- HeikoS [~heiko@05419e79.skybroadband.com] has quit [Client Quit] | 01:21 | |
| shogun-buildbot | build #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 #shogun | 06: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 #shogun | 07: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 #shogun | 10: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 #shogun | 10:20 | |
| -!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has joined #shogun | 10:22 | |
| -!- vortex_ape [~vortex_ap@120.59.75.202] has quit [Ping timeout: 256 seconds] | 10:28 | |
| -!- HeikoS [~heiko@05419e79.skybroadband.com] has joined #shogun | 10:55 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 10: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 #shogun | 11:41 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 11: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 #shogun | 12:23 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 12:23 | |
| -!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3] | 13:46 | |
| -!- Netsplit *.net <-> *.split quits: @besser82 | 17:37 | |
| -!- Netsplit *.net <-> *.split quits: shogun-buildbot | 17:37 | |
| -!- Netsplit over, joins: shogun-buildbot | 17:37 | |
| -!- Netsplit over, joins: besser82 | 17:38 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 17:38 | |
| -!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has joined #shogun | 18:17 | |
| @wiking | ping | 19: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 | |
| @wiking | stamm stamm | 19:33 |
| @wiking | nobody stma? | 19:33 |
| @wiking | :D | 19:33 |
| -!- lambday [6a3386ac@gateway/web/freenode/ip.106.51.134.172] has joined #shogun | 19:41 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 19:41 | |
| -!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has joined #shogun | 19:44 | |
| -!- PirosB3 [~pirosb3@host246-221-dynamic.19-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3] | 19:54 | |
| @besser82 | wiking, I'm hier for Stamm ^_^ | 19:56 |
| * besser82 hands some virtual steins out to other folks | 19:56 | |
| -!- yorkerlin [b8af2f1e@gateway/web/freenode/ip.184.175.47.30] has joined #shogun | 19:58 | |
| -!- HeikoS [~heiko@05419e79.skybroadband.com] has joined #shogun | 20:00 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 20:00 | |
| -!- thoralf [~thoralf@ip5b418b8d.dynamic.kabel-deutschland.de] has joined #shogun | 20:00 | |
| -!- mode/#shogun [+o thoralf] by ChanServ | 20:01 | |
| @thoralf | Heyho. | 20:01 |
| @HeikoS | thoralf: yo | 20:01 |
| @HeikoS | thoralf: hey man good to see you! | 20:01 |
| -!- iglesiasg [~iglesias@524B8E0B.cm-4-4c.dynamic.ziggo.nl] has joined #shogun | 20:02 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 20:02 | |
| @iglesiasg | Hello! | 20:02 |
| @HeikoS | iglesiasg: hey! | 20:02 |
| @lambday | hello! | 20:02 |
| @HeikoS | iglesiasg: long time no see | 20:02 |
| @HeikoS | lambday: hey man! | 20:03 |
| yorkerlin | hello | 20:03 |
| @HeikoS | yorkerlin: hi! | 20:03 |
| @iglesiasg | HeikoS: definitely :) | 20:03 |
| @thoralf | Full house :) | 20:03 |
| @iglesiasg | how are you guys doing? | 20:03 |
| @lambday | HeikoS: hey! :) | 20:03 |
| @lambday | iglesiasg: over-eating :( | 20:03 |
| @lambday | yorkerlin: congrats man! :) | 20:03 |
| yorkerlin | Hi, guys! :) | 20:04 |
| @HeikoS | besser82: you are here too? | 20:04 |
| @iglesiasg | lambday: good food? :) | 20:04 |
| @besser82 | HeikoS, sure | 20:04 |
| @HeikoS | besser82: cool, hi | 20:04 |
| @lambday | iglesiasg: self-made Indian dishes ;) | 20:04 |
| @HeikoS | lambday: mjam | 20:04 |
| @besser82 | hi, HeikoS | 20:04 |
| @HeikoS | BTW guys, I put up a small list of things we could talk about here: https://github.com/shogun-toolbox/shogun/wiki/Stammtisch-2015-07-15 | 20:05 |
| * besser82 has some german wheat-beer :P | 20:05 | |
| yorkerlin | cool | 20:05 |
| @HeikoS | besser82: haha nice. I have German homemade bread | 20:05 |
| @iglesiasg | lambday: 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 |
| @HeikoS | wiking: around? | 20:05 |
| @besser82 | thoralf, hey! =) | 20:06 |
| @lambday | iglesiasg: haha :D great man! | 20:06 |
| @lambday | lisitsyn: there? | 20:06 |
| @HeikoS | so guys, first thing I wanted to say is a welcome to yorkerlin (in case your spam filter blocks shogun-list ;) ) | 20:07 |
| @besser82 | yorkerlin, Welcome on board! :D | 20:07 |
| @HeikoS | yorkerlin will probably be cursing us for having added him after he realises all the stuff he has to do now ;) | 20:08 |
| @besser82 | d'oh, yes! :P | 20:08 |
| @iglesiasg | welcome, Wu! | 20:08 |
| yorkerlin | thanks for all of you guys:) | 20:08 |
| @HeikoS | Apart 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 Shogun | 20:09 |
| @HeikoS | see the list in the wiki | 20:09 |
| @HeikoS | dont know wheter kevin will be around | 20:09 |
| @HeikoS | But I guess one good thing would be if everyone commented on his new website draft | 20:09 |
| @HeikoS | https://github.com/shogun-toolbox/shogun-web2 | 20:10 |
| @HeikoS | in particular here: http://shogun-web.herokuapp.com/ | 20:10 |
| @HeikoS | there are already lots of discussions in the issues of the repo | 20:11 |
| yorkerlin | look cool :) | 20:12 |
| @iglesiasg | the site looks pretty awesome | 20:12 |
| @lambday | wow this is responsive! | 20:12 |
| @thoralf | +1 | 20:12 |
| @HeikoS | yorkerlin: still a draft so needs lots of feedback | 20:12 |
| @lambday | bootstrap? | 20:13 |
| @HeikoS | lambday: I think partly | 20:13 |
| @lambday | the red fonts on the bottom probably can be a bit more readable with some other color? | 20:13 |
| @HeikoS | kevin made a lot of effort for this, so lets be responsive and give feedback so that this grows into something mature | 20:13 |
| @HeikoS | lambday: issue! ;) | 20:13 |
| @iglesiasg | lambday: https://github.com/shogun-toolbox/shogun-web2/issues/20 | 20:14 |
| @iglesiasg | ;) | 20:14 |
| @HeikoS | iglesiasg: haha | 20:14 |
| @lambday | iglesiasg: haha | 20:14 |
| @HeikoS | iglesiasg: brewed mustard brown! | 20:14 |
| yorkerlin | ic haha | 20:14 |
| @HeikoS | lambday: could you give some updates on the linalg? I have no idea what was the last thing that was worked on | 20:15 |
| @HeikoS | yorkerlin: you probably have some requirements to that thing, could be good to get this going | 20:16 |
| @lambday | HeikoS: elementwise unary operation.. | 20:16 |
| @HeikoS | lambday: ah yes, people are using that now I think | 20:16 |
| @lambday | HeikoS: we planned for binary ones but then I got lazy | 20:16 |
| @HeikoS | lambday: I thought it might be cool to put a roadmap for linalg somewhere | 20:16 |
| @HeikoS | maybe in the wiki page your wrote for it | 20:16 |
| @lambday | HeikoS: yeah that thing is helpful.. we had some impressive benchmark with GPU for element-wise ops | 20:17 |
| @HeikoS | lambday: I remember that | 20:17 |
| @HeikoS | lambday: really liked that and that swhy I think it would be good to keep that going | 20:17 |
| @lambday | HeikoS: yeah that would be good | 20:17 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/wiki/README_linalg | 20:17 |
| @HeikoS | yorkerlin: needs linear solve like operations all the time | 20:17 |
| @lambday | HeikoS: okay I'll get back to linalg | 20:17 |
| @HeikoS | lambday: maybe the best way is to add things that are needed most, yorkerlin can probably tell you | 20:18 |
| yorkerlin | I will post some features/operations required for GP inference | 20:18 |
| @HeikoS | I think there were some issues related to that somewhere | 20:19 |
| @lambday | yorkerlin: sounds great, Now you can assign the task to me (or anybody) | 20:19 |
| @lambday | I remember having a bunch of issues I assigned to myself but didn't quite finish them | 20:20 |
| @HeikoS | lambday: we could also rework the kernel framework using that | 20:20 |
| @HeikoS | in particular kernels that are based on pairwise distances | 20:20 |
| @HeikoS | the matrix computations can be done on GPU: both pairwise distances and the unary operations | 20:21 |
| @HeikoS | esben had some ideas | 20:21 |
| yorkerlin | let me look at my codes first. @HeikoS, we need to decide which inference methods are required to use GPU speedup | 20:21 |
| @HeikoS | yorkerlin: I would go for matrix factorisations and multiplications | 20:21 |
| @lambday | HeikoS: that sounds really great! would be cool if we can GPUize this | 20:22 |
| @HeikoS | yorkerlin: but you know what operations are needed most | 20:22 |
| @HeikoS | yorkerlin: computing kernel matrices on GPU is also interesting for GP | 20:22 |
| yorkerlin | yes | 20:22 |
| lisitsyn | oh | 20:22 |
| @HeikoS | so cann pull that out into a base class (I think it already is partly) and then overload the kernel matrix methods | 20:22 |
| lisitsyn | hey guys | 20:22 |
| @HeikoS | lisitsyn: hi! | 20:22 |
| @iglesiasg | lisitsyn: hey! | 20:23 |
| @lambday | I don't recall what happened to Esben's PR that spawn this element-wise idea | 20:23 |
| @lambday | lisitsyn: hello :D | 20:23 |
| @HeikoS | lisitsyn: hey man how are things | 20:23 |
| yorkerlin | GaussianARDKernel is used linalg now. | 20:23 |
| @HeikoS | lambday: let me dig it out | 20:23 |
| lisitsyn | HeikoS: just got home and forgot about our party :) | 20:23 |
| @HeikoS | lambday: https://github.com/shogun-toolbox/shogun/pull/2818 | 20:24 |
| @HeikoS | lisitsyn: just starting ;) | 20:24 |
| lisitsyn | ok cool | 20:24 |
| lisitsyn | HeikoS: have you seen I pushed that range thing I promised? | 20:24 |
| @lambday | HeikoS: okay thanks.. | 20:24 |
| lisitsyn | you can now use python-like loops | 20:25 |
| yorkerlin | cool! | 20:25 |
| @lambday | lisitsyn: cool stuff man | 20:25 |
| lisitsyn | lambday: use it! :) | 20:25 |
| @lambday | lisitsyn: just watch for my next PR ;) | 20:26 |
| lisitsyn | lambday: what is it? | 20:26 |
| @lambday | lisitsyn: I mean you'll see that I'm using range :D | 20:26 |
| lisitsyn | ahh | 20:27 |
| lisitsyn | ok guys I am now following your discussion before | 20:27 |
| lisitsyn | not* | 20:27 |
| lisitsyn | so let me talk on myself haha | 20:27 |
| @thoralf | lisitsyn: :D | 20:27 |
| lisitsyn | Im going to push one more thing soon | 20:27 |
| lisitsyn | that's generic get/set for sgobject using tags | 20:27 |
| @lambday | lisitsyn: what's the idea? | 20:28 |
| lisitsyn | let me talk C++ | 20:28 |
| @lambday | yes sir | 20:28 |
| lisitsyn | T get(Tag<T> tag); | 20:28 |
| lisitsyn | void set(Tag<T> tag, T value); | 20:28 |
| lisitsyn | that's it | 20:28 |
| @thoralf | lisitsyn: How would we use it? | 20:28 |
| @HeikoS | lisitsyn: what about some grepped auto-refactoring of auto? :) | 20:28 |
| lisitsyn | say you have object | 20:28 |
| lisitsyn | obj | 20:28 |
| lisitsyn | oh say its kernel | 20:29 |
| lisitsyn | gaussian kernel | 20:29 |
| @lambday | lisitsyn: this would work in the modular interface? | 20:29 |
| lisitsyn | gk.set(gk.width, 3.0) | 20:29 |
| lisitsyn | yes I think any language should support it | 20:29 |
| @thoralf | Ah. | 20:29 |
| lisitsyn | with one restriction | 20:29 |
| lisitsyn | we have to restrict possible types of parameters | 20:30 |
| lisitsyn | but I think it is double, int, SGObject* and some base types | 20:30 |
| @HeikoS | lisitsyn: like all the types for swig right? | 20:30 |
| lisitsyn | no | 20:30 |
| lisitsyn | I think we should use a few | 20:30 |
| lisitsyn | we need really base classes | 20:31 |
| @HeikoS | lisitsyn: for types? | 20:31 |
| lisitsyn | the same types would be visible from plugins | 20:31 |
| lisitsyn | its the next step | 20:31 |
| @HeikoS | lisitsyn: maybe examples would help, I am lost ;) | 20:31 |
| lisitsyn | hmm ok | 20:31 |
| lisitsyn | class GaussianKernel { static Tag<double> width; } | 20:32 |
| lisitsyn | that's how we declare parameter | 20:32 |
| lisitsyn | Tag<?> could be basically anything but if we want speed and plugins | 20:32 |
| lisitsyn | we should restrict what T is | 20:32 |
| lisitsyn | say Tag<LinearMachine> is ok | 20:33 |
| lisitsyn | but Tag<SVM> is not | 20:33 |
| lisitsyn | otherwise SVM is not a plugin | 20:33 |
| lisitsyn | but a part of the core | 20:33 |
| lisitsyn | anyone following? :) | 20:33 |
| @HeikoS | lisitsyn: would that be part of aer? | 20:33 |
| lisitsyn | HeikoS: I'll kill aer and will push ideas from it into shogun gradually | 20:33 |
| lisitsyn | that's how I think it would work | 20:34 |
| @lambday | lisitsyn: I remember you saying that we must need all the base classes in the core - so kinda following :/ | 20:34 |
| @HeikoS | lisitsyn: ok also good | 20:34 |
| @HeikoS | lisitsyn: 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 out | 20:34 |
| @HeikoS | and the getter/Setter stuff is part of that | 20:34 |
| lisitsyn | ah | 20:34 |
| lisitsyn | you mean sublibrary is better? | 20:35 |
| @HeikoS | lisitsyn: yeah | 20:35 |
| lisitsyn | hmm why not | 20:35 |
| @HeikoS | like something independent of Shogun that allows to expose any class framework to all modular languages | 20:35 |
| lisitsyn | yeah I like this idea | 20:35 |
| @lambday | +1 | 20:35 |
| @HeikoS | sonney2k also wanted to do this ages ago | 20:35 |
| @HeikoS | we talked about it GSoC 2013 summit ;) | 20:35 |
| @HeikoS | while hiking through the desert | 20:35 |
| lisitsyn | I like it naming wise | 20:36 |
| lisitsyn | shogun rules a few libs | 20:36 |
| lisitsyn | and decoupling is good | 20:36 |
| @HeikoS | yeah exactly | 20:37 |
| lisitsyn | so my plan is | 20:37 |
| lisitsyn | to add tags | 20:37 |
| lisitsyn | to add generic class that supports tags | 20:37 |
| lisitsyn | and inherit sgobject from it | 20:37 |
| lisitsyn | so we get kool thing | 20:38 |
| lisitsyn | then maybe we should think really really hard | 20:38 |
| @lambday | can we get rid of manual refcounting in the process of that? | 20:38 |
| lisitsyn | hmm yeah | 20:38 |
| lisitsyn | ^ .. really really hard to select base classes | 20:39 |
| lisitsyn | that's *stable* API of shogun | 20:39 |
| lisitsyn | it could lead to some frustration actually | 20:39 |
| lisitsyn | once pluginized you can't produce many methods | 20:39 |
| lisitsyn | it is rather data driven | 20:39 |
| lisitsyn | you pull some kind of task | 20:40 |
| lisitsyn | and parameters | 20:40 |
| @iglesiasg | sorry 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 | |
| lisitsyn | ok we will miss you :) | 20:40 |
| lisitsyn | anyone? :) | 20:40 |
| @lambday | yeah | 20:40 |
| -!- curiousguy13 [~curiousgu@59.177.199.41] has joined #shogun | 20:41 | |
| @lambday | I'd really like to work on that - so maybe we should discuss this a bit more | 20:41 |
| @HeikoS | igbye | 20:41 |
| @lambday | lisitsyn: I read somewhere some issues regarding binary compatibility | 20:41 |
| lisitsyn | ah about binary | 20:41 |
| lisitsyn | if we talk about C++ there is no binary thing | 20:42 |
| @HeikoS | lisitsyn: I dont get that | 20:42 |
| lisitsyn | C++ is doomed abi-wise | 20:42 |
| @lambday | so someone suggested to use C for some parts - since in terms of binary C is better than C++ | 20:42 |
| lisitsyn | yes | 20:42 |
| lisitsyn | C ABI is rock stable | 20:42 |
| @lambday | yeah | 20:42 |
| lisitsyn | HeikoS: what needs explanation? | 20:42 |
| @lambday | so if we aim for platform independence then that is also a matter of concern | 20:42 |
| lisitsyn | lambday: yeah we should develop C++ API | 20:43 |
| lisitsyn | then C layer | 20:43 |
| @lambday | lisitsyn: exactly | 20:43 |
| @HeikoS | lisitsyn: Im not the c/C++ expert | 20:43 |
| lisitsyn | that's the best way I believe | 20:43 |
| lisitsyn | HeikoS: yeah I just don't get what you missed | 20:43 |
| @HeikoS | lisitsyn: what does that mean in practice | 20:43 |
| @HeikoS | ok | 20:43 |
| @HeikoS | so why the seperation? | 20:43 |
| @HeikoS | what would each layer do? | 20:43 |
| @lambday | lisitsyn: I'll read that article in details - it had some serious good stuffs | 20:43 |
| @HeikoS | lisitsyn: would that not be complicated? | 20:43 |
| lisitsyn | hmm | 20:43 |
| lisitsyn | quite a few questions ;) | 20:43 |
| lisitsyn | what separation? | 20:43 |
| @HeikoS | c/C++ | 20:44 |
| lisitsyn | ah | 20:44 |
| lisitsyn | ok C++ supports function overloading | 20:44 |
| @HeikoS | lisitsyn: does that also get rid of the swig madness in terms of memory etc? | 20:44 |
| lisitsyn | HeikoS: hmm not sure | 20:44 |
| lisitsyn | maybe yes | 20:44 |
| lisitsyn | if we get with plugins yes | 20:45 |
| lisitsyn | I mean if we use plugin structure | 20:45 |
| lisitsyn | it would be like a few seconds to compile I think | 20:45 |
| lisitsyn | it won't be that big | 20:45 |
| @HeikoS | thats good | 20:45 |
| lisitsyn | but API would be quite strict | 20:45 |
| @HeikoS | what does that mean? | 20:45 |
| lisitsyn | you won't be able to do same things | 20:45 |
| @HeikoS | concrete? | 20:45 |
| lisitsyn | say you want to develop a new class | 20:45 |
| lisitsyn | that supports FooBar() | 20:45 |
| lisitsyn | I don't see good way to support FooBar() with plugins unless there is a base class in our stable API | 20:46 |
| lisitsyn | that supports FooBar() | 20:46 |
| @HeikoS | ??? | 20:46 |
| @HeikoS | haha | 20:46 |
| @HeikoS | I am so lost | 20:46 |
| lisitsyn | ok | 20:46 |
| lisitsyn | say you have SVM | 20:46 |
| @HeikoS | what is FooBar() ? an instance? a method? | 20:46 |
| lisitsyn | method | 20:46 |
| @HeikoS | method of a new class? | 20:46 |
| @lambday | you can only do things that can be overridden? | 20:46 |
| lisitsyn | yes | 20:46 |
| lisitsyn | yes | 20:46 |
| @lambday | okay | 20:47 |
| lisitsyn | you can provide only methods from the API | 20:47 |
| lisitsyn | or it would be some trick | 20:47 |
| lisitsyn | to call it | 20:47 |
| lisitsyn | ok let me talk code | 20:47 |
| lisitsyn | svm = shogun.machine("SVM"); | 20:47 |
| lisitsyn | bam | 20:47 |
| lisitsyn | we get svm | 20:47 |
| lisitsyn | we can train svm | 20:47 |
| lisitsyn | svm.train(); | 20:47 |
| lisitsyn | but we can't get support vectors | 20:48 |
| @lambday | ah | 20:48 |
| lisitsyn | because support vectors are not in our *generic* API | 20:48 |
| lisitsyn | what we would have to do is | 20:48 |
| @HeikoS | lisitsyn: but why is that good then? | 20:48 |
| lisitsyn | sv = svm.get("support_vectors"); | 20:48 |
| lisitsyn | like that | 20:48 |
| @HeikoS | if one cannot add custom methods, thats quite a restriction | 20:49 |
| lisitsyn | HeikoS: because it is the only way for plugins | 20:49 |
| @lambday | have some generic thing in the base which would allow to do subclass specific things in overridden way | 20:49 |
| @HeikoS | what about void precompute_alpha() | 20:49 |
| lisitsyn | HeikoS: it would be svm.call("precompute_alpha"); or so | 20:49 |
| lisitsyn | or | 20:49 |
| lisitsyn | svm.do(svm.operations.precompute_alpha); | 20:49 |
| @HeikoS | not sure whether I like that to be honest | 20:49 |
| lisitsyn | this is also possible | 20:49 |
| @HeikoS | convoluted | 20:49 |
| lisitsyn | HeikoS: yes but no swig problems and very dynamic | 20:50 |
| @HeikoS | lisitsyn: sure agreed | 20:50 |
| @lambday | 2nd one sounds better | 20:50 |
| lisitsyn | yes | 20:50 |
| @lambday | I hate string tags | 20:50 |
| lisitsyn | yes strings suck | 20:50 |
| @HeikoS | Shogun is a ML toolbox though, we want users and developers to be able to put things in the code that allow for custom computations | 20:50 |
| @HeikoS | so at the bottom of the class tree I expect there to be tons of custom operatilons | 20:51 |
| @HeikoS | operations | 20:51 |
| lisitsyn | yeah | 20:51 |
| lisitsyn | but they should not be exposed | 20:51 |
| lisitsyn | that enforces a good practice actually | 20:51 |
| @HeikoS | exposed? | 20:51 |
| lisitsyn | but too strict | 20:51 |
| @lambday | lisitsyn: why classname.do(...) cannot be exposed? | 20:51 |
| @HeikoS | to swig? or to public | 20:51 |
| lisitsyn | yeah I mean you do custom operation just to train machine | 20:51 |
| lisitsyn | or something like that | 20:52 |
| @HeikoS | lisitsyn: think about all the stuff one can do after trainnig | 20:52 |
| @HeikoS | lisitsyn: SVs, get_w, labels_to_prbabilities | 20:52 |
| lisitsyn | you mean like various inference things? | 20:52 |
| @HeikoS | yeah | 20:52 |
| @HeikoS | get_inducing_points | 20:52 |
| lisitsyn | well | 20:52 |
| @HeikoS | get_posterior_covariance | 20:52 |
| @HeikoS | etc | 20:52 |
| lisitsyn | what I propose ruins syntax | 20:52 |
| lisitsyn | that's true | 20:52 |
| lisitsyn | but you get other things | 20:53 |
| lisitsyn | you can compile your plugin standalone | 20:53 |
| lisitsyn | it is a second and you run it | 20:53 |
| lisitsyn | with such development cycle you can be quite fast | 20:53 |
| @HeikoS | true, | 20:53 |
| @HeikoS | but in practice? | 20:53 |
| @HeikoS | I use ccache and this is also very fast | 20:53 |
| @HeikoS | ccache-swig also seems to work nowadays | 20:53 |
| @HeikoS | I like the getter/stter thing though | 20:54 |
| lisitsyn | well I don't know | 20:54 |
| @HeikoS | and of course that things are modular | 20:54 |
| @HeikoS | any other projects having experience on such a design? | 20:54 |
| @HeikoS | wiking: mentioned something a while ago | 20:54 |
| -!- vortex_ape [~vortex_ap@120.59.76.228] has joined #shogun | 20:54 | |
| lisitsyn | hmm I didn't do any research on that | 20:54 |
| @HeikoS | lisitsyn: I think best thing would be to get an estimate on effort and improvement | 20:55 |
| @HeikoS | its quite a major change | 20:55 |
| lisitsyn | that's pretty hard | 20:55 |
| @lambday | lisitsyn: could you please explain a bit about why the do() method that you propose cannot be exposed to modular interface? | 20:55 |
| lisitsyn | lambday: they can | 20:55 |
| @lambday | lisitsyn: so are we actually losing anything with that? I mean it's mostly syntactics | 20:56 |
| lisitsyn | yes mostly syntax | 20:56 |
| -!- vortex_ape [~vortex_ap@120.59.76.228] has quit [Remote host closed the connection] | 20:56 | |
| @HeikoS | lisitsyn: maybe prototype is a good idea, but dont know | 20:56 |
| lisitsyn | it could be pretty ugly syntax to be honest | 20:56 |
| @HeikoS | lisitsyn: hey, since I have to leave soon | 20:57 |
| lisitsyn | HeikoS: its controversial I don't know if it is good | 20:57 |
| @lambday | I don't think then that it would stand in the way of our iterating addition model of dev | 20:57 |
| @HeikoS | lisitsyn: also wanted to talk a bit about manual project | 20:57 |
| lisitsyn | ah | 20:57 |
| lisitsyn | yeah | 20:57 |
| yorkerlin | One cmake question: Can we choose compile a modular (say, GP modular) without compiling all irrelevant ones (eg, SVM)? | 20:57 |
| lisitsyn | yorkerlin: pretty hard | 20:58 |
| @HeikoS | yorkerlin: good point | 20:58 |
| @HeikoS | we have a demo for that | 20:58 |
| @HeikoS | thoralf: did that | 20:58 |
| @HeikoS | I think this might be good alternative in fact | 20:58 |
| lisitsyn | guys I have to leave for 15 minutes | 20:58 |
| lisitsyn | HeikoS: will you be gone then? | 20:59 |
| @HeikoS | lisitsyn: yeah | 20:59 |
| lisitsyn | argh | 20:59 |
| @HeikoS | well | 20:59 |
| lisitsyn | ok so | 20:59 |
| @HeikoS | Im online most days | 20:59 |
| lisitsyn | ah | 20:59 |
| lisitsyn | ok | 20:59 |
| @HeikoS | just good to get the talking going | 20:59 |
| lisitsyn | yeah | 20:59 |
| @HeikoS | yorkerlin, thoralf did a bash based version of that | 20:59 |
| @HeikoS | ok | 20:59 |
| lisitsyn | HeikoS: can you push me a bit on the manual thing then | 20:59 |
| @HeikoS | I leave you guys to it | 20:59 |
| @HeikoS | lisitsyn: yeah will do ;) | 21:00 |
| @HeikoS | thats almost done so good to fnish | 21:00 |
| @HeikoS | and then let people populate | 21:00 |
| yorkerlin | \ping @HeikoS any link? | 21:00 |
| lisitsyn | lambday: ok when I am back we can discuss api :) | 21:00 |
| @HeikoS | yorkerlin: searching | 21:01 |
| @lambday | lisitsyn: alright.. see you | 21:01 |
| yorkerlin | another question /ping @lambday, if we use SGMatrix, can we choose use GPUMatrix and CPUMatrix on-the-fly or on compilation time | 21:02 |
| -!- HeikoS [~heiko@05419e79.skybroadband.com] has quit [Quit: Leaving.] | 21:02 | |
| @lambday | yorkerlin: I'm afraid not - I remember discussing about this but we dumped that idea for some valid reasons - SG is always CPU | 21:03 |
| @lambday | yorkerlin: or maybe I didn't understand your question? | 21:04 |
| -!- vortex_ape [~vortex_ap@120.59.76.228] has joined #shogun | 21:04 | |
| yorkerlin | so we have to GPU matix in codes. | 21:04 |
| @lambday | yorkerlin: as of now, yes. | 21:05 |
| @lambday | yorkerlin: since the use-case is pretty application specific, I think it is good that way | 21:05 |
| yorkerlin | if we do not have supported GPU, the GUP matrix will use eigen3? | 21:06 |
| yorkerlin | if we have GPU matrix and we use linalg, | 21:06 |
| @lambday | yorkerlin: nope. GPU is basically ViennaCL matrixbase syntactic sugar - so in absence of GPU, it will use CPU just like ViennaCL does | 21:06 |
| yorkerlin | ok. seems good. | 21:07 |
| @lambday | if you don't have ViennaCL, you miss the entire GPUMatrix class | 21:07 |
| yorkerlin | about kernel part. For GPU speedup, currently kernel returns SGMatrix. | 21:08 |
| yorkerlin | if we want to use GPU matrix, currently we have to copy SGMatrix to GPUMatrix | 21:09 |
| yorkerlin | right? | 21:09 |
| @lambday | yorkerlin: yeah that's awful. | 21:09 |
| @lambday | yorkerlin: but you don't wanna change that in the base | 21:09 |
| @lambday | since not always we'll use GPU for kernel computation (so far I understood from the discussion) | 21:10 |
| yorkerlin | yes. GPU speed up for kernel computation is a next step | 21:10 |
| @lambday | or maybe I miss something here | 21:10 |
| @lambday | yorkerlin: 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 | |
| yorkerlin | I am not familiar with many kernels. | 21:12 |
| @lambday | neither am I.. Heiko is the guy to ask then | 21:12 |
| yorkerlin | the issue is if viennaCL is missing, what can we do | 21:13 |
| @lambday | yorkerlin: well - since we decided to go with ViennaCL for our GPU stuffs, we'll miss all of that | 21:13 |
| @lambday | other solution is to write all those linalg ops using OpenCL or CUDA ourselves which is bad | 21:14 |
| @lambday | yorkerlin: why are you concerned about viennacl being missing? | 21:15 |
| yorkerlin | since kernel computation is essnetial for shogun, if we use viennaCL for kernel computation, what can we do? | 21:16 |
| yorkerlin | and viennaCl is missing | 21:16 |
| @lambday | yorkerlin: hmm ok.. gotta have some fallback mechanism | 21:17 |
| @lambday | yorkerlin: I don't think that's gonna be hard - just some additional code | 21:18 |
| yorkerlin | ok. seems good | 21: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 |
| @lambday | yorkerlin: what kind of linalg operations do you need there? | 21:19 |
| @lambday | yorkerlin: yeah that sounds good | 21:20 |
| yorkerlin | cholesky | 21:20 |
| @lambday | okay - hmm we don't have that yet | 21:20 |
| @lambday | I think getting linalg in a matured state is gonna take a while | 21:20 |
| @lambday | :( | 21:21 |
| yorkerlin | ok. | 21:21 |
| yorkerlin | once linalg is stable, we can start work on it | 21:21 |
| @lambday | yorkerlin: yeah! if you keep pushing me for new stuffs, then I'll get motivated a bit more :D | 21:22 |
| yorkerlin | cool! :) I leave now. I will post a issue about this. | 21:22 |
| @lambday | yorkerlin: what you're doing BTW? Masters? | 21:22 |
| @lambday | yorkerlin: okay man ttyl :) | 21:23 |
| -!- yorkerlin [b8af2f1e@gateway/web/freenode/ip.184.175.47.30] has quit [Quit: Page closed] | 21:23 | |
| lisitsyn | lambday: ok I am backz | 21:27 |
| @lambday | lisitsyn: hey.. | 21:27 |
| @lambday | so about aer | 21:28 |
| lisitsyn | yes | 21:28 |
| lisitsyn | lambday: anything you want to clarify? | 21:30 |
| @lambday | lisitsyn: Heiko had some valid point about usability - I'm not sure how to manage it properly | 21:33 |
| @lambday | from what I understood, with the do() stuffs we can pretty much achieve anything custom | 21:34 |
| lisitsyn | yeah probably yes | 21:35 |
| @lambday | lisitsyn: how does this go with d-ptrs ? | 21:35 |
| @lambday | do() thing is in the outer class then custom methods are in the inner | 21:35 |
| lisitsyn | yes | 21:36 |
| lisitsyn | all would be in .cpp files I think | 21:36 |
| @lambday | yeah | 21:36 |
| @lambday | and there will be enums? | 21:36 |
| lisitsyn | for operations? | 21:36 |
| lisitsyn | hmm I just realized | 21:37 |
| lisitsyn | we have to use strings | 21:37 |
| @lambday | since functors are not accessible from modular :/ | 21:37 |
| lisitsyn | say svm provides support_vectors | 21:37 |
| @lambday | ok | 21:37 |
| lisitsyn | we'd have to svm.get("support_vectors") | 21:37 |
| lisitsyn | or add a tag for that | 21:38 |
| @lambday | tag thing is faster | 21:38 |
| lisitsyn | yeah and it is typed | 21:38 |
| @lambday | but ugly if mapped to modular | 21:39 |
| @lambday | for all T you have to give them new names | 21:39 |
| @lambday | right? | 21:39 |
| lisitsyn | no | 21:39 |
| lisitsyn | overloading would work | 21:39 |
| @lambday | how one creates Tag<T> from python modular then? | 21:39 |
| lisitsyn | yes | 21:39 |
| lisitsyn | that's the point | 21:40 |
| lisitsyn | here you'd need new names | 21:40 |
| lisitsyn | *but* | 21:40 |
| lisitsyn | you can provide them out of box | 21:40 |
| lisitsyn | like gaussian kernel width is a member of gaussian kernel | 21:40 |
| lisitsyn | width tag* | 21:40 |
| @lambday | oh i see | 21:40 |
| lisitsyn | but no plugins then haha | 21:41 |
| @thoralf | Someone mentioned my bash-hack to compile a incomplete version of SHOGUN. | 21:41 |
| @thoralf | https://github.com/tklein23/shogun-partial-build | 21:41 |
| lisitsyn | oh | 21:41 |
| lisitsyn | wu is gone | 21:41 |
| lisitsyn | but thanks | 21:41 |
| @lambday | lisitsyn: because gaussian goes to core then? :/ | 21:42 |
| lisitsyn | yeaas | 21:42 |
| lisitsyn | lambday: I broke my head with that already | 21:42 |
| lisitsyn | whatever you do you meet some other restriction :D | 21:42 |
| @lambday | argh | 21:42 |
| @lambday | I am starting to wonder if plugin is really for the development model we have here at Shogun :/ | 21:43 |
| lisitsyn | I don't know | 21:43 |
| @lambday | lisitsyn: okay we can forget tag then - strings are fine | 21:43 |
| lisitsyn | no we should still use tags I think | 21:44 |
| lisitsyn | if you use strings you'd have to case anyway | 21:44 |
| lisitsyn | so its cheaper to create tag from string once | 21:44 |
| lisitsyn | s/case/cast | 21:44 |
| @lambday | hmm | 21:45 |
| @lambday | lisitsyn: 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 |
| @lambday | lisitsyn: see you soon | 21:56 |
| -!- lambday [6a3386ac@gateway/web/freenode/ip.106.51.134.172] has quit [Quit: Leaving.] | 21:56 | |
| lisitsyn | lambday: ok see you | 22:25 |
| @thoralf | Bye. | 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 #shogun | 23:36 | |
| --- Log closed Tue Jul 14 00:00:52 2015 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!