--- Log opened Thu Jan 31 00:00:51 2019 | ||
-!- wiking_ [~wiking@c-185-45-237-122.customer.ggaweb.ch] has quit [Remote host closed the connection] | 00:15 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 00:46 | |
-!- mode/#shogun [+o wiking] by ChanServ | 00:46 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 03:31 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 04:01 | |
-!- mode/#shogun [+o wiking] by ChanServ | 04:01 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 240 seconds] | 04:05 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 04:37 | |
-!- mode/#shogun [+o wiking] by ChanServ | 04:37 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 240 seconds] | 07:22 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 08:07 | |
-!- mode/#shogun [+o wiking] by ChanServ | 08:07 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 08:16 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 08:33 | |
-!- mode/#shogun [+o wiking] by ChanServ | 08:33 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 250 seconds] | 08:41 | |
-!- gf712 [90520834@gateway/web/freenode/ip.144.82.8.52] has joined #shogun | 08:51 | |
-shogun-buildbot:#shogun- Build nightly_default #203 is complete: Failure [failed test (failure)] - http://buildbot.shogun-toolbox.org:8080/#builders/17/builds/203 | 08:59 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 09:05 | |
-!- mode/#shogun [+o wiking] by ChanServ | 09:05 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Client Quit] | 09:09 | |
-!- Lefteris [836fb90d@gateway/web/freenode/ip.131.111.185.13] has joined #shogun | 11:22 | |
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has joined #shogun | 11:52 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 11:52 | |
@HeikoS | wuwei[m] I will merge now, ok? :) | 11:52 |
---|---|---|
wuwei[m] | sure | 11:53 |
@HeikoS | well done on that one, it was a beast | 11:54 |
@HeikoS | tada :) | 11:56 |
-!- gf712 [90520834@gateway/web/freenode/ip.144.82.8.52] has quit [Ping timeout: 256 seconds] | 11:56 | |
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has quit [Ping timeout: 246 seconds] | 12:11 | |
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has joined #shogun | 12:37 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 12:37 | |
lisitsyn | HeikoS: hey | 12:38 |
lisitsyn | I was thinking in background | 12:39 |
@HeikoS | jo | 12:39 |
@HeikoS | lisitsyn and? | 12:39 |
lisitsyn | it should be doable | 12:39 |
@HeikoS | i wonder how we can do this without refactoring all the enum interfaces | 12:40 |
@HeikoS | and the machine_int registration of those | 12:40 |
@HeikoS | sure we can change all the enum types | 12:40 |
@HeikoS | but that seems suicidal to me | 12:40 |
@HeikoS | what would be ok would be to somehow change definitions only | 12:41 |
@HeikoS | and keep all the interfaces the same | 12:41 |
@HeikoS | and the new definition can be instantiate from string | 12:41 |
@HeikoS | lisitsyn how would you do it? | 12:41 |
@HeikoS | lisitsyn and? | 12:55 |
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has quit [Ping timeout: 250 seconds] | 13:54 | |
-!- gf712 [90520834@gateway/web/freenode/ip.144.82.8.52] has joined #shogun | 14:01 | |
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has joined #shogun | 14:01 | |
HeikoS | gf712 yo! how is the python script for extracting model stuff coming along btw? | 14:17 |
gf712 | HeikoS: It can serialise | 14:18 |
gf712 | working on deserialising now | 14:18 |
HeikoS | great | 14:18 |
HeikoS | is there anything to look at? | 14:18 |
gf712 | went a bit offtrack this week but I'll aim to finish it by tomorrow? | 14:18 |
gf712 | yup, I forked the project and worked on victors branch | 14:19 |
gf712 | viktor's | 14:19 |
gf712 | let me find it | 14:19 |
gf712 | https://github.com/gf712/openml-python/tree/shogun_converter | 14:20 |
gf712 | if you setup it up you should be able to pass an svm with a kernel | 14:21 |
gf712 | with the latest shogun version | 14:21 |
gf712 | still need to add support for other nested objects, i.e. distance | 14:21 |
gf712 | and then need to look at pipeline | 14:21 |
gf712 | I was wondering how I can detect a SGobject that needs to be serialised, i.e. distance and kernel | 14:22 |
gf712 | right now I check if an object is of type "CKernel*" for example | 14:23 |
HeikoS | get_name should do it I think | 14:31 |
HeikoS | wait not sure i understand | 14:32 |
gf712 | let's say you have a svm | 14:32 |
gf712 | and it has a kernel | 14:32 |
gf712 | you need to serialise the svm and the kernel within it | 14:33 |
gf712 | so when you query the type of each param you can check if it is a "non primitive" type | 14:33 |
gf712 | for example the kernel param is of type CKernel* I think | 14:33 |
HeikoS | any sgobject needs to be serialized right? | 14:33 |
HeikoS | every | 14:34 |
gf712 | but not all can be | 14:34 |
HeikoS | like? | 14:34 |
gf712 | because there isn't a getter for it | 14:34 |
gf712 | hmm one thing I can come up with right now would be a bool | 14:34 |
-!- mode/#shogun [+o HeikoS] by ChanServ | 14:34 | |
gf712 | not a sgobject | 14:34 |
gf712 | but as an illustration | 14:34 |
@HeikoS | no but I mean any instance of CSGObject should be serialized | 14:34 |
@HeikoS | bool is not sgobject | 14:34 |
gf712 | svm=sg.machine("SVM", kernel=sg.kernel("GaussianKernel")) | 14:35 |
gf712 | svm.get("custom_kernel") | 14:35 |
gf712 | The current Python API does not have a getter for 'custom_kernel' of type 'shogun::CSGObject*' | 14:36 |
@HeikoS | kernel(svm.get("custom_kernel")) | 14:36 |
@HeikoS | btw the custom kernel field should not be exported anyways imo as it is a computational tool | 14:36 |
gf712 | ah ok | 14:37 |
@HeikoS | doesnt that work? using the kernel factory? | 14:37 |
@HeikoS | I think we should name those "as_kernel" | 14:37 |
gf712 | it was more of an example, could even be kernel | 14:37 |
gf712 | if no kernel is defined | 14:37 |
@HeikoS | as_BASETYPE basically for every of those defined in factory.h | 14:37 |
gf712 | svm=sg.machine("SVM") | 14:37 |
gf712 | svm.get("kernel") | 14:37 |
gf712 | ValueError: The current Python API does not have a getter for 'kernel' of type 'shogun::CKernel*' | 14:37 |
gf712 | I can just add a try catch | 14:37 |
@HeikoS | is that what happens now? | 14:38 |
gf712 | ah ok! good to know | 14:38 |
@HeikoS | gf712 I vaguely remember that get return CSGObject pointer by default | 14:39 |
@HeikoS | let me check that | 14:39 |
@HeikoS | ah ok on | 14:39 |
@HeikoS | it doesnt | 14:39 |
gf712 | so basically I need to iterate over params | 14:39 |
@HeikoS | so CSGObject is not a base type that can be retrieved using get | 14:39 |
gf712 | and get a type that I can serialise | 14:39 |
@HeikoS | ok i see | 14:40 |
gf712 | i.e. kernel I can serialise by keeping the name | 14:40 |
@HeikoS | what about this: | 14:40 |
@HeikoS | we add a method in the get | 14:40 |
gf712 | and then to serialise you can do sg.TYPE(params) | 14:40 |
gf712 | deserialise* | 14:40 |
@HeikoS | mmh | 14:40 |
@HeikoS | i am confused now | 14:40 |
@HeikoS | so let's stay with kernel | 14:41 |
@HeikoS | so you iterate over parameter names | 14:41 |
@HeikoS | and some of those correspond to a CSGObject parameter | 14:41 |
gf712 | yes | 14:41 |
gf712 | such as a kernel | 14:41 |
@HeikoS | but curently, there is only getters for specific classes, like kernel | 14:41 |
@HeikoS | so you would have to try all of those | 14:41 |
@HeikoS | for all shogun base types, you would have to try getting them | 14:41 |
gf712 | yes | 14:42 |
@HeikoS | and if any of those work, then you know that you have a serializable parameter | 14:42 |
@HeikoS | that sucks | 14:42 |
gf712 | so I need some list to keep track of what is available | 14:42 |
@HeikoS | what about we move this to c++ code inside swig? | 14:42 |
gf712 | for example in the svm svm.parameter_type('kernel') | 14:42 |
@HeikoS | like add a method | 14:42 |
@HeikoS | get(std::string) | 14:42 |
@HeikoS | CSGObject* get(std::string) | 14:42 |
@HeikoS | and this one tries all the base class getters | 14:42 |
@HeikoS | and then returns a casted version | 14:43 |
@HeikoS | and then swig wraps that | 14:43 |
@HeikoS | good thing is you could auto generate the trying all cases using the shogun base types structure | 14:43 |
@HeikoS | ah | 14:43 |
gf712 | I think that can all be done in python no? | 14:44 |
@HeikoS | and then you could also offer a method that gets all parameter names of CSGobjects, or even better a bool whether a given parameter is an object | 14:44 |
gf712 | ah the latter would be useful I think | 14:44 |
gf712 | let me think | 14:44 |
@HeikoS | well but if you do it in Python then it only works for Python, and also you cannot use the c++ base types to make it maintainable | 14:44 |
@HeikoS | a random list of python things somewhere in the code is not ideal, we keep adding base types (see my current PRs) | 14:45 |
gf712 | true | 14:45 |
gf712 | that was my original concern | 14:45 |
gf712 | but I was thinking now | 14:45 |
gf712 | I could try and catch with get | 14:45 |
gf712 | and if get works check if the param is a python builtin, i.e. int | 14:45 |
gf712 | and if not I can keep the type and use that to keep the information to later deserialise | 14:46 |
gf712 | but yea, then I need a mapping | 14:46 |
gf712 | HeikoS what do you mean with "good thing is you could auto generate the trying all cases using the shogun base types structure"? | 14:47 |
@HeikoS | well in c++ we know all the base types that are available for put/get | 14:48 |
@HeikoS | since we have them in a trait | 14:48 |
@HeikoS | is_sg_base | 14:48 |
@HeikoS | put/get is only defined for those | 14:48 |
@HeikoS | so trying all the types in that trait will definitely work | 14:49 |
lisitsyn | HeikoS: I am thinking of renaming Any :) | 14:51 |
lisitsyn | it becomes Var :D | 14:51 |
@HeikoS | lisitsyn do it :D | 14:52 |
@HeikoS | but | 14:52 |
@HeikoS | enums! | 14:52 |
@HeikoS | :) | 14:52 |
lisitsyn | HeikoS: yeah that's why I thought of it | 14:52 |
lisitsyn | HeikoS: I am halfway done | 14:52 |
@HeikoS | cool! | 14:55 |
@HeikoS | looking forward to see it | 14:55 |
@HeikoS | lisitsyn question | 15:00 |
lisitsyn | yes? | 15:00 |
@HeikoS | shall we rather have CSVM* sg.svm(CSGObject), or CSV* sg.as_svm(CSGObject) or CSVM* CSGObject::as_svm | 15:00 |
lisitsyn | 1 or 2 | 15:01 |
@HeikoS | kk | 15:01 |
@HeikoS | thx :) | 15:01 |
@HeikoS | lisitsyn another q | 15:03 |
@HeikoS | so I have MKL class | 15:03 |
@HeikoS | has a member of type CSVM | 15:03 |
@HeikoS | now I wanna put that | 15:03 |
@HeikoS | currenty, put is only defined for CMachine | 15:04 |
@HeikoS | I could add sg.as_svm and define put for svm as well | 15:04 |
@HeikoS | but then | 15:04 |
@HeikoS | put cannot decide if I give an CSVM instance | 15:04 |
lisitsyn | why can't it? | 15:05 |
@HeikoS | what happens is that when I call mkl.put("svm", sg.as_svm(my_svm_machine)) | 15:07 |
@HeikoS | swig goes into put_machine | 15:07 |
@HeikoS | put<CMachine> | 15:07 |
@HeikoS | not into put<CSVM> | 15:07 |
@HeikoS | so I get an error | 15:07 |
@HeikoS | since sg.as_svm(my_svm_machine) *is* a machine | 15:07 |
lisitsyn | but why? | 15:08 |
lisitsyn | CMachine > CSGObject? | 15:08 |
lisitsyn | why the same thing does not happen to CMachine then/ | 15:09 |
@HeikoS | because there is no put for it | 15:09 |
@HeikoS | put is only defined for CMachine | 15:09 |
@HeikoS | not for SGObject | 15:09 |
@HeikoS | and it *does* happen | 15:09 |
@HeikoS | thats why we register ojects by their base lcass | 15:09 |
lisitsyn | HeikoS: actually swig is able to handle such things | 15:09 |
@HeikoS | not by sgobject | 15:09 |
@HeikoS | let me show you | 15:09 |
lisitsyn | HeikoS: I mean overloading works | 15:10 |
lisitsyn | it might be broken due to something | 15:10 |
lisitsyn | but it should work | 15:10 |
@HeikoS | I think i know what happens....meeeh | 15:13 |
@HeikoS | ok anyway | 15:13 |
@HeikoS | why Var? :) | 15:13 |
lisitsyn | HeikoS: it becomes more than any | 15:16 |
lisitsyn | and we can't replace it | 15:16 |
lisitsyn | the more we add | 15:16 |
lisitsyn | gets really complicated | 15:17 |
@HeikoS | i see | 15:18 |
lisitsyn | HeikoS: the functional part is really crazy | 15:24 |
lisitsyn | :D | 15:24 |
lisitsyn | I am surprised I carried that | 15:25 |
@HeikoS | lol indeed | 15:26 |
@HeikoS | well growing | 15:26 |
@HeikoS | it wasnt designed that way | 15:26 |
lisitsyn | HeikoS: well | 15:52 |
lisitsyn | it solved many problems so it is a good thing | 15:52 |
@HeikoS | i guess :) | 15:52 |
lisitsyn | you can't build the same behaviour out of std:: things | 15:52 |
lisitsyn | if we were rebuilding the whole thing it could be | 15:53 |
lisitsyn | HeikoS: ah I lack constexpr-if so much | 15:53 |
@HeikoS | ehehe | 15:53 |
@HeikoS | gf712 is the master here :) | 15:53 |
lisitsyn | I can't use it so I still rely on decltype things | 15:54 |
gf712 | HeikoS haha I just like the whole moving runtime things to compile time.. but it confuses me too | 15:56 |
gf712 | you're a master if you understand this https://www.youtube.com/watch?v=PJwd4JLYJJY&t=606s | 15:57 |
wuwei[m] | Heiko: hey | 16:08 |
lisitsyn | HeikoS: gf712: please check https://github.com/shogun-toolbox/shogun/pull/4500 | 16:20 |
lisitsyn | check the test first to understand what's happening | 16:20 |
lisitsyn | HeikoS: now someone has got to convert all the enums | 17:18 |
@HeikoS | lisitsyn maybe an example would be good? | 17:33 |
lisitsyn | HeikoS: sorry I've spent my borrowed time today :P | 17:33 |
lisitsyn | maybe tomorrow | 17:33 |
@HeikoS | sure :) | 17:33 |
@HeikoS | what you wanna convert the enum to? | 17:33 |
@HeikoS | the smart enum lib thingi? | 17:34 |
@HeikoS | or custom? | 17:34 |
lisitsyn | HeikoS: I think the best is to steal and adapt | 17:34 |
@HeikoS | alright | 17:40 |
@HeikoS | Ill leave that to you :) | 17:40 |
lisitsyn | HeikoS: do we merge the feature? | 17:42 |
@HeikoS | the from_string? | 17:42 |
lisitsyn | yes | 17:42 |
@HeikoS | lisitsyn I would not yet | 17:42 |
lisitsyn | HeikoS: but why? | 17:42 |
@HeikoS | only once we actually have something working from meta examples | 17:42 |
lisitsyn | it is complete :) | 17:42 |
@HeikoS | like using the liblinera enums from there | 17:42 |
@HeikoS | the reason is | 17:42 |
@HeikoS | that I see complications on the horizont with changing the enum types | 17:43 |
@HeikoS | so I would wait | 17:43 |
@HeikoS | because maybe the chain of changes doesnt work in the end | 17:43 |
@HeikoS | then we dont need the thingi | 17:43 |
@HeikoS | see what I mean? | 17:43 |
lisitsyn | HeikoS: well I'd keep it anyway | 17:44 |
@HeikoS | but if we don't use it? | 17:44 |
lisitsyn | meh | 17:44 |
@HeikoS | I mean no harm in leaving the Pr there and develop in it or? | 17:44 |
@HeikoS | I have no string feelings though, if you want to merged, do it ;) | 17:45 |
lisitsyn | The macro has a soft limit of 64 declared constants. | 17:46 |
lisitsyn | hmm | 17:46 |
@HeikoS | not good | 17:46 |
@HeikoS | ah | 17:46 |
@HeikoS | mmh | 17:46 |
@HeikoS | maybe not a problem | 17:46 |
@HeikoS | we wont do CT_LIBSVM with that | 17:46 |
lisitsyn | HeikoS: I am thinking of code gen :) | 17:49 |
@HeikoS | for what? | 17:51 |
lisitsyn | HeikoS: just like classlist | 17:53 |
@HeikoS | for what? | 17:53 |
lisitsyn | HeikoS: I'd go for that if you don't mind | 17:53 |
@HeikoS | for the enums? | 17:53 |
lisitsyn | HeikoS: fromstring | 17:53 |
lisitsyn | yes | 17:53 |
@HeikoS | but what about plugins? | 17:54 |
@HeikoS | shouldnt the enums be local to the class only | 17:54 |
lisitsyn | HeikoS: plugin can add these enums to the registry on load | 17:54 |
@HeikoS | if you do that, then why would we need strings at all? | 17:55 |
@HeikoS | or no | 17:55 |
@HeikoS | rather | 17:55 |
lisitsyn | HeikoS: because you can't modify the interface | 17:55 |
@HeikoS | so you maintain a dictionary or something of all possible enum types? | 17:56 |
@HeikoS | but globally | 17:56 |
lisitsyn | HeikoS: looks like | 17:56 |
lisitsyn | this is the least intrusive solution for now | 17:56 |
@HeikoS | how do you | 17:56 |
@HeikoS | well | 17:56 |
@HeikoS | do we want that? | 17:56 |
@HeikoS | or do we want something nice? | 17:56 |
lisitsyn | what's nicer? | 17:56 |
lisitsyn | its all pretty trciky | 17:57 |
@HeikoS | I am not sure, but I am just saying that least intrusive is maybe not th best criterion to use | 17:58 |
@HeikoS | and a global list also seems weird to me | 17:58 |
@HeikoS | rather make shogun enums have the from string inbuilt | 17:58 |
lisitsyn | HeikoS: it is basically impossible :) | 17:58 |
lisitsyn | the thing is that we either stop treating them as ints | 17:58 |
lisitsyn | ooor I don't know | 17:58 |
lisitsyn | I mean that better enum is actually something that's a class | 17:59 |
@HeikoS | yes | 17:59 |
@HeikoS | Like some parameter class | 17:59 |
@HeikoS | defined via a macro that generates the from string method | 18:00 |
lisitsyn | HeikoS: very tricky things | 18:00 |
@HeikoS | so ok, how does it work with the global list | 18:00 |
lisitsyn | ok I'll think about it | 18:00 |
@HeikoS | especially how to instantiate enum whose enum type is unknown at compile time | 18:01 |
lisitsyn | HeikoS: I don't think it works either | 18:01 |
@HeikoS | if we have a datatype with a "from_string" interface | 18:01 |
lisitsyn | HeikoS: class Enum { string } | 18:01 |
lisitsyn | :) | 18:01 |
@HeikoS | I don't see any way to do this without macros | 18:02 |
@HeikoS | maybe gf712 has ideas as well | 18:02 |
lisitsyn | have to go now | 18:02 |
lisitsyn | I think converting all the enums would be quite wrong | 18:03 |
@HeikoS | ok see you | 18:04 |
-!- gf712 [90520834@gateway/web/freenode/ip.144.82.8.52] has quit [Ping timeout: 256 seconds] | 18:11 | |
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has quit [Ping timeout: 246 seconds] | 18:23 | |
-!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds] | 23:27 | |
-!- besser82 [~besser82@fedora/besser82] has joined #shogun | 23:46 | |
-!- mode/#shogun [+o besser82] by ChanServ | 23:46 | |
-!- besser82 [~besser82@fedora/besser82] has quit [Quit: Freedom, Friends, Features, First [fedoraproject.org]] | 23:58 | |
-!- besser82 [~besser82@fedora/besser82] has joined #shogun | 23:59 | |
-!- mode/#shogun [+o besser82] by ChanServ | 23:59 | |
--- Log closed Fri Feb 01 00:00:52 2019 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!