| --- 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!