| --- Log opened Thu Jan 24 00:00:41 2019 | ||
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 00:04 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 00:06 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 00:06 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 00:42 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 01:55 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 01:55 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 240 seconds] | 01:59 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 02:44 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 02:44 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 250 seconds] | 02:48 | |
| -!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 06:45 | |
| -!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Changing host] | 06:45 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 06:45 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 06:45 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 246 seconds] | 06:49 | |
| -!- gf712 [8028b333@gateway/web/freenode/ip.128.40.179.51] has joined #shogun | 08:38 | |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 09:59 | |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Remote host closed the connection] | 10:07 | |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 10:12 | |
| gf712 | wiking_ hey | 10:16 |
|---|---|---|
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Ping timeout: 245 seconds] | 10:16 | |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 10:41 | |
| gf712 | wiking_ hey | 10:58 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Ping timeout: 240 seconds] | 10:59 | |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 11:24 | |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Remote host closed the connection] | 11:29 | |
| -!- HeikoS [5aae0441@gateway/web/cgi-irc/kiwiirc.com/ip.90.174.4.65] has joined #shogun | 11:43 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 11:43 | |
| @HeikoS | gf712 yo | 11:43 |
| @HeikoS | lisitsyn yo | 11:43 |
| lisitsyn | HeikoS: hello | 11:43 |
| @HeikoS | lisitsyn I have a suggestion | 11:43 |
| lisitsyn | yas | 11:43 |
| lisitsyn | what is? | 11:44 |
| @HeikoS | I want to get rid of all swig related code in libshogun | 11:44 |
| @HeikoS | and move it to the swig c++ code | 11:44 |
| @HeikoS | like parameter_names etc | 11:44 |
| @HeikoS | things that would only be necessary from interfaces | 11:44 |
| @HeikoS | as otherwise we have the c++ strongly typed api | 11:44 |
| lisitsyn | well sounds good | 11:44 |
| @HeikoS | this means that the c++ api and the swig api will change | 11:44 |
| @HeikoS | as for example factories will be moved to swig code | 11:45 |
| @HeikoS | this means no more meta examples in c++ | 11:45 |
| @HeikoS | what are your thoughts on that? | 11:45 |
| lisitsyn | why to move factories? | 11:45 |
| @HeikoS | because there are constructors | 11:45 |
| lisitsyn | but what about plugins? | 11:46 |
| @HeikoS | ah | 11:46 |
| @HeikoS | you see, this is why I ask :) | 11:46 |
| @HeikoS | plugins need factories as well | 11:46 |
| @HeikoS | mmh | 11:46 |
| lisitsyn | yeah but if you have other way to use plugins without factories | 11:46 |
| @HeikoS | actually this then might not make sense | 11:46 |
| lisitsyn | it would work | 11:46 |
| @HeikoS | things like getting the parameter names | 11:47 |
| @HeikoS | is this also necessary? | 11:47 |
| lisitsyn | this one I am not sure | 11:47 |
| @HeikoS | I give you a plugin for a machine | 11:47 |
| @HeikoS | you want to use it from c++ but you dont have the source | 11:47 |
| lisitsyn | well I have one idea though | 11:48 |
| @HeikoS | then you would want parameter names and description or? | 11:48 |
| lisitsyn | it might be that plugin always comes with a header | 11:48 |
| lisitsyn | because it is C++ and you're gonna compile that anyway | 11:48 |
| lisitsyn | so basically plugin might be distributed as .h + .so | 11:49 |
| lisitsyn | then we need no factories | 11:49 |
| lisitsyn | and no introspection things | 11:49 |
| @HeikoS | ah | 11:49 |
| lisitsyn | see what I mean? | 11:49 |
| @HeikoS | is that what we had in mind initially? | 11:49 |
| lisitsyn | no | 11:49 |
| lisitsyn | I think no | 11:49 |
| @HeikoS | yes the header as part of plugin I guess | 11:49 |
| lisitsyn | it is a new idea for me | 11:50 |
| lisitsyn | :D | 11:50 |
| lisitsyn | just realized it might be good | 11:50 |
| @HeikoS | so this is for the case of using the plugin in c++ program | 11:50 |
| lisitsyn | the header basically defines the objects | 11:50 |
| lisitsyn | and its parameters also | 11:50 |
| @HeikoS | otherwise I would just use the .so and shogunswig.so | 11:50 |
| lisitsyn | because tags | 11:50 |
| @HeikoS | how do you mean for the parameters? | 11:50 |
| lisitsyn | class LibSVM { static Tag<float> C } | 11:51 |
| lisitsyn | something like that | 11:51 |
| @HeikoS | I see | 11:51 |
| lisitsyn | so you can use typed thing | 11:51 |
| @HeikoS | the name registration is not visible though as that is runtime | 11:51 |
| lisitsyn | yeah | 11:51 |
| @HeikoS | but that is for swig | 11:51 |
| @HeikoS | for c++ one can use tags | 11:51 |
| lisitsyn | yes | 11:51 |
| lisitsyn | tags are defined in .h | 11:51 |
| @HeikoS | so actually, we can even more the getters/setters that use strings into swig right? | 11:51 |
| lisitsyn | yes | 11:52 |
| @HeikoS | ok that is good | 11:52 |
| lisitsyn | I think they make not much sense in C++ | 11:52 |
| @HeikoS | what about the meta examples? | 11:52 |
| @HeikoS | they will break | 11:52 |
| @HeikoS | because API is not unified anymore | 11:52 |
| @HeikoS | so we won't have c++ examples unless we write them | 11:52 |
| lisitsyn | what wouldn't work? | 11:52 |
| @HeikoS | like factories | 11:52 |
| lisitsyn | ah | 11:52 |
| @HeikoS | which are used in there | 11:52 |
| @HeikoS | or generic put/get | 11:53 |
| @HeikoS | well get we have typed | 11:53 |
| @HeikoS | but then we would also have to make the meta language for put | 11:53 |
| @HeikoS | something like | 11:53 |
| @HeikoS | svm.putReal("C", 1.0) | 11:53 |
| lisitsyn | I am unsure about this thing yet | 11:53 |
| @HeikoS | I mean it is not the worst thing | 11:53 |
| @HeikoS | the meta examples having a unified api in c++ and swig is awkward anyways | 11:53 |
| @HeikoS | for many reasons | 11:53 |
| @HeikoS | type safety | 11:54 |
| @HeikoS | wrap | 11:54 |
| lisitsyn | I feel like targeting python/etc is a bit more important anyway | 11:54 |
| @HeikoS | some | 11:54 |
| lisitsyn | but I can't decide there | 11:54 |
| @HeikoS | I wonder whether we could convince ourselves that pelple who want the c++ api can just read the doxygen? :D | 11:54 |
| @HeikoS | since they know c++ code, they can read unittests and the API | 11:54 |
| @HeikoS | well I am asking for opinions | 11:55 |
| @HeikoS | so that we can discuss with the others | 11:55 |
| lisitsyn | yeah C++ is something more advanced | 11:55 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 11:55 | |
| @HeikoS | wiking_ yo | 11:56 |
| wiking_ | almost | 11:56 |
| wiking_ | not yet | 11:56 |
| gf712 | HeikoS hey, trying to understand this conversation :D | 11:56 |
| @HeikoS | gf712 hi | 11:57 |
| @HeikoS | wiking_ let me know once you have a minute I would like to run something by you | 11:57 |
| @HeikoS | gf712 questions / opinions welcome :) | 11:57 |
| gf712 | ok, so from basics, so I can just find my bearings... | 11:58 |
| lisitsyn | HeikoS: but why to drop C++ api? | 11:58 |
| lisitsyn | I mean is it causing any problems now? | 11:59 |
| gf712 | the idea is to separate all the low level stuff from the ML algorithm implementations | 11:59 |
| @HeikoS | lisitsyn I have the feeling it would be good design wise to separate the interface code from the c++ code | 11:59 |
| @HeikoS | since it would make a few things much more clear | 11:59 |
| @HeikoS | see the latest pipeline problems | 11:59 |
| @HeikoS | they have a neat c++ api which is typed and good | 11:59 |
| lisitsyn | I don't know about pipeline problems | 12:00 |
| @HeikoS | there is a pr | 12:00 |
| @HeikoS | but generally it is just to make it a bit more neat | 12:00 |
| lisitsyn | checking | 12:00 |
| @HeikoS | lisitsyn I feel sometimes there is a risk of imposing questionable design into the libshogun code just because of the interfaces | 12:01 |
| lisitsyn | uhm can't see | 12:01 |
| lisitsyn | HeikoS: well C++ should target for tag-based/typed and others should target string-based | 12:01 |
| lisitsyn | that's I agree | 12:01 |
| @HeikoS | so I guess my motivation comes from looking at the cpp meta examples and the fact that they dont really look like c++ | 12:02 |
| @HeikoS | so I am like, why not accept that it will be a different API | 12:02 |
| lisitsyn | HeikoS: I have a thought that | 12:03 |
| @HeikoS | and then, why would we need all the code to make the swig examples work in libshogun | 12:03 |
| lisitsyn | it would be good to still have it | 12:03 |
| lisitsyn | but also try to develop more typed one | 12:03 |
| lisitsyn | in parallel | 12:03 |
| @HeikoS | what is "a typed one" | 12:03 |
| lisitsyn | e.g. develop an interface without factories | 12:03 |
| lisitsyn | then with tags instead of strings | 12:03 |
| @HeikoS | yes this is kind of what I mean | 12:03 |
| @HeikoS | that interface is there right? | 12:03 |
| @HeikoS | we have it | 12:03 |
| lisitsyn | yeah but I don't have a feeling that you need to drop anything to do that | 12:04 |
| @HeikoS | just a matter of keeping things tidy: code that is not part of c++ api can go to swig interface | 12:04 |
| @HeikoS | then there is no risk of convoluting libshogun | 12:04 |
| @HeikoS | gf712 shall I merge? | 12:05 |
| gf712 | HeikoS just need to fix the push_bask | 12:06 |
| @HeikoS | ok I will wait | 12:06 |
| gf712 | does it mater where the doxygen string is btw? | 12:06 |
| @HeikoS | no it doesnt | 12:06 |
| gf712 | ok, cool | 12:06 |
| @HeikoS | sorry I didnt hit reply | 12:06 |
| gf712 | btw unrelated | 12:06 |
| gf712 | but would it be possible to get a version string for python API | 12:07 |
| gf712 | like in conda there is version 6.1.3 | 12:07 |
| lisitsyn | HeikoS: can you show me an example of non-cpp api? I am checking now and it looks more or less good | 12:07 |
| @HeikoS | like this stuff | 12:09 |
| @HeikoS | 28 auto d = wrap(distance("EuclideanDistance")); 29 d->put("lhs", features_train); | 12:09 |
| @HeikoS | gf712 what do you mean? | 12:09 |
| gf712 | HeikoS sg.__version___ | 12:09 |
| gf712 | It is needed for openml | 12:09 |
| @HeikoS | gf712 ah I see | 12:09 |
| @HeikoS | gf712 I think we have that somewhere | 12:09 |
| lisitsyn | HeikoS: a small step would be to make it | 12:10 |
| @HeikoS | gf712 Version.h | 12:10 |
| lisitsyn | d->put(Tag<decltype(features_train)>("lhs"), features_train); | 12:10 |
| gf712 | HeikoS yup, but I don't think there is a way to get MAINVERSION | 12:10 |
| lisitsyn | then gradually make it | 12:10 |
| @HeikoS | lisitsyn that we can do now already :D | 12:10 |
| gf712 | which is what is used in the conda versioning | 12:10 |
| gf712 | I think? | 12:10 |
| @HeikoS | gf712 we can modify the current mechanism? | 12:10 |
| @HeikoS | lisitsyn the enums are another issue | 12:11 |
| lisitsyn | somehow make it "d->put(Tags::lhs, features_train);" or whatever like that | 12:11 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Remote host closed the connection] | 12:11 | |
| @HeikoS | lisitsynwell the problem is that then we need to change the meta example language | 12:11 |
| lisitsyn | HeikoS: one easy thing would be to pollute some auxillary namespace with all possible tags | 12:11 |
| @HeikoS | as it is | 12:11 |
| @HeikoS | Distance d = distance("EuclideanDistance", lhs=features_train, rhs=features_train) | 12:11 |
| gf712 | HeikoS cool, I can do that, just wanteed to ask if that's fine | 12:11 |
| @HeikoS | gf712 sure do it :) | 12:12 |
| @HeikoS | lisitsyn all good ideas | 12:12 |
| lisitsyn | HeikoS: shogun::tag::<every possible parameter> | 12:12 |
| @HeikoS | lisitsyn this breaks the cpp meta examples | 12:12 |
| lisitsyn | no, why? | 12:12 |
| @HeikoS | because mapping from the example.sg file to the cpp output is hard | 12:13 |
| @HeikoS | we dont have typed put calls in there | 12:13 |
| lisitsyn | HeikoS: you just drop the "" | 12:13 |
| lisitsyn | "something" becomes tag::something | 12:13 |
| @HeikoS | can you elaborate? | 12:13 |
| lisitsyn | the hardest part is to create such a .h with tags | 12:13 |
| lisitsyn | HeikoS: you can easily replace all the strings with tags | 12:14 |
| lisitsyn | we just have to declare them somehow | 12:14 |
| lisitsyn | this would become more C++y | 12:14 |
| @HeikoS | I am not that sure | 12:14 |
| @HeikoS | because there we are making another weird construct to unify things | 12:14 |
| @HeikoS | why not just go with the normal c++ way | 12:14 |
| lisitsyn | that's the normal C++ way | 12:15 |
| @HeikoS | that | 12:15 |
| lisitsyn | :) | 12:15 |
| @HeikoS | a list with all possible tags? | 12:15 |
| lisitsyn | no | 12:15 |
| @HeikoS | generated by a python script? :D | 12:15 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 12:15 | |
| lisitsyn | it is a step before we have plugins | 12:15 |
| lisitsyn | then this tags would go to the plugin header | 12:15 |
| lisitsyn | but before we have that we have a giant plugin (shogun itself) | 12:15 |
| lisitsyn | that's the point | 12:15 |
| lisitsyn | the conversion to plugins would be much easier then | 12:15 |
| @HeikoS | sure | 12:15 |
| @HeikoS | ok the other thing that is an example are enums | 12:16 |
| @HeikoS | in swig these are ints | 12:16 |
| lisitsyn | yes? | 12:16 |
| @HeikoS | wouldnt it be nice to have them typesafe in c++? | 12:16 |
| lisitsyn | oh that's really minor, isn't it ? | 12:17 |
| lisitsyn | :) | 12:17 |
| @HeikoS | it is | 12:17 |
| @HeikoS | just adds to the list | 12:17 |
| @HeikoS | just like "wrap" | 12:17 |
| @HeikoS | and the factory | 12:18 |
| @HeikoS | instead of some and ctor | 12:18 |
| lisitsyn | well we basically need to convert T("name") to some<T>() | 12:18 |
| @HeikoS | lisitsyn just to clarify what you meant above | 12:18 |
| @HeikoS | lisitsyn mmh that seems almost possbible to do now or? | 12:19 |
| lisitsyn | HeikoS: just needs proper header to include | 12:19 |
| lisitsyn | I don't know how to detect that | 12:20 |
| @HeikoS | we have the ctags for that no? | 12:20 |
| lisitsyn | yes if you know how that's nice | 12:20 |
| @HeikoS | so questions | 12:20 |
| @HeikoS | Distance d = distance("EuclideanDistance", lhs=features_train, rhs=features_train) | 12:20 |
| @HeikoS | we have this | 12:20 |
| lisitsyn | ok you detect the header | 12:21 |
| lisitsyn | include it | 12:21 |
| lisitsyn | then do auto d = some<EuclideanDistance>(); | 12:21 |
| @HeikoS | which becomes | 12:21 |
| @HeikoS | 28 auto d = wrap(distance("EuclideanDistance")); 29 d->put("lhs", features_train); 30 d->put("rhs", features_train); | 12:21 |
| @HeikoS | we make it | 12:21 |
| @HeikoS | some<EuclideanDistance>() | 12:21 |
| @HeikoS | and then | 12:21 |
| lisitsyn | auto lhs_tag = Tag<decltype(features_train)>("lhs"); | 12:21 |
| lisitsyn | d->put(lhs_tag, features_train); | 12:22 |
| lisitsyn | then gradually we move lhs_tag away somehow | 12:22 |
| @HeikoS | let me try that | 12:22 |
| @HeikoS | just now | 12:22 |
| lisitsyn | okay (shrug) :) | 12:22 |
| @HeikoS | ah | 12:22 |
| @HeikoS | no | 12:22 |
| @HeikoS | "Init": { "Construct": "auto $name = some<C$typeName>($arguments)$kwargs", "Copy": "auto $name = wrap($expr)$kwargs", | 12:23 |
| @HeikoS | we are using some already for ctor | 12:23 |
| @HeikoS | but since all is factory | 12:23 |
| @HeikoS | we have this "wrap" for all copy asignments | 12:23 |
| lisitsyn | wrap is some hack I don't remember what for | 12:23 |
| @HeikoS | which covers both factory and CFeatures::apply | 12:23 |
| lisitsyn | somebody would fix it some day I believe | 12:23 |
| @HeikoS | to put raw pointers into Some | 12:23 |
| @HeikoS | how? | 12:24 |
| @HeikoS | CLabels* CFeatures::apply | 12:24 |
| @HeikoS | raw pointer | 12:24 |
| lisitsyn | ah | 12:24 |
| lisitsyn | we get rid of pointers | 12:24 |
| lisitsyn | this is how | 12:24 |
| lisitsyn | :D | 12:24 |
| lisitsyn | ahhh ok | 12:24 |
| lisitsyn | we need to make the great transition | 12:24 |
| lisitsyn | tough thing | 12:24 |
| @HeikoS | hehe | 12:24 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Remote host closed the connection] | 12:24 | |
| @HeikoS | ok I will try the put instead | 12:24 |
| lisitsyn | tags is something doable I believe | 12:25 |
| lisitsyn | it would crash if we put it two times though | 12:25 |
| lisitsyn | you'd declare the tag twice | 12:26 |
| @HeikoS | give me a one liner | 12:26 |
| lisitsyn | HeikoS: give you what? | 12:26 |
| @HeikoS | for the put | 12:26 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 12:27 | |
| lisitsyn | it is just the same | 12:27 |
| lisitsyn | eh? | 12:27 |
| lisitsyn | d->put(Tag<decltype($value)>($name), $value); | 12:27 |
| lisitsyn | something like that | 12:27 |
| lisitsyn | HeikoS: ^? | 12:28 |
| @HeikoS | trying | 12:29 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Remote host closed the connection] | 12:31 | |
| @HeikoS | 35 kmeans->put(Tag<decltype<2>("k")>, 2); 36 kmeans->put(Tag<decltype<d>("distance")>, d); | 12:32 |
| lisitsyn | HeikoS: oops | 12:36 |
| lisitsyn | decltype<2> | 12:36 |
| lisitsyn | :) | 12:36 |
| lisitsyn | does it work? | 12:36 |
| @HeikoS | 29 d->put(Tag<decltype(features_train)>("lhs")>, features_train); 30 d->put(Tag<decltype(features_train)>("rhs")>, features_train); | 12:37 |
| @HeikoS | yeah was playing with the meta generator | 12:37 |
| @HeikoS | still not | 12:37 |
| lisitsyn | doesn't work? what fails? | 12:37 |
| lisitsyn | ah | 12:38 |
| lisitsyn | you forgot () | 12:38 |
| lisitsyn | create tag | 12:38 |
| lisitsyn | HeikoS: is it possible to put the definitions of those tags to the beginning of the snippet? | 12:39 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/pull/4483 | 12:39 |
| @HeikoS | does this have the double tag problem? | 12:40 |
| @HeikoS | it compiles | 12:40 |
| lisitsyn | HeikoS: what's the double tag problem? | 12:40 |
| @HeikoS | you said something above | 12:40 |
| lisitsyn | HeikoS: ah this one doesn't | 12:40 |
| @HeikoS | ah | 12:40 |
| @HeikoS | nice runtime error | 12:40 |
| @HeikoS | old problem | 12:40 |
| @HeikoS | once again meta cpp | 12:40 |
| @HeikoS | Some | 12:40 |
| @HeikoS | and put | 12:40 |
| @HeikoS | ah wait I know how to fix | 12:40 |
| lisitsyn | eh? | 12:40 |
| @HeikoS | 182: [ERROR] In file /home/heiko/git/shogun/src/shogun/base/SGObject.h line 366: Cannot put parameter EuclideanDistance::lhs of type shogun::CFeatures*, incompatible provided type shogun::Some<shogun::CFeatures>. | 12:41 |
| lisitsyn | ah ok | 12:41 |
| lisitsyn | HeikoS: I don't know how to fix that :) | 12:42 |
| lisitsyn | do you? | 12:42 |
| @HeikoS | yes | 12:42 |
| @HeikoS | overload put | 12:43 |
| @HeikoS | for Some | 12:43 |
| @HeikoS | hide it from swig | 12:43 |
| @HeikoS | I did that for the put by name already | 12:43 |
| @HeikoS | but put by name can be moved to swig c++ | 12:43 |
| @HeikoS | so adding anotoher one | 12:43 |
| lisitsyn | oh | 12:44 |
| @HeikoS | Let's see what the CI says | 12:46 |
| @HeikoS | thanks for the discussion! | 12:46 |
| lisitsyn | HeikoS: wilkommen :) | 12:47 |
| lisitsyn | HeikoS: ah you can also do the same with get | 12:49 |
| lisitsyn | kmeans->get<SGMatrix<float64_t>>("cluster_centers") | 12:50 |
| lisitsyn | kmeans->get(Tag<SGMatrix<float64_t>>("cluster_centers")) | 12:50 |
| @HeikoS | but why? | 12:50 |
| lisitsyn | just the same reason | 12:50 |
| @HeikoS | already typed or? | 12:50 |
| lisitsyn | to prepare for the transition | 12:50 |
| @HeikoS | but here get is a template | 12:50 |
| @HeikoS | i dont see a difference between get<> and get(Tag<> | 12:51 |
| lisitsyn | HeikoS: I believe the next step is to move all the Tag<...> to the top of the script | 12:51 |
| @HeikoS | That will be tricky | 12:51 |
| @HeikoS | although | 12:51 |
| lisitsyn | HeikoS: some postprocessing | 12:51 |
| @HeikoS | maybe not | 12:51 |
| lisitsyn | HeikoS: perfect would be to declare a namespace in the beginning | 12:52 |
| lisitsyn | namespace tags { ... } | 12:52 |
| lisitsyn | and then put them there | 12:52 |
| @HeikoS | lisitsyn oh one thing | 12:54 |
| @HeikoS | Pipeline basically has the problem | 12:54 |
| @HeikoS | together with xvalidation | 12:54 |
| @HeikoS | that xvalidation has a member of type CMachine | 12:55 |
| @HeikoS | and Pipeline inherits from machine | 12:55 |
| @HeikoS | so we would like to "put" a pipeline | 12:55 |
| @HeikoS | but that doesnt work with tags | 12:55 |
| @HeikoS | you can only put a CMachine | 12:55 |
| @HeikoS | lisitsyn no subclasses allowed | 12:55 |
| @HeikoS | lisitsyn solutions? we thought about doing that via c++ api (factory that accepts Pipeline and then casts or so) | 12:56 |
| @HeikoS | I gotta go | 12:56 |
| @HeikoS | but maybe talk to wuwei[m] about this | 12:56 |
| lisitsyn | HeikoS: uhm no solution so far | 12:56 |
| @HeikoS | would be good to have that sorted | 12:56 |
| @HeikoS | ok see you | 12:56 |
| @HeikoS | ?????? | 12:57 |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 12:59 | |
| -!- wiking__ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has joined #shogun | 13:14 | |
| -!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Read error: Connection reset by peer] | 13:15 | |
| -!- HeikoS [5aae0441@gateway/web/cgi-irc/kiwiirc.com/ip.90.174.4.65] has quit [Ping timeout: 240 seconds] | 13:19 | |
| lisitsyn | oh I was scaried with that word haha | 13:21 |
| -!- wiking__ is now known as wiking_ | 14:00 | |
| -!- wiking_ is now known as wiking | 14:01 | |
| -!- wiking [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Changing host] | 14:01 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 14:01 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 14:01 | |
| @wiking | mmm i needed to ghost the guy | 14:01 |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 14:08 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 14:09 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 14:09 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 14:09 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 14:12 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 14:12 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 268 seconds] | 14:17 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 14:28 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 14:28 | |
| gf712 | wiking: hey | 14:50 |
| @wiking | gf712: hey | 14:51 |
| gf712 | I have a question about openml | 14:51 |
| gf712 | do you know how openml uses the 'oml-python:serialized_object' entries internally? | 14:51 |
| gf712 | I am not sure if it something do just help serialising/deserialising | 14:52 |
| gf712 | to* | 14:52 |
| gf712 | or if the server actually uses this information in the flows? | 14:52 |
| gf712 | for example here https://github.com/openml/openml-python/blob/7a612eaece2fd28315d99dda3e2393ada2f27478/openml/flows/sklearn_converter.py#L501 | 14:55 |
| @wiking | mmm | 14:57 |
| @wiking | in case of sklearn that's a pickle file or what? | 14:57 |
| @wiking | no it's 'function' | 14:58 |
| @wiking | i mean i think there's no real object ever | 14:58 |
| @wiking | serialized | 14:58 |
| @wiking | it's only the 'flow' | 14:58 |
| gf712 | in the case of pipelines it creates {'oml-python:serialized_object':"component_reference"} | 14:58 |
| gf712 | ah ok | 14:58 |
| @wiking | which is just a bunch of metadata | 14:58 |
| @wiking | of the objects | 14:58 |
| gf712 | so it's probably just a helper to get an object from flow | 14:58 |
| @wiking | yes | 14:59 |
| gf712 | OK cool! thanks | 14:59 |
| @wiking | gf712: what would you use for a std::map<std::set<>, std::function> | 14:59 |
| @wiking | this? | 14:59 |
| @wiking | or you have a better idea? | 14:59 |
| @wiking | apart from using unordered version ;) | 15:00 |
| gf712 | in which situation are you using it? | 15:00 |
| @wiking | ah yeah set = std::set<std::string> | 15:02 |
| @wiking | so bascially i have 1 function for the same bunch of strings | 15:02 |
| @wiking | gf712: this is in re how to identify machines and export them to coreml | 15:02 |
| gf712 | so the function has nothing bound right? | 15:03 |
| @wiking | that's just the function that does the converting | 15:03 |
| gf712 | ah ok, I think I would do that | 15:03 |
| @wiking | only thing is that there's not better way to do this dispatching | 15:04 |
| gf712 | std::function<T(std::string)> no? | 15:04 |
| gf712 | or whatever the signature is | 15:04 |
| @wiking | std::function<T(CMachine*)> | 15:05 |
| @wiking | but yeah | 15:05 |
| gf712 | otherwise you could do SFINAE and create custom structs to call the right function? | 15:08 |
| gf712 | not sure if that is any better though | 15:08 |
| @wiking | yeah that might look ugly | 15:09 |
| @wiking | :) | 15:09 |
| gf712 | but that woudn't work with std::string anyway | 15:10 |
| gf712 | would have to use something compile time | 15:10 |
| gf712 | anyway, yup the map works well | 15:10 |
| gf712 | feels pythonic | 15:10 |
| wuwei[m] | hi, I added a new factory but I got "splitting_strategy() takes no keyword arguments", anyone knows what I missed? | 16:37 |
| @wiking | damn | 16:37 |
| @wiking | a static variable cannot be assigned by a lambda expression | 16:37 |
| @wiking | ? | 16:37 |
| @wiking | anybody knows why this isn't evaluated https://pastebin.com/ZuYBc7vT | 16:38 |
| @wiking | ? | 16:38 |
| @wiking | if i call this macro as if it doesn't do anything | 16:39 |
| wuwei[m] | what's the rhs? a lambda? but the lhs is a bool | 16:41 |
| wuwei[m] | maybe you should add () at the end | 16:41 |
| @wiking | noup :( | 16:42 |
| @wiking | didn't help | 16:42 |
| @wiking | apparently https://stackoverflow.com/questions/15581662/is-it-possible-to-initialize-static-variable-with-lambda | 16:43 |
| @wiking | should do it what u said wuwei[m] | 16:43 |
| gf712 | are you trying to store the lambda or the result of it? | 16:44 |
| @wiking | i just need to call the lambda | 16:44 |
| @wiking | dont care about it's result | 16:45 |
| @wiking | as u see its just a placeholder | 16:45 |
| @wiking | :) | 16:45 |
| @wiking | but i wanna init that variable on load time | 16:45 |
| @wiking | of the lib | 16:45 |
| @wiking | funny | 16:46 |
| @wiking | if i export this as a shared lib | 16:46 |
| @wiking | then it works | 16:46 |
| @wiking | mmmm i guess maybe the static vars are being optimized out if its a static lib | 16:46 |
| @wiking | since they are not used? | 16:46 |
| gf712 | it seems like it | 16:49 |
| gf712 | tried it on compiler explorer | 16:50 |
| gf712 | and when you use optimiser the static disappears | 16:50 |
| gf712 | when it isn't used | 16:50 |
| gf712 | something like this https://godbolt.org/z/ArKqDY | 16:53 |
| gf712 | doesn't compile result when O3 but does on O0, when you remove static it gets compiled either way | 16:54 |
| gf712 | is that what you mean? | 16:54 |
| @wiking | yeah | 16:55 |
| @wiking | now if i use shared lib things getting better | 16:55 |
| @wiking | buuuut | 16:55 |
| @wiking | so actually the lambda is being evaluated | 16:55 |
| @wiking | but somehow when i fill up that static hashmap | 16:55 |
| @wiking | it's as if didn't happen | 16:55 |
| gf712 | are you doing that in c++14 or 17? | 16:56 |
| @wiking | 14 atm | 16:57 |
| @wiking | its weird | 17:00 |
| @wiking | that's a static var | 17:00 |
| @wiking | if i change content | 17:01 |
| @wiking | then it should remain like that | 17:01 |
| @wiking | :) | 17:01 |
| gf712 | do you capture &kConverters? | 17:02 |
| @wiking | gf712: shoudln't need to capture it | 17:03 |
| @wiking | as its a static | 17:03 |
| @wiking | but i've tried passing the static var as an arg of the lambda | 17:04 |
| @wiking | same result | 17:04 |
| @wiking | gf712: here? | 17:56 |
| @wiking | lisitsyn: here? | 17:57 |
| @wiking | is there any particular reason why this is not a const | 17:59 |
| @wiking | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/base/SGObject.h#L447 | 17:59 |
| @wiking | ? | 17:59 |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 18:04 | |
| gf712 | not anymore I think? it was changing self->map before (bug), but not it isnt so should be const | 18:07 |
| gf712 | now* | 18:07 |
| -!- gf712 [8028b333@gateway/web/freenode/ip.128.40.179.51] has quit [Quit: Page closed] | 18:15 | |
| -!- shubham808 [~atom@14.139.240.247] has joined #shogun | 18:19 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 18:41 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 18:41 | |
| @wiking | lisitsyn: around? | 20:33 |
| lisitsyn | wiking: hey | 20:33 |
| @wiking | ok so do you know why this is not const | 20:33 |
| @wiking | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/base/SGObject.h#L447 | 20:33 |
| @wiking | and the other question | 20:33 |
| @wiking | if i just create an empty CLibSVM | 20:33 |
| @wiking | and i do | 20:33 |
| @wiking | c->get("kernel") | 20:34 |
| @wiking | should it return anything or throw exception? | 20:34 |
| @wiking | btw its a magical exercise to try to work with a const CMachine* and use its getters | 20:34 |
| @wiking | :D | 20:34 |
| @wiking | everything screams | 20:35 |
| lisitsyn | wiking: I think if you make it const and it works | 20:35 |
| lisitsyn | then you should make it const :) | 20:35 |
| @wiking | yeah i made it | 20:35 |
| @wiking | i ust wondered if there's special reason | 20:35 |
| lisitsyn | I don't know any | 20:35 |
| @wiking | but still get("kernel") | 20:35 |
| @wiking | libc++abi.dylib: terminating with uncaught exception of type shogun::ShogunException: [ERROR] In file /Users/wiking/shogun/src/shogun/base/SGObject.cpp line 1075: Cannot get parameter LibSVM::kernel of type shogun::CKernel* as object, not object type. | 20:36 |
| @wiking | but i guess its because i'm calling this on an empty CLibSVM | 20:36 |
| @wiking | yep yepo it was only that | 20:37 |
| @wiking | :) | 20:37 |
| @wiking | lisitsyn: https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/kernel/Kernel.h#L52 | 20:38 |
| @wiking | this as well is > /dev/null | 20:38 |
| lisitsyn | oh yes please :) | 20:38 |
| -!- shubham808 [~atom@14.139.240.247] has quit [Quit: Leaving.] | 21:47 | |
| @wiking | lisitsyn: asdf | 21:57 |
| @wiking | :) | 21:57 |
| @wiking | i think our polynomial kernel is rather simple :) | 21:57 |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 22:31 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 22:38 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 22:38 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 246 seconds] | 22:42 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 22:51 | |
| -!- mode/#shogun [+o wiking] by ChanServ | 22:51 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 23:46 | |
| --- Log closed Fri Jan 25 00:00:42 2019 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!