--- Log opened Tue Oct 14 00:00:24 2014 | ||
-!- iglesiasg [~iglesias@524B8E0B.cm-4-4c.dynamic.ziggo.nl] has quit [Quit: Lost terminal] | 00:50 | |
-!- wiking_ [~wiking@info2k1.hu] has joined #shogun | 02:32 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Read error: Connection reset by peer] | 02:32 | |
-!- wiking_ [~wiking@info2k1.hu] has quit [Read error: Connection reset by peer] | 02:32 | |
-!- wiking [~wiking@info2k1.hu] has joined #shogun | 02:37 | |
-!- wiking [~wiking@info2k1.hu] has quit [Read error: Connection reset by peer] | 02:40 | |
-!- wiking [~wiking@info2k1.hu] has joined #shogun | 02:42 | |
-!- wiking [~wiking@info2k1.hu] has quit [Read error: Connection reset by peer] | 02:45 | |
-!- wiking [~wiking@info2k1.hu] has joined #shogun | 02:47 | |
-!- wiking [~wiking@info2k1.hu] has quit [Read error: Connection reset by peer] | 02:47 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 02:56 | |
-!- mode/#shogun [+o wiking] by ChanServ | 02:56 | |
-!- pickle27 [~pickle27@192-0-136-118.cpe.teksavvy.com] has quit [Remote host closed the connection] | 03:15 | |
-!- wiking_ [~wiking@info2k1.hu] has joined #shogun | 04:46 | |
-!- Netsplit *.net <-> *.split quits: @wiking | 04:54 | |
-!- wiking_ is now known as wiking | 04:57 | |
-!- wiking [~wiking@info2k1.hu] has quit [Changing host] | 04:57 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 04:57 | |
-!- mode/#shogun [+o wiking] by ChanServ | 04:57 | |
-!- lambday [67157e4e@gateway/web/freenode/ip.103.21.126.78] has joined #shogun | 10:56 | |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has joined #shogun | 10:58 | |
-!- mlilenium_ [~mlilenium@178.251.136.142] has joined #shogun | 11:58 | |
-!- mlilenium_ [~mlilenium@178.251.136.142] has left #shogun [] | 11:59 | |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has quit [Quit: PirosB3] | 13:17 | |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has joined #shogun | 13:31 | |
-!- lambday [67157e4e@gateway/web/freenode/ip.103.21.126.78] has quit [Ping timeout: 246 seconds] | 14:09 | |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has quit [Quit: PirosB3] | 14:22 | |
-!- soumyaC [uid15286@gateway/web/irccloud.com/x-jtwbswvxtyqnmrve] has joined #shogun | 14:43 | |
-!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has joined #shogun | 14:47 | |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has joined #shogun | 15:48 | |
-!- ialong [9052b472@gateway/web/freenode/ip.144.82.180.114] has joined #shogun | 16:00 | |
-!- HeikoS [~heiko@nat-204-182.internal.eduroam.ucl.ac.uk] has joined #shogun | 16:03 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 16:03 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 16:58 | |
shogun-notifier- | shogun: Sergey Lisitsyn :develop * 5894cdb / src/interfaces/python_static/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/5894cdb230387853d6593287fe4d27f77f031746 | 16:58 |
---|---|---|
shogun-notifier- | shogun: Fixed python_static compilation error | 16:58 |
shogun-buildbot | build #3212 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3212 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 17:04 |
-!- travis-ci [~travis-ci@ec2-174-129-79-49.compute-1.amazonaws.com] has joined #shogun | 17:23 | |
travis-ci | it's Sergey Lisitsyn's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/37946712 | 17:23 |
-!- travis-ci [~travis-ci@ec2-174-129-79-49.compute-1.amazonaws.com] has left #shogun [] | 17:23 | |
-!- ialong [9052b472@gateway/web/freenode/ip.144.82.180.114] has quit [Ping timeout: 246 seconds] | 17:26 | |
lambday | HeikoS: lisitsyn: hi | 17:51 |
@lisitsyn | lambday: heya | 17:51 |
lambday | lisitsyn: how's it going man? | 17:51 |
@lisitsyn | lambday: oh very busy but cool | 17:51 |
@lisitsyn | what about you? | 17:51 |
lambday | haha | 17:51 |
lambday | lisitsyn: I came back to college to finish my degree.. | 17:51 |
lambday | so back to Mumbai again | 17:52 |
@lisitsyn | lambday: hmm interesting | 17:52 |
@lisitsyn | wasn't it finished? | 17:52 |
lambday | lisitsyn: thesis work was incomplete.. so joined the company.. did training and worked for 3 months... now came back and finish it off | 17:52 |
@lisitsyn | I see | 17:53 |
@lisitsyn | so you escaped oracle? | 17:53 |
lambday | lisitsyn: nah.. :D took leave | 17:54 |
@lisitsyn | ah | 17:54 |
lambday | lisitsyn: was going through aer.. | 17:54 |
@lisitsyn | lambday: ah cool | 17:55 |
@lisitsyn | let me know what you think | 17:55 |
lambday | lisitsyn: cool thing with the Any thing | 17:55 |
lambday | lisitsyn: I was also going through this tutorial on dr. dobbs... where they try to make it cross platform | 17:55 |
lambday | currently aer is linux only, right? | 17:55 |
@lisitsyn | hmm yeah | 17:55 |
@lisitsyn | but shouldn't be a problem | 17:55 |
lambday | so that thing we can look into.. | 17:55 |
@lisitsyn | it is posix now | 17:55 |
lambday | lisitsyn: I was redesigning the statistical hypothesis testing part.. I think with the help of Any we can boost things up a notch | 17:56 |
lambday | also, so far I understood... this design fits nicely with the plugin design you have | 17:57 |
@lisitsyn | lambday: yeah any thing comes from boost | 17:57 |
@lisitsyn | as usual boost things are cool | 17:57 |
@lisitsyn | although boost's any is not cool I believe :D | 17:58 |
lambday | lol I didn't mean that boost but yeah | 17:58 |
@lisitsyn | I mean they just get RTTI | 17:58 |
@lisitsyn | from the type | 17:58 |
lambday | I meant power it up | 17:58 |
lambday | yeah | 17:58 |
@lisitsyn | and then compare strings | 17:58 |
@lisitsyn | that's like super slow | 17:58 |
lambday | oh one thing I needed to discuss... if you have time | 17:58 |
@lisitsyn | sure | 18:01 |
lambday | lisitsyn: at one place, I need to downcast from base feature/kernel ptr type to the actual feature/kernel ptr type... currently I'm doing that inside a switch case with the help of the enums that we have | 18:01 |
@lisitsyn | lambday: I guess virtual function :D | 18:01 |
@lisitsyn | but it would be not very nice I guess | 18:01 |
lambday | virtual function for what? typecasting? | 18:02 |
lambday | lisitsyn: I was thinking of demangling stuff that you have in aer | 18:03 |
@lisitsyn | oh demangling doesn't sound reliable | 18:03 |
@lisitsyn | can you explain it a bit more? | 18:03 |
lambday | ok.. trying | 18:03 |
@lisitsyn | so you have to act according to the type of kernel? | 18:04 |
lambday | lisitsyn: so what we need is this - a set_foo(Base* ptr) function (non-templated) which calls a templated push_back(Derived* ptr) function internally with the actual type | 18:05 |
lambday | set_foo we releave to the modular interface | 18:05 |
lambday | reveal* | 18:05 |
lambday | now this thing is easy for features and kernels since we have these enums | 18:05 |
lambday | but what if I want this thing to work with a user defined feature class as well | 18:06 |
lambday | (not a hard requirement - just a good thing to have - users defining their own feature class with whatever the hell they wanna use - they just write a few policy classes that is required by the framework and voila! | 18:07 |
lambday | lisitsyn: one idea was to make set_foo(...) method templated.. but then one cannot use this set_foo(...) inside some non-templated (probably virtual) method where the ptr thing is passes as Base* and not Derived* | 18:09 |
lambday | so while set_foo calls push_back, we need to make the cast | 18:09 |
@lisitsyn | lambday: I guess it is called multimethod | 18:10 |
@lisitsyn | quite a few ways to implement it :D | 18:10 |
lambday | lisitsyn: name a few :D | 18:10 |
@lisitsyn | lambday: iirc alexandrescu has some crazy stuff in his book about that | 18:11 |
@lisitsyn | lambday: anyway exposing templated method doesn't sound nice | 18:11 |
lambday | lisitsyn: that's what I thought.. | 18:11 |
lambday | and by his book you mean modern c++ design, right | 18:12 |
@lisitsyn | yeah | 18:12 |
@lisitsyn | lambday: why do you need to call this method on derived? | 18:12 |
lambday | so that I can set some type specific policies based on the actual type | 18:13 |
lambday | without the wrapper having to worry about the internal | 18:13 |
lambday | lisitsyn: | 18:13 |
lambday | ah wiki for multimethods uses a hashmap sort of thing - this is what I was thinking | 18:14 |
@lisitsyn | lambday: well yeah you can actually put a map | 18:15 |
@lisitsyn | but that's slower than virtual method | 18:15 |
lambday | and what should be the appropriate key-value pair that I can use in that map? a string as key and a functor as a value :D | 18:16 |
@lisitsyn | lambday: what are real names for these methods? | 18:16 |
lambday | set_p(CFeatures* feats) .. set_q... set_kernel_p, set_kernel_q... | 18:17 |
@lisitsyn | ah so you want to dispatch | 18:18 |
lambday | lisitsyn: https://github.com/lambday/flash/blob/develop/src/flash/statistics/HypothesisTest.cpp#L92 | 18:18 |
@lisitsyn | CFeatures -> features used by kernel | 18:18 |
lambday | this is what I have | 18:18 |
lambday | ummm... no | 18:18 |
lambday | I mean yeah eventually... but that's not why I require it here | 18:19 |
@lisitsyn | lambday: static_cast<typename feats_traits<C_DENSE,F_DREAL>::type*> | 18:20 |
@lisitsyn | what does it return? | 18:20 |
@lisitsyn | what type? | 18:20 |
lambday | CDenseFeatures<float64_t> | 18:20 |
lambday | inside feats_traits its defined | 18:21 |
@lisitsyn | lambday: does your data manager work different for that? | 18:21 |
lambday | yes | 18:21 |
lambday | it does something for dense, for sparse, and for streaming dense, streamaing sparse | 18:21 |
lambday | for strings | 18:21 |
lambday | etc | 18:21 |
@lisitsyn | lambday: okay I'd actually suggest you to avoid using templates here as it is called only once | 18:22 |
@lisitsyn | you don't really need perfomance here I believe | 18:22 |
lambday | lisitsyn: nah just a nicer way to handle this | 18:22 |
@lisitsyn | lambday: I think you'd better go with some virtual methods | 18:22 |
@lisitsyn | and dispatch all these fetchers and permutators dynamically | 18:23 |
lambday | lisitsyn: so you're suggesting making push_back non-templated | 18:23 |
@lisitsyn | yeah | 18:23 |
@lisitsyn | lambday: if you want to dispatch it before push back | 18:24 |
@lisitsyn | I can suggest to create some temporary object | 18:24 |
lambday | and virtual methods have to be overridden somewhere for all the features and kernels I want to support | 18:24 |
@lisitsyn | well you can delegate it to kernel | 18:24 |
@lisitsyn | or feature | 18:24 |
lambday | lisitsyn: could you please explain a bit on the temporary object creation part? | 18:26 |
lambday | because I thought of that but couldn't do it | 18:26 |
@lisitsyn | well you need permutator and fetcher | 18:26 |
lambday | yep | 18:26 |
@lisitsyn | so you can push_back some object that stores features, permutator and fetcher | 18:26 |
@lisitsyn | basically a tuple of these three | 18:27 |
lambday | but for getting the appropriate fetcher and permutator, we need to know the actual type | 18:27 |
lambday | even if we add another level of abstraction still it has to be handled by someone | 18:28 |
@lisitsyn | lambday: can you delegate fetcher to the feature? | 18:28 |
@lisitsyn | I mean can you let feature know of fetcher to use | 18:28 |
@lisitsyn | feature->get_fetcher() | 18:28 |
lambday | lisitsyn: ah if these things are members then its super easy but this fetching and permutating thing is specific to the application.. so adding these to feature is probably not what we want | 18:29 |
@lisitsyn | okay then create some dispatcher | 18:29 |
@lisitsyn | dispatcher->get_fetcher(feature); | 18:30 |
lambday | what we can do is the define a internal feature class for this application and map CFeatures into that | 18:30 |
lambday | lisitsyn: dispatcher as a base class you mean? | 18:31 |
@lisitsyn | lambday: well just some class that creates propers objects for you | 18:32 |
lambday | lisitsyn: that's what I had with get_instance - just that its templated | 18:32 |
@lisitsyn | lambday: don't think you need it templated - looks like you going to suffer with this | 18:33 |
@lisitsyn | not sure if these struggles worth it :) | 18:33 |
lambday | lisitsyn: well, the other way is ugly copy paste :( | 18:34 |
lambday | I thought let compiler do all that :D | 18:34 |
@lisitsyn | ok my advice is to put all the dispatch to one place | 18:34 |
@lisitsyn | and then you can play with that somehow | 18:34 |
@lisitsyn | maps or something virtual | 18:34 |
lambday | as in, as overloaded methods? | 18:35 |
lambday | okay | 18:35 |
@lisitsyn | push_back(dispatch(features)); | 18:35 |
@lisitsyn | let it go to some dispatch | 18:35 |
@lisitsyn | then you at least have all the horror isolated in one function or class | 18:36 |
lambday | lisitsyn: yeah that can be done - either the horror is there with the enums or dispatch | 18:37 |
@lisitsyn | lambday: I think some table (kind of enum map) would work quite fast | 18:38 |
@lisitsyn | int -> factory of permutators | 18:39 |
lambday | lisitsyn: yeah... that's a better idea | 18:39 |
@wiking | btw: https://github.com/Yelp/MOE | 18:39 |
lambday | lisitsyn: but horrifying thing is that we have two enums for features - feature type and feature class :( | 18:40 |
lambday | lisitsyn: why don't you like demangling stuffs? cause its compiler dependent? | 18:42 |
@lisitsyn | lambday: slow and non-portable | 18:43 |
@lisitsyn | okay got to go | 18:45 |
lambday | lisitsyn: alright.. thanks man | 18:45 |
lambday | btw +1 for the naming convention :D | 18:45 |
lambday | for shogun :D | 18:45 |
@lisitsyn | haha | 18:46 |
lambday | btw found this place in Bangalore - thought I should share - http://image6.buzzintown.com/files/venue/upload_8000/upload_original/373327-shogun-malgudi-dhaba.PNG | 18:49 |
lambday | went to the place - nice food :) | 18:49 |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has quit [Quit: PirosB3] | 19:23 | |
-!- txomon|home [~txomon@unaffiliated/txomon] has quit [Ping timeout: 245 seconds] | 19:28 | |
-!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has quit [Ping timeout: 246 seconds] | 19:29 | |
-!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has joined #shogun | 19:34 | |
-!- txomon|home [~txomon@unaffiliated/txomon] has joined #shogun | 19:41 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 19:58 | |
-!- HeikoS [~heiko@nat-204-182.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 20:09 | |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has joined #shogun | 21:41 | |
-!- PirosB3 [~pirosb3@ip-66.net-81-220-115.brest.rev.numericable.fr] has quit [Quit: PirosB3] | 22:20 | |
-!- lambday [67157f4f@gateway/web/freenode/ip.103.21.127.79] has quit [Ping timeout: 246 seconds] | 23:33 | |
--- Log closed Wed Oct 15 00:00:25 2014 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!