IRC logs of #shogun for Thursday, 2019-01-31

--- 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 #shogun00:46
-!- mode/#shogun [+o wiking] by ChanServ00:46
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]03:31
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun04:01
-!- mode/#shogun [+o wiking] by ChanServ04:01
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 240 seconds]04:05
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun04:37
-!- mode/#shogun [+o wiking] by ChanServ04:37
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 240 seconds]07:22
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun08:07
-!- mode/#shogun [+o wiking] by ChanServ08:07
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]08:16
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun08:33
-!- mode/#shogun [+o wiking] by ChanServ08: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 #shogun08:51
-shogun-buildbot:#shogun- Build nightly_default #203 is complete: Failure [failed test (failure)] - http://buildbot.shogun-toolbox.org:8080/#builders/17/builds/20308:59
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun09:05
-!- mode/#shogun [+o wiking] by ChanServ09:05
-!- wiking [~wiking@huwico/staff/wiking] has quit [Client Quit]09:09
-!- Lefteris [836fb90d@gateway/web/freenode/ip.131.111.185.13] has joined #shogun11:22
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has joined #shogun11:52
-!- mode/#shogun [+o HeikoS] by ChanServ11:52
@HeikoSwuwei[m] I will merge now, ok? :)11:52
wuwei[m]sure11:53
@HeikoSwell done on that one, it was a beast11:54
@HeikoStada :)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 #shogun12:37
-!- mode/#shogun [+o HeikoS] by ChanServ12:37
lisitsynHeikoS: hey12:38
lisitsynI was thinking in background12:39
@HeikoSjo12:39
@HeikoSlisitsyn and?12:39
lisitsynit should be doable12:39
@HeikoSi wonder how we can do this without refactoring all the enum interfaces12:40
@HeikoSand the machine_int registration of those12:40
@HeikoSsure we can change all the enum types12:40
@HeikoSbut that seems suicidal to me12:40
@HeikoSwhat would be ok would be to somehow change definitions only12:41
@HeikoSand keep all the interfaces the same12:41
@HeikoSand the new definition can be instantiate from string12:41
@HeikoSlisitsyn how would you do it?12:41
@HeikoSlisitsyn 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 #shogun14:01
-!- HeikoS [4dedf3c3@gateway/web/cgi-irc/kiwiirc.com/ip.77.237.243.195] has joined #shogun14:01
HeikoSgf712 yo! how is the python script for extracting model stuff coming along btw?14:17
gf712HeikoS: It can serialise14:18
gf712working on deserialising now14:18
HeikoSgreat14:18
HeikoSis there anything to look at?14:18
gf712went a bit offtrack this week but I'll aim to finish it by tomorrow?14:18
gf712yup, I forked the project and worked on victors branch14:19
gf712viktor's14:19
gf712let me find it14:19
gf712https://github.com/gf712/openml-python/tree/shogun_converter14:20
gf712if you setup it up you should be able to pass an svm with a kernel14:21
gf712with the latest shogun version14:21
gf712still need to add support for other nested objects, i.e. distance14:21
gf712and then need to look at pipeline14:21
gf712I was wondering how I can detect a SGobject that needs to be serialised, i.e. distance and kernel14:22
gf712right now I check if an object is of type "CKernel*" for example14:23
HeikoSget_name should do it I think14:31
HeikoSwait not sure i understand14:32
gf712let's say you have a svm14:32
gf712and it has a kernel14:32
gf712you need to serialise the svm and the kernel within it14:33
gf712so when you query the type of each param you can check if it is a "non primitive" type14:33
gf712for example the kernel param is of type CKernel* I think14:33
HeikoSany sgobject needs to be serialized right?14:33
HeikoSevery14:34
gf712but not all can be14:34
HeikoSlike?14:34
gf712because there isn't a getter for it14:34
gf712hmm one thing I can come up with right now would be a bool14:34
-!- mode/#shogun [+o HeikoS] by ChanServ14:34
gf712not a sgobject14:34
gf712but as an illustration14:34
@HeikoSno but I mean any instance of CSGObject should be serialized14:34
@HeikoSbool is not sgobject14:34
gf712svm=sg.machine("SVM", kernel=sg.kernel("GaussianKernel"))14:35
gf712svm.get("custom_kernel")14:35
gf712 The current Python API does not have a getter for 'custom_kernel' of type 'shogun::CSGObject*'14:36
@HeikoSkernel(svm.get("custom_kernel"))14:36
@HeikoSbtw the custom kernel field should not be exported anyways imo as it is a computational tool14:36
gf712ah ok14:37
@HeikoSdoesnt that work? using the kernel factory?14:37
@HeikoSI think we should name those "as_kernel"14:37
gf712it was more of an example, could even be kernel14:37
gf712if no kernel is defined14:37
@HeikoSas_BASETYPE basically for every of those defined in  factory.h14:37
gf712svm=sg.machine("SVM")14:37
gf712 svm.get("kernel")14:37
gf712ValueError: The current Python API does not have a getter for 'kernel' of type 'shogun::CKernel*'14:37
gf712I can just add a try catch14:37
@HeikoSis that what happens now?14:38
gf712ah ok! good to know14:38
@HeikoSgf712 I vaguely remember that get return CSGObject pointer by default14:39
@HeikoSlet me check that14:39
@HeikoSah ok on14:39
@HeikoSit doesnt14:39
gf712so basically I need to iterate over params14:39
@HeikoSso CSGObject is not a base type that can be retrieved using get14:39
gf712and get a type that I can serialise14:39
@HeikoSok i see14:40
gf712i.e. kernel I can serialise by keeping the name14:40
@HeikoSwhat about this:14:40
@HeikoSwe add a method in the get14:40
gf712and then to serialise you can do sg.TYPE(params)14:40
gf712deserialise*14:40
@HeikoSmmh14:40
@HeikoSi am confused now14:40
@HeikoSso let's stay with kernel14:41
@HeikoSso you iterate over parameter names14:41
@HeikoSand some of those correspond to a CSGObject parameter14:41
gf712yes14:41
gf712such as a kernel14:41
@HeikoSbut curently, there is only getters for specific classes, like kernel14:41
@HeikoSso you would have to try all of those14:41
@HeikoSfor all shogun base types, you would have to try getting them14:41
gf712yes14:42
@HeikoSand if any of those work, then you know that you have a serializable parameter14:42
@HeikoSthat sucks14:42
gf712so I need some list to keep track of what is available14:42
@HeikoSwhat about we move this to c++ code inside swig?14:42
gf712for example in the svm svm.parameter_type('kernel')14:42
@HeikoSlike add a method14:42
@HeikoSget(std::string)14:42
@HeikoSCSGObject* get(std::string)14:42
@HeikoSand this one tries all the base class getters14:42
@HeikoSand then returns a casted version14:43
@HeikoSand then swig wraps that14:43
@HeikoSgood thing is you could auto generate the trying all cases using the shogun base types structure14:43
@HeikoSah14:43
gf712I think that can all be done in python no?14:44
@HeikoSand 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 object14:44
gf712ah the latter would be useful I think14:44
gf712let me think14:44
@HeikoSwell 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 maintainable14:44
@HeikoSa random list of python things somewhere in the code is not ideal, we keep adding base types (see my current PRs)14:45
gf712true14:45
gf712that was my original concern14:45
gf712but I was thinking now14:45
gf712I could try and catch with get14:45
gf712and if get works check if the param is a python builtin, i.e. int14:45
gf712and if not I can keep the type and use that to keep the information to later deserialise14:46
gf712but yea, then I need a mapping14:46
gf712HeikoS what do you mean with "good thing is you could auto generate the trying all cases using the shogun base types structure"?14:47
@HeikoSwell in c++ we know all the base types that are available for put/get14:48
@HeikoSsince we have them in a trait14:48
@HeikoSis_sg_base14:48
@HeikoSput/get is only defined for those14:48
@HeikoSso trying all the types in that trait will definitely work14:49
lisitsynHeikoS: I am thinking of renaming Any :)14:51
lisitsynit becomes Var :D14:51
@HeikoSlisitsyn do it :D14:52
@HeikoSbut14:52
@HeikoSenums!14:52
@HeikoS :)14:52
lisitsynHeikoS: yeah that's why I thought of it14:52
lisitsynHeikoS: I am halfway done14:52
@HeikoScool!14:55
@HeikoSlooking forward to see it14:55
@HeikoSlisitsyn question15:00
lisitsynyes?15:00
@HeikoSshall we rather have CSVM* sg.svm(CSGObject), or CSV* sg.as_svm(CSGObject) or CSVM* CSGObject::as_svm15:00
lisitsyn1 or 215:01
@HeikoSkk15:01
@HeikoSthx :)15:01
@HeikoSlisitsyn another q15:03
@HeikoSso I have MKL class15:03
@HeikoShas a member of type CSVM15:03
@HeikoSnow I wanna put that15:03
@HeikoScurrenty, put is only defined for CMachine15:04
@HeikoSI could add sg.as_svm and define put for svm as well15:04
@HeikoSbut then15:04
@HeikoSput cannot decide if I give an CSVM instance15:04
lisitsynwhy can't it?15:05
@HeikoSwhat happens is that when I call mkl.put("svm", sg.as_svm(my_svm_machine))15:07
@HeikoSswig goes into put_machine15:07
@HeikoSput<CMachine>15:07
@HeikoSnot into put<CSVM>15:07
@HeikoSso I get an error15:07
@HeikoSsince sg.as_svm(my_svm_machine) *is* a machine15:07
lisitsynbut why?15:08
lisitsynCMachine > CSGObject?15:08
lisitsynwhy the same thing does not happen to CMachine then/15:09
@HeikoSbecause there is no put for it15:09
@HeikoSput is only defined for CMachine15:09
@HeikoSnot for SGObject15:09
@HeikoSand it *does* happen15:09
@HeikoSthats why we register ojects by their base lcass15:09
lisitsynHeikoS: actually swig is able to handle such things15:09
@HeikoSnot by sgobject15:09
@HeikoSlet me show you15:09
lisitsynHeikoS: I mean overloading works15:10
lisitsynit might be broken due to something15:10
lisitsynbut it should work15:10
@HeikoSI think i know what happens....meeeh15:13
@HeikoSok anyway15:13
@HeikoSwhy Var? :)15:13
lisitsynHeikoS: it becomes more than any15:16
lisitsynand we can't replace it15:16
lisitsynthe more we add15:16
lisitsyngets really complicated15:17
@HeikoSi see15:18
lisitsynHeikoS: the functional part is really crazy15:24
lisitsyn:D15:24
lisitsynI am surprised I carried that15:25
@HeikoSlol indeed15:26
@HeikoSwell growing15:26
@HeikoSit wasnt designed that way15:26
lisitsynHeikoS: well15:52
lisitsynit solved many problems so it is a good thing15:52
@HeikoSi guess :)15:52
lisitsynyou can't build the same behaviour out of std:: things15:52
lisitsynif we were rebuilding the whole thing it could be15:53
lisitsynHeikoS: ah I lack constexpr-if so much15:53
@HeikoSehehe15:53
@HeikoSgf712 is the master here :)15:53
lisitsynI can't use it so I still rely on decltype things15:54
gf712HeikoS haha I just like the whole moving runtime things to compile time.. but it confuses me too15:56
gf712you're a master if you understand this https://www.youtube.com/watch?v=PJwd4JLYJJY&t=606s15:57
wuwei[m]Heiko: hey16:08
lisitsynHeikoS: gf712: please check https://github.com/shogun-toolbox/shogun/pull/450016:20
lisitsyncheck the test first to understand what's happening16:20
lisitsynHeikoS: now someone has got to convert all the enums17:18
@HeikoSlisitsyn maybe an example would be good?17:33
lisitsynHeikoS: sorry I've spent my borrowed time today :P17:33
lisitsynmaybe tomorrow17:33
@HeikoSsure :)17:33
@HeikoSwhat you wanna convert the enum to?17:33
@HeikoSthe smart enum lib thingi?17:34
@HeikoSor custom?17:34
lisitsynHeikoS: I think the best is to steal and adapt17:34
@HeikoSalright17:40
@HeikoSIll leave that to you :)17:40
lisitsynHeikoS: do we merge the feature?17:42
@HeikoSthe from_string?17:42
lisitsynyes17:42
@HeikoSlisitsyn I would not yet17:42
lisitsynHeikoS: but why?17:42
@HeikoSonly once we actually have something working from meta examples17:42
lisitsynit is complete :)17:42
@HeikoSlike using the liblinera enums from there17:42
@HeikoSthe reason is17:42
@HeikoSthat I see complications on the horizont with changing the enum types17:43
@HeikoSso I would wait17:43
@HeikoSbecause maybe the chain of changes doesnt work in the end17:43
@HeikoSthen we dont need the thingi17:43
@HeikoSsee what I mean?17:43
lisitsynHeikoS: well I'd keep it anyway17:44
@HeikoSbut if we don't use it?17:44
lisitsynmeh17:44
@HeikoSI mean no harm in leaving the Pr there and develop in it or?17:44
@HeikoSI have no string feelings though, if you want to merged, do it ;)17:45
lisitsynThe macro has a soft limit of 64 declared constants.17:46
lisitsynhmm17:46
@HeikoSnot good17:46
@HeikoSah17:46
@HeikoSmmh17:46
@HeikoSmaybe not a problem17:46
@HeikoSwe wont do CT_LIBSVM with that17:46
lisitsynHeikoS: I am thinking of code gen :)17:49
@HeikoSfor what?17:51
lisitsynHeikoS: just like classlist17:53
@HeikoSfor what?17:53
lisitsynHeikoS: I'd go for that if you don't mind17:53
@HeikoSfor the enums?17:53
lisitsynHeikoS: fromstring17:53
lisitsynyes17:53
@HeikoSbut what about plugins?17:54
@HeikoSshouldnt the enums be local to the class only17:54
lisitsynHeikoS: plugin can add these enums to the registry on load17:54
@HeikoSif you do that, then why would we need strings at all?17:55
@HeikoSor no17:55
@HeikoSrather17:55
lisitsynHeikoS: because you can't modify the interface17:55
@HeikoSso you maintain a dictionary or something of all possible enum types?17:56
@HeikoSbut globally17:56
lisitsynHeikoS: looks like17:56
lisitsynthis is the least intrusive solution for now17:56
@HeikoShow do you17:56
@HeikoSwell17:56
@HeikoSdo we want that?17:56
@HeikoSor do we want something nice?17:56
lisitsynwhat's nicer?17:56
lisitsynits all pretty trciky17:57
@HeikoSI am not sure, but I am just saying that least intrusive is maybe not th best criterion to use17:58
@HeikoSand a global list also seems weird to me17:58
@HeikoSrather make shogun enums have the from string inbuilt17:58
lisitsynHeikoS: it is basically impossible :)17:58
lisitsynthe thing is that we either stop treating them as ints17:58
lisitsynooor I don't know17:58
lisitsynI mean that better enum is actually something that's a class17:59
@HeikoSyes17:59
@HeikoSLike some parameter class17:59
@HeikoSdefined via a macro that generates the from string method18:00
lisitsynHeikoS: very tricky things18:00
@HeikoSso ok, how does it work with the global list18:00
lisitsynok I'll think about it18:00
@HeikoSespecially how to instantiate enum whose enum type is unknown at compile time18:01
lisitsynHeikoS: I don't think it works either18:01
@HeikoSif we have a datatype with a "from_string" interface18:01
lisitsynHeikoS: class Enum { string }18:01
lisitsyn:)18:01
@HeikoSI don't see any way to do this without macros18:02
@HeikoSmaybe gf712 has ideas as well18:02
lisitsynhave to go now18:02
lisitsynI think converting all the enums would be quite wrong18:03
@HeikoSok see you18: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 #shogun23:46
-!- mode/#shogun [+o besser82] by ChanServ23:46
-!- besser82 [~besser82@fedora/besser82] has quit [Quit: Freedom, Friends, Features, First [fedoraproject.org]]23:58
-!- besser82 [~besser82@fedora/besser82] has joined #shogun23:59
-!- mode/#shogun [+o besser82] by ChanServ23: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!