--- Log opened Mon May 21 00:00:02 2012 | ||
--- Day changed Mon May 21 2012 | ||
n4nd0 | we won't have access to anything that is not defined in that class | 00:00 |
---|---|---|
n4nd0 | right? | 00:00 |
-!- cronor [~cronor@g225026248.adsl.alicedsl.de] has quit [Ping timeout: 246 seconds] | 00:00 | |
-!- cronor_ is now known as cronor | 00:00 | |
blackburn | n4nd0: right | 00:01 |
blackburn | looks unsolvable | 00:01 |
blackburn | :D | 00:01 |
n4nd0 | no wait | 00:02 |
n4nd0 | we would have access to the other stuff if we downcast | 00:02 |
blackburn | yes but I so much do not like casting | 00:02 |
n4nd0 | well, but it must exist because of something and it solves the problem we get here :D | 00:03 |
n4nd0 | why don't you like it? | 00:03 |
blackburn | nevermind I think I can live with it :D | 00:03 |
n4nd0 | tell me anyway | 00:03 |
blackburn | I do not know - I simply do not like it | 00:04 |
blackburn | it looks redundant | 00:04 |
n4nd0 | ok | 00:05 |
blackburn | ok let me think what can we do here then | 00:05 |
n4nd0 | how can we do it in any case from other interfaces other that libshogun? | 00:05 |
n4nd0 | e.g. python | 00:05 |
n4nd0 | I have read about doing something like base_class_instance.__class__ = DerivedClass | 00:06 |
n4nd0 | that didn't work though | 00:06 |
n4nd0 | something like that operation can only be used with head variables | 00:06 |
blackburn | no just lets live with casting :D | 00:07 |
n4nd0 | ? | 00:09 |
blackburn | I mean it is ok to do this casting I think | 00:09 |
blackburn | I changed my mind :D | 00:11 |
blackburn | n4nd0: however it looks really redundant | 00:12 |
blackburn | see - you need *to know* which labels to use | 00:12 |
n4nd0 | yes | 00:12 |
n4nd0 | tell me why it is redundant | 00:13 |
blackburn | n4nd0: because of that casting you need to do (and only in one proper way) | 00:14 |
n4nd0 | I don't see why you worry about redundancy here | 00:15 |
n4nd0 | probably I am missing something | 00:15 |
blackburn | I just do not like that any user would need to cast apply result | 00:15 |
blackburn | and know what is the result | 00:15 |
n4nd0 | mmm I see | 00:17 |
n4nd0 | I agree with you, in that sense it would be more comfortable that apply returns directly what is needed | 00:18 |
n4nd0 | but I see no way to have at the same time that advantage and a CMachine::apply that works for all the subclasses | 00:18 |
blackburn | yes and this drives me mad | 00:18 |
n4nd0 | I don't think that the fact that the user needs to know this such a big deal in any case | 00:20 |
n4nd0 | isn't require to know something similar when creating features, for example? | 00:20 |
CIA-113 | shogun: Sergey Lisitsyn master * rfc7021d / (7 files): Some labels refactoring - http://git.io/wxrZTQ | 00:20 |
CIA-113 | shogun: Sergey Lisitsyn master * r101802d / (2 files in 2 dirs): Merge branch 'master' of github.com:shogun-toolbox/shogun - http://git.io/4nqqTQ | 00:20 |
blackburn | yes but there should be a hack anyway | 00:20 |
blackburn | for python at least | 00:20 |
blackburn | n4nd0: ok I think I'd rather go sleep now | 00:24 |
n4nd0 | all right | 00:24 |
n4nd0 | good night | 00:25 |
blackburn | n4nd0: if you are bored | 00:25 |
blackburn | you may add these copy constructors | 00:25 |
blackburn | n4nd0: just ERROR on wrong labels given | 00:26 |
blackburn | in this way your way of casting should work | 00:26 |
n4nd0 | ok | 00:26 |
blackburn | I hope I will feel better about all these things tomorrow | 00:31 |
blackburn | see you | 00:31 |
-!- blackburn [~blackburn@188.122.250.167] has left #shogun [] | 00:31 | |
-!- wiking_ [~wiking@ip188.67-202-72.static.steadfastdns.net] has joined #shogun | 00:44 | |
-!- wiking_ [~wiking@ip188.67-202-72.static.steadfastdns.net] has quit [Changing host] | 00:44 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 00:44 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 250 seconds] | 00:46 | |
-!- wiking_ is now known as wiking | 00:46 | |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] | 01:04 | |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has joined #shogun | 01:04 | |
-!- blackburn [~blackburn@188.122.250.167] has joined #shogun | 01:17 | |
blackburn | argh insomnia | 01:17 |
blackburn | n4nd0: still here? | 01:17 |
n4nd0 | blackburn: yeah | 01:17 |
n4nd0 | blackburn: I cannot solve this :( | 01:17 |
blackburn | solve what? | 01:17 |
n4nd0 | if we return CLabels | 01:18 |
n4nd0 | cast it to CMulticlassLabels in python | 01:18 |
blackburn | hmm why? | 01:19 |
blackburn | I thought copy constructor would enable this - no? | 01:19 |
n4nd0 | I did a constructor like this one | 01:20 |
n4nd0 | http://snipt.org/ujOj3 | 01:20 |
blackburn | right - and? | 01:21 |
n4nd0 | one of the examples explodes | 01:21 |
blackburn | only one? | 01:22 |
n4nd0 | it was the second I tried | 01:22 |
n4nd0 | not a good percentage :D | 01:23 |
blackburn | what is the error? | 01:23 |
n4nd0 | the common *** glibc detected *** python: free(): invalid pointer: 0x0ad330e8 *** | 01:23 |
n4nd0 | and a long trace | 01:23 |
blackburn | heh | 01:24 |
blackburn | ok but it is not the problem of copy constructor I think | 01:24 |
n4nd0 | this it gdb's trace | 01:25 |
n4nd0 | http://snipt.org/ujPb2 | 01:25 |
blackburn | not a constructor problem again :) | 01:26 |
n4nd0 | I think it must be related | 01:27 |
n4nd0 | since it is what the new changes have introduced | 01:27 |
blackburn | no I can't believe that | 01:28 |
blackburn | the problem is in wrong get_mean | 01:28 |
blackburn | n4nd0: do you understand why it is wrong? | 01:29 |
n4nd0 | something is getting deleted twice | 01:29 |
n4nd0 | right? | 01:29 |
blackburn | yes | 01:29 |
blackburn | n4nd0: adding .clone() would be the simplest solution I think | 01:30 |
n4nd0 | I cannot believe that the error has nothing to do with this constructor thing | 01:32 |
n4nd0 | what else can it be otherwise? | 01:33 |
n4nd0 | I'd that probably something is not getting properly initialized | 01:33 |
blackburn | n4nd0: no it is wrong anyway | 01:33 |
n4nd0 | what? | 01:33 |
n4nd0 | the constructor is wrong? | 01:33 |
blackburn | ge_mean | 01:33 |
blackburn | ahha anoooooother problem | 01:34 |
blackburn | apply returns float64_t | 01:34 |
blackburn | apply(int32_t) | 01:34 |
n4nd0 | where is that happening? | 01:34 |
blackburn | cmachine | 01:35 |
blackburn | or what? | 01:35 |
n4nd0 | haha don't know, you said it :P | 01:35 |
n4nd0 | why is that apply an issue? | 01:36 |
n4nd0 | for structured labels it is | 01:36 |
n4nd0 | I actually thought of that but forgot to mention :S | 01:36 |
blackburn | yes for SO | 01:36 |
n4nd0 | arghh damn it | 01:37 |
n4nd0 | is templates = solution? | 01:38 |
blackburn | no | 01:38 |
blackburn | :D | 01:38 |
n4nd0 | why not? | 01:38 |
blackburn | how? | 01:38 |
blackburn | templating of what? | 01:38 |
n4nd0 | the type that represents a single label | 01:38 |
blackburn | CMachine<T>? | 01:40 |
n4nd0 | what otherwise? | 01:41 |
blackburn | CKernelMachiine : public CMachine<float64_t>? | 01:41 |
blackburn | oh so complex | 01:41 |
n4nd0 | it gets nasty indeed | 01:42 |
n4nd0 | this shit is a huge change man ... | 01:42 |
blackburn | I would rather remove apply by index | 01:42 |
n4nd0 | I bet it is not widely used | 01:43 |
blackburn | in all libshogun examples | 01:43 |
blackburn | :D | 01:43 |
n4nd0 | as long as it is in the examples and we don't screw lot of users | 01:44 |
blackburn | we screwed everything already | 01:44 |
blackburn | lets write down | 01:45 |
n4nd0 | so when we say that to make it templated may be difficult in terms of SWIG | 01:56 |
n4nd0 | it should be possible or? | 01:56 |
blackburn | lets assure we have written down all ideas | 01:56 |
blackburn | and freeze it :D | 01:56 |
blackburn | I think yes should be possible | 01:57 |
n4nd0 | *but* if we template it | 01:57 |
n4nd0 | shouldn't CMachine be templated too? | 01:57 |
n4nd0 | how would we declare apply otherwise? | 01:58 |
blackburn | yes be templated | 01:58 |
blackburn | and everything should be | 01:58 |
n4nd0 | I don't like much the idea of making it templated too | 01:58 |
blackburn | sounds infeasible | 01:58 |
n4nd0 | I think that downcasting is the best | 01:58 |
blackburn | yes probably | 01:59 |
n4nd0 | in C++ or java is something we can do directly | 02:00 |
n4nd0 | we need to provide some functions to do it from other languages | 02:00 |
n4nd0 | maybe SWIG methods like the one the suggest in the link I pasted there | 02:00 |
n4nd0 | what do you think? | 02:00 |
blackburn | n4nd0: for python there should be a hack I think | 02:01 |
n4nd0 | to make it transparent you mean= | 02:01 |
n4nd0 | ? | 02:01 |
blackburn | yes | 02:02 |
blackburn | hah it is already dawn here | 02:04 |
n4nd0 | not yet here, but it'll be soon probably | 02:05 |
-!- av3ngr [av3ngr@nat/redhat/x-ouidhbnbsioxllxt] has joined #shogun | 02:06 | |
n4nd0 | let's see if we can agree all on this soon | 02:06 |
blackburn | I'll merge apply() and apply(CFeatures* data) now | 02:07 |
-!- av3ngr [av3ngr@nat/redhat/x-ouidhbnbsioxllxt] has quit [Read error: Connection reset by peer] | 02:07 | |
n4nd0 | what changes? | 02:07 |
-!- av3ngr [av3ngr@nat/redhat/x-hjkimqqbpdpapkel] has joined #shogun | 02:07 | |
blackburn | n4nd0: just merge these two methods | 02:07 |
blackburn | to apply(CFeatures* data=NULL) | 02:07 |
-!- av3ngr [av3ngr@nat/redhat/x-hjkimqqbpdpapkel] has quit [Read error: Connection reset by peer] | 02:27 | |
CIA-113 | shogun: iglesias master * recc853c / src/shogun/classifier/QDA.cpp : ~ RealLabels to MulticlassLabels in QDA - http://git.io/kHTmcQ | 02:27 |
-!- abn_ [av3ngr@nat/redhat/x-pugqrqjzwcytawbe] has joined #shogun | 02:27 | |
-!- vikram360 [~vikram360@117.192.171.164] has joined #shogun | 02:41 | |
blackburn | hmmm good way to get rid of insomnia | 02:41 |
blackburn | now I want to die after such refactoring :D | 02:42 |
CIA-113 | shogun: Sergey Lisitsyn master * rad7e86b / (28 files in 7 dirs): Merged apply() and apply(CFeatures* data) into apply(CFeatures* data=NULL) - http://git.io/q4ZnsA | 02:46 |
-!- vikram360 [~vikram360@117.192.171.164] has quit [Ping timeout: 246 seconds] | 02:46 | |
blackburn | n4nd0: here? | 02:47 |
n4nd0 | yeah | 02:50 |
n4nd0 | tell me | 02:50 |
n4nd0 | blackburn: still insomnia :)? | 02:51 |
blackburn | yes | 02:51 |
blackburn | n4nd0: could you please move QDA to multiclass then? | 02:51 |
n4nd0 | sure | 02:52 |
n4nd0 | I am with another thing but I will do it ;) | 02:52 |
blackburn | ok | 02:53 |
-!- Francis_Chan [~Adium@210.25.133.42] has joined #shogun | 02:55 | |
-!- Francis_Chan [~Adium@210.25.133.42] has left #shogun [] | 02:56 | |
blackburn | hmm no more insomnia | 02:56 |
blackburn | I am powered off | 02:56 |
blackburn | last commit | 02:56 |
blackburn | :D | 02:56 |
blackburn | n4nd0: I ran QDA on 39209 vectors of size 576 | 02:57 |
n4nd0 | how did it go? | 02:57 |
blackburn | is it a big mistake? | 02:57 |
blackburn | 15 mins elapsed or so | 02:57 |
blackburn | no result yet :D | 02:57 |
blackburn | n4nd0: am I right it requires to operate on 43(num classes) matrices of 576x576 shape? | 02:58 |
CIA-113 | shogun: Sergey Lisitsyn master * re8a662e / (8 files in 3 dirs): Moved GNB to multiclass folder - http://git.io/jAD8Vw | 02:59 |
n4nd0 | I didn't understand the last part soryr | 02:59 |
n4nd0 | sorry* | 02:59 |
blackburn | n4nd0: I mean while dimension is 576 | 02:59 |
blackburn | and number of classes is 43 | 02:59 |
n4nd0 | yes? | 02:59 |
blackburn | it would require to construct 43 matrices | 03:00 |
n4nd0 | well, more than that actually :O | 03:00 |
blackburn | but no n_of_vectors matrix? | 03:00 |
blackburn | because 39K is too big for square matrices :D | 03:01 |
blackburn | uh | 03:01 |
blackburn | 915s elapsed | 03:01 |
blackburn | it trained! | 03:01 |
blackburn | lets wait it applies | 03:01 |
n4nd0 | if I remember correctly no, no # vectors matrix | 03:01 |
n4nd0 | it will actually build one matrix, 2 ndarrays and one vector | 03:01 |
blackburn | hmm apply is pretty slow | 03:01 |
n4nd0 | :( | 03:01 |
blackburn | ah | 03:02 |
blackburn | dgemms | 03:02 |
n4nd0 | maybe we could add there multi-threading or sth? | 03:02 |
blackburn | oh line 103 is pretty bad | 03:03 |
blackburn | you may use add_to_dense_vec here instead | 03:03 |
n4nd0 | it is an empty line :P | 03:04 |
blackburn | X = features - means part | 03:04 |
n4nd0 | instead of the for? | 03:04 |
blackburn | ah you need full matrix here | 03:04 |
blackburn | can't it be avoided? | 03:05 |
n4nd0 | no idea | 03:05 |
blackburn | nevermind | 03:06 |
blackburn | we have broken shogun anyway | 03:06 |
blackburn | :D | 03:06 |
n4nd0 | haha | 03:06 |
n4nd0 | c'mon, it will be fixed soon | 03:06 |
n4nd0 | what were you using QDA for btw? | 03:07 |
n4nd0 | just trying it out? | 03:07 |
blackburn | same problem - road sign recognition | 03:07 |
blackburn | yes just curious about results | 03:07 |
n4nd0 | ok | 03:08 |
blackburn | still applying :D | 03:08 |
n4nd0 | oh not good | 03:08 |
n4nd0 | how many vectors? | 03:08 |
n4nd0 | in apply | 03:08 |
blackburn | 12630 | 03:09 |
n4nd0 | those are quite a few too | 03:09 |
blackburn | still.. | 03:11 |
blackburn | arrrrrrgh I can't wait no more | 03:17 |
blackburn | hrrr | 03:17 |
n4nd0 | yeah, I am going to bed too | 03:18 |
n4nd0 | good morning | 03:18 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 03:20 | |
-!- blackburn [~blackburn@188.122.250.167] has quit [Ping timeout: 260 seconds] | 03:21 | |
-!- abn__ [av3ngr@nat/redhat/x-jlcexhkeketlyesx] has joined #shogun | 03:32 | |
-!- abn_ [av3ngr@nat/redhat/x-pugqrqjzwcytawbe] has quit [Ping timeout: 240 seconds] | 03:36 | |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] | 03:57 | |
-!- av3ngr [av3ngr@nat/redhat/x-pjunzffxtdsfhgvr] has joined #shogun | 03:58 | |
-!- abn__ [av3ngr@nat/redhat/x-jlcexhkeketlyesx] has quit [Ping timeout: 276 seconds] | 04:03 | |
-!- vikram360 [~vikram360@117.192.161.161] has joined #shogun | 04:46 | |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has joined #shogun | 05:06 | |
-!- av3ngr [av3ngr@nat/redhat/x-pjunzffxtdsfhgvr] has quit [Read error: Connection reset by peer] | 05:28 | |
-!- av3ngr [av3ngr@nat/redhat/x-crgfftiyumbtmlza] has joined #shogun | 05:29 | |
-!- av3ngr [av3ngr@nat/redhat/x-crgfftiyumbtmlza] has quit [Read error: Connection reset by peer] | 05:40 | |
-!- abn_ [av3ngr@nat/redhat/x-ktzqmkcjqpbbiibl] has joined #shogun | 05:41 | |
-!- abn_ [av3ngr@nat/redhat/x-ktzqmkcjqpbbiibl] has quit [Read error: Connection reset by peer] | 06:12 | |
-!- abn_ [av3ngr@nat/redhat/x-aqwycomoiagytinn] has joined #shogun | 06:14 | |
-!- abn__ [av3ngr@nat/redhat/x-mfgmdhkqdftcoqnz] has joined #shogun | 06:49 | |
-!- abn_ [av3ngr@nat/redhat/x-aqwycomoiagytinn] has quit [Ping timeout: 244 seconds] | 06:52 | |
-!- abn__ [av3ngr@nat/redhat/x-mfgmdhkqdftcoqnz] has quit [Read error: Connection reset by peer] | 07:04 | |
-!- av3ngr [av3ngr@nat/redhat/x-nknzddjwccloowmq] has joined #shogun | 07:05 | |
-!- abn_ [av3ngr@nat/redhat/x-fnazpdaeawkebpne] has joined #shogun | 07:10 | |
-!- av3ngr [av3ngr@nat/redhat/x-nknzddjwccloowmq] has quit [Ping timeout: 265 seconds] | 07:14 | |
-!- abn_ [av3ngr@nat/redhat/x-fnazpdaeawkebpne] has quit [Read error: Connection reset by peer] | 07:22 | |
-!- av3ngr [av3ngr@nat/redhat/x-hswmmepzjupurfpz] has joined #shogun | 07:23 | |
-!- av3ngr [av3ngr@nat/redhat/x-hswmmepzjupurfpz] has quit [Read error: Connection reset by peer] | 07:40 | |
-!- av3ngr [av3ngr@nat/redhat/x-pkxftaaonwjygnkl] has joined #shogun | 07:40 | |
-!- av3ngr [av3ngr@nat/redhat/x-pkxftaaonwjygnkl] has quit [Read error: Connection reset by peer] | 07:58 | |
-!- abn_ [av3ngr@nat/redhat/x-kcuzawowlelshpos] has joined #shogun | 07:59 | |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has quit [Quit: cronor] | 08:18 | |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has joined #shogun | 08:19 | |
@sonney2k | morning | 08:25 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 08:28 | |
@sonney2k | n4nd0, how about the solution you and blackburn suggested? | 08:30 |
@sonney2k | I mean use apply_binary() and it will return BinaryLabels | 08:30 |
@sonney2k | apply_multiclass() -> MulticlassLabels etc | 08:30 |
n4nd0 | the one we referred to as to use interfaces? | 08:31 |
@sonney2k | and then in addition to enable people to use CMethod::apply() | 08:31 |
@sonney2k | a way to convert CLabels -> anything | 08:31 |
@sonney2k | if possible :) | 08:31 |
@sonney2k | so adding additional constructors CMulticlassLabels(CLabels* lab) | 08:32 |
@sonney2k | etc | 08:32 |
@sonney2k | I am fine with that | 08:32 |
n4nd0 | that's like providing all the strategies we talked about except from templates :D | 08:32 |
@sonney2k | templates? | 08:32 |
@sonney2k | you mean each machine gets a template label parameter? | 08:33 |
n4nd0 | to make CLabels templated | 08:33 |
@sonney2k | that won't help | 08:33 |
n4nd0 | yeah, CMachine should then be templated too | 08:33 |
n4nd0 | I do not like that much this though | 08:33 |
@sonney2k | actually it is sufficient if CMachine is templated | 08:33 |
@sonney2k | L* labels; | 08:33 |
n4nd0 | sonney2k: have you seen the google docs where we wrote some of this things? | 08:34 |
n4nd0 | these* things | 08:34 |
@sonney2k | not yet | 08:34 |
n4nd0 | but you have access to it, right? | 08:34 |
-!- pluskid [~pluskid@li164-218.members.linode.com] has joined #shogun | 08:35 | |
pluskid | hi sonney2k | 08:35 |
@sonney2k | n4nd0, I got the mail but my mail prg is refusing access | 08:36 |
@sonney2k | pluskid, there are a couple of issues we need to discuss about wrt the new label system | 08:36 |
pluskid | I just got the email | 08:36 |
@sonney2k | pluskid, biggest problem is that some machines return binary labels *or* reallabels | 08:36 |
pluskid | for example? | 08:36 |
@sonney2k | like kernel machines | 08:36 |
@sonney2k | so plan would be to use CMachine::apply() whcih always returns CLabels | 08:37 |
@sonney2k | and then inside the machines have a function like apply_binary() etc | 08:37 |
@sonney2k | returning the wanted label | 08:37 |
@sonney2k | and if there is just one alternative return it in apply() | 08:37 |
@sonney2k | based on label type one can then determine whats going on | 08:37 |
@sonney2k | argh | 08:37 |
@sonney2k | I have to leave train | 08:38 |
pluskid | so apply_binary, apply_mc, apply_SO? | 08:38 |
@sonney2k | n4nd0, I please get pluskid up to date | 08:38 |
@sonney2k | yeah | 08:38 |
@sonney2k | gtg | 08:38 |
pluskid | ok | 08:38 |
@sonney2k | will be back in 10-15 mins | 08:38 |
pluskid | n4nd0: so what's the conclusion so far? | 08:38 |
n4nd0 | pluskid: I'll send you a link to a google doc where we wrote some of our thoughts | 08:38 |
pluskid | the doc blackburn shared? | 08:39 |
n4nd0 | yeah | 08:39 |
n4nd0 | already got it? | 08:39 |
n4nd0 | I just sent you an invitation in any case | 08:39 |
pluskid | Ah, got it | 08:40 |
pluskid | but those are all questions | 08:40 |
pluskid | not solutions | 08:40 |
n4nd0 | possible solutions are 1, 2 and 3 | 08:40 |
pluskid | hmm | 08:41 |
n4nd0 | I told you it was a doc with some thoughts in any case ;) | 08:41 |
pluskid | 1 will be killed by sonney2k | 08:41 |
n4nd0 | yeah | 08:41 |
n4nd0 | that one is there just because it could be possible | 08:41 |
n4nd0 | but imho to make CMachine templated is not a good idea | 08:42 |
n4nd0 | so I would discard it as well | 08:42 |
n4nd0 | I think that he is suggesting to provide both 2 and 3 | 08:42 |
pluskid | both? | 08:43 |
n4nd0 | just change "possible solutions" if you don't like that ;) | 08:43 |
n4nd0 | yeah, I think so | 08:43 |
n4nd0 | check what he said at 8:30 | 08:43 |
n4nd0 | I don't know yet why both | 08:43 |
pluskid | downcasting seems to be not very friendly to SWIG | 08:44 |
n4nd0 | I think the link is a way to do it | 08:44 |
pluskid | i like 3 personly | 08:44 |
pluskid | yes, but that's tedious | 08:44 |
pluskid | have to write a func for every possible casting | 08:44 |
n4nd0 | do you think so? | 08:44 |
n4nd0 | it is just one for each Labels hierarchy leaf | 08:45 |
n4nd0 | shouldn't be that many | 08:45 |
n4nd0 | Binary, Multiclass, Regression (or Real) and SO | 08:45 |
pluskid | hmm | 08:45 |
pluskid | you are right | 08:45 |
-!- sonne|work [~sonnenbu@194.78.35.195] has joined #shogun | 08:52 | |
sonne|work | Re | 08:53 |
sonne|work | pluskid, n4nd0 so any thoughts? | 08:53 |
-!- uricamic [~uricamic@2001:718:2:1634:28fe:5862:cc8e:2234] has joined #shogun | 08:53 | |
n4nd0 | sonney2k: why do we need both things? castings from Labels to any other thing *and* the interfaces? | 08:54 |
n4nd0 | wouldn't one of them suffice? | 08:54 |
sonne|work | n4nd0: which interfaces? | 08:54 |
sonne|work | you mean the apply_binary? | 08:55 |
n4nd0 | the approach 3 in the document | 08:55 |
n4nd0 | yeah | 08:55 |
pluskid | sonne|work: so you put apply_binary in CMachine or CBinaryMachine? | 08:55 |
sonne|work | pluskid: in kernel machine | 08:55 |
n4nd0 | pluskid: I think that would be in CBinary | 08:55 |
sonne|work | I wouldn't introduce any CBinary or so | 08:55 |
n4nd0 | oh yeah, in kernel and linear machine probably | 08:56 |
sonne|work | n4nd0: I just managed to open the document | 08:56 |
n4nd0 | good | 08:56 |
sonne|work | 1) isn't going to help as with the problem we are having | 08:56 |
pluskid | sonne|work: so KernelMachine can return both CRealLabel and CBinaryLabel? | 08:56 |
sonne|work | so 2) and 3) or apply_binary() etc are the only option | 08:57 |
sonne|work | pluskid: yes | 08:57 |
pluskid | why not make use of confidence in BinaryLabels ? | 08:57 |
pluskid | I mean RealLabel is equivalent to BinaryLabels with confidence value | 08:57 |
sonne|work | pluskid: no | 08:58 |
sonne|work | real labels might have confidences too | 08:58 |
sonne|work | pluskid: think of GPs | 08:58 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: Lost terminal] | 08:58 | |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 08:58 | |
pluskid | sonne|work: so KernelMachine can be used for both classification and regression? | 08:59 |
pluskid | GP can return RealLabel with confidence | 09:00 |
pluskid | KernelMachine can return BinaryLabel with confidence | 09:00 |
sonne|work | pluskid: exactly | 09:00 |
sonne|work | but kernel machine could also return real label with confidence | 09:00 |
pluskid | so there's no need for KernelMachine to be able to return *both* RealLabel and BinaryLabel | 09:01 |
pluskid | oops | 09:01 |
pluskid | GP is a subclass of Kernelmachine? | 09:01 |
sonne|work | no but it could be | 09:01 |
sonne|work | and there are other techniques like it... | 09:01 |
pluskid | hmm | 09:01 |
pluskid | too bad that SWIG doesn't support interfaces | 09:02 |
pluskid | I mean multiple inheritance with pure virtual superclass (like interface in Java) | 09:02 |
pluskid | or else solution 3 looks good | 09:03 |
sonne|work | well the other solution | 09:03 |
sonne|work | would be to use templates in machines | 09:03 |
sonne|work | like L* labels | 09:03 |
sonne|work | but then again that doesn't help | 09:03 |
sonne|work | in swig and friends we would need to do %template Machine<CBinaryLabels> BinaryMachine etc | 09:04 |
sonne|work | actually 4) and 2) are more or less the same... | 09:06 |
pluskid | sonne|work: though some machines can be used for both regression and classification | 09:06 |
pluskid | or both binary or MC | 09:06 |
pluskid | I think it's good to distinguish | 09:06 |
pluskid | to create base class for binary, MC, regression and SO | 09:06 |
pluskid | for example | 09:07 |
pluskid | liblinear can do many things | 09:07 |
pluskid | but we can wrap it as binary and mc | 09:07 |
pluskid | different wrappers makes it "different" machines | 09:07 |
pluskid | this might make things more clear | 09:07 |
sonne|work | pluskid leaving aside the problem that then e.g. liblinear cannot be a linearmachine for both regression and classification, this would also mean apply() from CMachine is no longer useful | 09:09 |
-!- abn_ [av3ngr@nat/redhat/x-kcuzawowlelshpos] has quit [Read error: Connection reset by peer] | 09:09 | |
-!- abn_ [av3ngr@nat/redhat/x-ofozcfboipspfgxn] has joined #shogun | 09:09 | |
sonne|work | except if we return CBinaryLabels casted as CLabels like now | 09:09 |
-!- uricamic [~uricamic@2001:718:2:1634:28fe:5862:cc8e:2234] has quit [Quit: Leaving.] | 09:09 | |
pluskid | if we make the hierarchy clear | 09:09 |
pluskid | then CMachine would have no apply | 09:09 |
-!- abn_ [av3ngr@nat/redhat/x-ofozcfboipspfgxn] has quit [Read error: Connection reset by peer] | 09:10 | |
pluskid | apply() is moved to subclasses | 09:10 |
pluskid | CBinMachine, CMCMachine, CSOMachine, etc. | 09:10 |
pluskid | CBinMachine's apply return CBinLabels | 09:10 |
pluskid | CSOMachine's apply return CSOLabels | 09:10 |
pluskid | do you think this is a possible solution? | 09:10 |
-!- abn_ [av3ngr@nat/redhat/x-nxczvssnqswykuju] has joined #shogun | 09:10 | |
sonne|work | pluskid: yes except that we have code duplication because we also have KernelMachine etc | 09:11 |
pluskid | hmm | 09:11 |
-!- abn_ [av3ngr@nat/redhat/x-nxczvssnqswykuju] has quit [Read error: Connection reset by peer] | 09:11 | |
pluskid | yes | 09:11 |
pluskid | you are right | 09:11 |
n4nd0 | I don't like much the idea of removing apply() from the base class and have it in all the subclasses | 09:11 |
-!- abn_ [av3ngr@nat/redhat/x-kkqwvuqhxfnbucxt] has joined #shogun | 09:11 | |
pluskid | KernelMachine is in a different hierarchy | 09:11 |
sonne|work | well ok CBinKernelMachine etc gives also too much stuff | 09:12 |
sonne|work | Machines I mean | 09:12 |
sonne|work | n4nd0: yeah I would prefer to have apply() in the baseclass too | 09:12 |
sonne|work | problem then remains with casting | 09:12 |
-!- abn_ [av3ngr@nat/redhat/x-kkqwvuqhxfnbucxt] has quit [Read error: Connection reset by peer] | 09:12 | |
-!- av3ngr [av3ngr@nat/redhat/x-whazgcqjivdomxue] has joined #shogun | 09:13 | |
sonne|work | I am not so worried about the casting stuff - what sucks though is that we need some extra treatment for the modular interfaces | 09:13 |
n4nd0 | sonne|work: why about the solution provided in the link in the google docs? | 09:13 |
sonne|work | n4nd0: it is basically 4) | 09:13 |
n4nd0 | well, I think it is 2) | 09:14 |
sonne|work | n4nd0: I would rather do a better one really for each machine doing something more clever | 09:14 |
n4nd0 | it is a way to provide this downcasting | 09:14 |
sonne|work | as in no need to change python modular code at all | 09:14 |
sonne|work | you just get the right CBinaryLabel object even if CMachine only returns CLabels | 09:14 |
sonne|work | this can be done by %ignore CMachine::apply() | 09:15 |
sonne|work | and adding a new apply() function in swig that returns the right type for each machine | 09:15 |
sonne|work | but the problem remains - linear machines can return both binary and regression labels | 09:16 |
sonne|work | some for kernel machines | 09:16 |
n4nd0 | I like that solution :) | 09:16 |
sonne|work | so I don't have a solution for that other than doing 4) apply_binary() etc... | 09:16 |
sonne|work | and lets say apply() per default returns the most powerful label descriptor like RealLabels in this case | 09:17 |
n4nd0 | could the same be applied but doing the %ignore in linear machine and kernel machine | 09:17 |
n4nd0 | and adding new apply in swig for every particular machine? | 09:17 |
sonne|work | n4nd0: yes - the only issue we have is that one might want to serialize a machine | 09:18 |
sonne|work | so when loading it you want to be able to call apply() | 09:18 |
sonne|work | ok fix would be to rename apply to apply_machine() | 09:18 |
sonne|work | but then one has to do the casting | 09:19 |
sonne|work | or to serialize the real machine (LibLinearRegression) ... | 09:19 |
sonne|work | n4nd0: actually no - that all should be ok. because one cannot cast down to CMachine from e.g. LibLinear anyways... | 09:22 |
sonne|work | n4nd0: so I favor this approach. it will involve doing 4) as helper functions and some typemap magic in addition | 09:23 |
n4nd0 | sonne|work: but there is no need to make apply_binary and friends | 09:24 |
pluskid | sonne|work: have a look at solution (5)? | 09:25 |
sonne|work | n4nd0: the typemaps would need to call them | 09:25 |
sonne|work | n4nd0: so better have that in the class | 09:25 |
sonne|work | pluskid: looking | 09:25 |
n4nd0 | sonne|work: ok, I understand | 09:26 |
sonne|work | pluskid: yes - I think we can avoid code duplication there by just having an independent CKernelMachine class that can be utilized | 09:26 |
-!- uricamic [~uricamic@2001:718:2:1634:2030:5375:f044:5459] has joined #shogun | 09:26 | |
sonne|work | I prefer 4) with typemap changes though | 09:26 |
pluskid | yes, kind of that | 09:26 |
sonne|work | let me write it | 09:26 |
pluskid | ok | 09:27 |
pluskid | but (5) can avoid that SWIG magic | 09:28 |
sonne|work | hmmhh, so how do we come to a decision? I guess we should wait for blackburn | 09:28 |
sonne|work | pluskid: yes | 09:28 |
sonne|work | but it sacrifices the apply() interface | 09:29 |
pluskid | there's no need for a generic apply() if we make the hierarchy clear | 09:29 |
pluskid | isn't it? | 09:29 |
sonne|work | pluskid: I think it is the same concept that we use for CMachine::apply(CFeatures* data) | 09:30 |
sonne|work | we have general CFeatures* there | 09:30 |
n4nd0 | sonne|work: got a doubt here, let's say we have KNN | 09:30 |
sonne|work | and only later check for the correct type | 09:30 |
n4nd0 | sonne|work: it will have two methods, apply() and apply_multiclass(), right? | 09:30 |
pluskid | I think they are different | 09:31 |
pluskid | a generic apply() returning a generic CLabel is not very useful | 09:31 |
sonne|work | pluskid: so we don't have CRealMachines or so | 09:31 |
n4nd0 | sonne|work: are both methods supposed to be implemented? | 09:31 |
sonne|work | pluskid: well one always has to cast to the correct type | 09:31 |
pluskid | yes, if one has to do casting, then one knows what he is doing | 09:31 |
n4nd0 | sonne|work: or apply() will contain most of the stuff and apply_multiclass just() calls and cast the return type from CLabels* to CMulticlassLabels* | 09:31 |
sonne|work | n4nd0: I would implement apply_multiclass() and let apply() { return apply_multiclass(); } | 09:32 |
pluskid | if one know what he is doing, he should know what kind of machine he is using | 09:32 |
pluskid | instead of a generic CMachine | 09:32 |
sonne|work | pluskid: but why is this different wrt CFeatures? you know which feature type you want to use so you should use a machine that supports it | 09:32 |
pluskid | there are machines that supports different kind of features | 09:33 |
pluskid | but each machine supports only one kind of label | 09:33 |
pluskid | (if we make the hierarchy clear as in (5)) | 09:33 |
sonne|work | pluskid: well one could say the same about machines & features. we would have RealKernels working only on realfeatures etc | 09:35 |
sonne|work | so then they would only support one type of features | 09:35 |
pluskid | but there are too many features, but only several kind of labels | 09:36 |
pluskid | a kind of trade-off here | 09:36 |
pluskid | anyway, maybe we should have blackburn in the discussion, too | 09:36 |
sonne|work | pluskid: yes it is a trade-off... I am favoring the other solution simply because we already treat features differently and I think it is more consistent now with CLabels to do the same | 09:37 |
pluskid | hmm | 09:37 |
sonne|work | of course the other solution is to just use the 'new' label system as is | 09:39 |
sonne|work | that is just real valued outputs | 09:39 |
sonne|work | is what machines return in general | 09:39 |
sonne|work | but CMachine::apply() still returns CLabels* | 09:39 |
sonne|work | pluskid: I like it more the way you suggested with having binary machines return binary stuff though ... | 09:40 |
pluskid | real valued output isn't suitable for SO I guess | 09:40 |
pluskid | yes, Binary and Regression is not that different | 09:40 |
pluskid | they can be combined | 09:40 |
sonne|work | pluskid: SOmachines will return SOLabels of course... that all works with the CLabels* CMachine::apply() interface | 09:43 |
sonne|work | pluskid: could you live with 4) btw? | 09:43 |
sonne|work | wiking: any opinion? | 09:44 |
pluskid | yes, of course :D | 09:44 |
pluskid | I have no problem with (4), though I prefer (5) :p | 09:44 |
sonne|work | yeah I know | 09:44 |
sonne|work | pluskid: the other issue with 5) is that it is a lot of work | 09:45 |
pluskid | that's true | 09:45 |
sonne|work | a lot more than 4) | 09:45 |
sonne|work | and I think 4) is already quite a bit | 09:45 |
sonne|work | well ok mostly in typemaps | 09:46 |
pluskid | so fast! | 09:46 |
sonne|work | not so much in machines/labels - only base machines and labels have to be touched | 09:46 |
sonne|work | pluskid: heh | 09:46 |
pluskid | sonne|work: you win :D | 09:46 |
sonne|work | n4nd0: you still ok with 4)? | 09:46 |
n4nd0 | sonne|work: sure | 09:47 |
sonne|work | I hope blackburn can live with it too | 09:47 |
sonne|work | we really need to get back into a stable state | 09:47 |
n4nd0 | the only problem I see with it is that apart from you I don't know who can take care of it since it requires dealing with SWIG | 09:48 |
sonne|work | and a decision is the first thing we need... rest is easy | 09:48 |
sonne|work | n4nd0: I can easily do an example | 09:48 |
sonne|work | then the rest will be obvious and you all can help | 09:48 |
n4nd0 | all right | 09:48 |
sonne|work | the changes to labels/machines can be done rather quickly | 09:49 |
n4nd0 | sonne|work: another topic, is it possible to use mosek from shogun? | 09:49 |
sonne|work | n4nd0: we have no wrapper for mosek | 09:49 |
sonne|work | n4nd0: so you are on your own | 09:49 |
n4nd0 | sonne|work: it turned out that we cannot use libqp for our problem :( | 09:49 |
n4nd0 | SO, I mean | 09:50 |
sonne|work | uh! | 09:50 |
sonne|work | that is not good | 09:50 |
sonne|work | we have to discuss with uricamic & vojtech | 09:50 |
sonne|work | n4nd0: we cannot use mosek by default | 09:50 |
sonne|work | we need something open source... | 09:50 |
n4nd0 | no way to use mosek as a first instance? | 09:51 |
sonne|work | n4nd0: would you mind doing a pull request for the labels - I mean for casting things? | 09:51 |
sonne|work | n4nd0: no one can use it except you then | 09:52 |
n4nd0 | sonne|work: because of the license file? | 09:52 |
sonne|work | not the build bot nor me ... | 09:52 |
sonne|work | n4nd0: what do you need btw that you cannot use any of libqp? | 09:52 |
n4nd0 | check this | 09:53 |
n4nd0 | http://cmp.felk.cvut.cz/~xfrancv/libqp/html/ | 09:53 |
n4nd0 | we need to solve something similar to the second problem | 09:53 |
n4nd0 | QP task with box constraints and a single linear equality constraint. | 09:53 |
n4nd0 | but our problem needs to handle inequalities like A?w <= b | 09:53 |
n4nd0 | or better A?x <= b using the notation there for the optimization vector | 09:54 |
sonne|work | n4nd0: that is a general optimizer you need there - IIRC there is no open source one for that | 09:55 |
sonne|work | is there no way around it? | 09:55 |
n4nd0 | I asked nico about it, he knows I asked him to use something open source | 09:56 |
n4nd0 | but he suggested mosek | 09:56 |
n4nd0 | so I guess there's nothing to do | 09:56 |
n4nd0 | no workaround either :S | 09:57 |
n4nd0 | afaik | 09:57 |
sonne|work | uricamic: do you need sth as complex as n4nd0? | 09:57 |
uricamic | hi there | 09:57 |
sonne|work | n4nd0: uricamic is creating some fast solver for SO problems | 09:57 |
sonne|work | so he will know if he needs a Ax <=b constraint | 09:57 |
uricamic | sonne|work: in my case the libqp is completely ok | 09:57 |
sonne|work | uricamic: how come you don't have these constraints? | 09:58 |
sonne|work | uricamic: btw is vojtech back? | 09:58 |
uricamic | He should be at work today, but has not arrived yet | 09:58 |
sonne|work | uricamic: ok maybe you ask him or tell us how you can do without Ax<=b :) | 09:59 |
uricamic | I think for the BMRM we are using, it is sufficient to use the liqp_splx solver | 09:59 |
sonne|work | uricamic: do you have the SO formulation you are solving somewhere on paper? | 10:00 |
sonne|work | and could mail it around to all the SO guys? | 10:00 |
n4nd0 | I think that using the dual formulation one doesn't encounter that constraints | 10:00 |
n4nd0 | those* | 10:01 |
uricamic | do you mean the original BMRM, or the version with our "improvements" | 10:01 |
sonne|work | uricamic: look at the mails nico sent around - the first one had a .pdf with the problem they are trying to solve | 10:04 |
sonne|work | so it is the original one IMHO | 10:04 |
sonne|work | n4nd0: could you deal with labels now? | 10:11 |
n4nd0 | sonne|work: do you want me to include this apply_binary and friends methods? | 10:11 |
sonne|work | n4nd0: no just the CMulticlassLabels(CLabels* label) stuff | 10:12 |
n4nd0 | ok | 10:12 |
-!- karlnapf [~heiko@host86-176-253-113.range86-176.btcentralplus.com] has joined #shogun | 10:25 | |
-!- vikram360 [~vikram360@117.192.161.161] has quit [Ping timeout: 245 seconds] | 10:26 | |
-!- vikram360 [~vikram360@117.192.169.190] has joined #shogun | 10:27 | |
-!- eric_ [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has joined #shogun | 10:30 | |
eric_ | hi all | 10:32 |
-!- av3ngr [av3ngr@nat/redhat/x-whazgcqjivdomxue] has quit [Quit: That's all folks!] | 10:32 | |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has quit [Quit: cronor] | 10:35 | |
n4nd0 | sonne|work: can you take a look to the new PR a moment and tell me if that is what you wanted? | 10:38 |
n4nd0 | how can we stop with an error if the cast is not valid? | 10:39 |
sonne|work | n4nd0: could you please check the label type? | 10:39 |
sonne|work | base_labels->get_label_type() == LT_MULTICLASS | 10:39 |
n4nd0 | all right | 10:39 |
sonne|work | ahh and btw isn't this an upcast :D | 10:39 |
sonne|work | YMMV as usual :) | 10:40 |
n4nd0 | we have a CLabels and get a CMulticlassLabels | 10:40 |
n4nd0 | I understand that as downcast | 10:40 |
n4nd0 | how do you see it? | 10:40 |
sonne|work | the other way round | 10:40 |
sonne|work | I guess my trees grow the other direction | 10:41 |
n4nd0 | :D | 10:41 |
sonne|work | n4nd0: what is CLabels* const base_labels for? | 10:41 |
sonne|work | the const? | 10:41 |
n4nd0 | just to denote we do not point to another thing inside | 10:42 |
n4nd0 | that we won't do base_labels = ... | 10:42 |
n4nd0 | does it make sense? | 10:42 |
sonne|work | you mean base_labels.something=somethign? | 10:42 |
n4nd0 | mmm no | 10:44 |
n4nd0 | that the pointer is constant | 10:44 |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 10:44 | |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 10:44 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 10:44 | |
sonne|work | n4nd0: but then it doesn't help or? I mean base_labels=NULL won't change a thing | 10:44 |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 265 seconds] | 10:45 | |
-!- wiking_ is now known as wiking | 10:45 | |
n4nd0 | sonne|work: I use just to make clear that base_class will point to the same thing after the call than before it | 10:46 |
n4nd0 | by the way I think I should assign the other members too | 10:46 |
n4nd0 | the confidences vector, the subset stack | 10:47 |
sonne|work | n4nd0: but when you have foo(int i) you don't write const there right? because i=2 won't change outside anyway | 10:47 |
sonne|work | ok anyway what is a problem is that we would need to steal the original labels etc | 10:48 |
n4nd0 | sonne|work: yeah it is base_class->something = .... we are not allowed to do that with the const | 10:49 |
sonne|work | n4nd0: maybe it is better to not have that as constructor but static helper function then | 10:49 |
n4nd0 | sonne|work: why? | 10:50 |
sonne|work | so just CMulticlassLabels* obtain_from_generic(CLabel* label) | 10:50 |
sonne|work | and then return the cast' object | 10:50 |
sonne|work | n4nd0: in constructor we cannot change the type of base_labels but have to copy all fields, like m_labels, m_confidences, ... | 10:51 |
-!- pluskid [~pluskid@li164-218.members.linode.com] has quit [Quit: Leaving] | 10:52 | |
n4nd0 | ok | 10:53 |
n4nd0 | so just that with (CMulticlassLabels*) base_labels | 10:53 |
sonne|work | yeah plus the label type check and an appropriate SG_ERROR msg | 10:54 |
-!- cronor [~cronor@fb.ml.tu-berlin.de] has joined #shogun | 11:02 | |
eric_ | What's the purpose of a MulticlassLbels class ? | 11:03 |
sonne|work | eric_: when we designed shogun we just used double* as in /output labels | 11:04 |
sonne|work | but that is not really nice/clean way | 11:04 |
sonne|work | for example binarylabels should only have +/-1 | 11:04 |
sonne|work | and machines having them as input should output +/-1 | 11:05 |
n4nd0 | wow I just got my package! | 11:06 |
sonne|work | same with multiclass 0...<nr classes> | 11:06 |
sonne|work | -1 | 11:06 |
sonne|work | so a binary classifier will return a binary label object | 11:06 |
sonne|work | and we have outputs +/- 1 | 11:07 |
sonne|work | in internally confidences (the real valued outputs) from before | 11:07 |
eric_ | okay thx | 11:07 |
eric_ | sonne|work: I would like to point out smthg strange with multiclass Xvalid, I didnt find the problem but some multiclass machine give wrong Xvalid results | 11:08 |
sonne|work | karlnapf: btw any thoughts about the new label stuff? | 11:09 |
eric_ | sonne|work: seems that only CMulticlassLibLinear works with that | 11:09 |
karlnapf | sonne|work, hi, just looking into it | 11:09 |
karlnapf | or could you give a brief overview? | 11:09 |
eric_ | sonne|work: CGMNPSVM or CMulticlassLibSVMgive wrong results. I said wrong coz I ve been testing splitting manually several times .. | 11:10 |
sonne|work | karlnapf: not yet ready though - there is one big change still missing | 11:11 |
sonne|work | karlnapf: in principle we drop the old label class | 11:11 |
sonne|work | before we assumed all labels == doubles | 11:11 |
karlnapf | and now instead? | 11:12 |
sonne|work | now we introduce CBinaryLabels, CMulticlassLabels, CRealLabels etc | 11:12 |
sonne|work | CStructuredOutputLabels | 11:12 |
sonne|work | etc | 11:12 |
sonne|work | and binary labels are just +1/-1 | 11:12 |
sonne|work | but all of them have confidences | 11:12 |
karlnapf | ah thats nice | 11:12 |
sonne|work | which for SVM would be the real valued outputs | 11:12 |
sonne|work | so a svm would return binary labels | 11:13 |
sonne|work | and one can access the actual predictions | 11:13 |
sonne|work | with +1/-1 | 11:13 |
karlnapf | we can finally have the john plat sigmoid stuff :) | 11:13 |
sonne|work | or the confidences for computing roc | 11:13 |
sonne|work | that's about it | 11:13 |
karlnapf | what about multiclass? | 11:13 |
sonne|work | 0...<nr_classes> | 11:13 |
karlnapf | confidences? | 11:13 |
sonne|work | confidence will be max f(x) in OvR | 11:14 |
sonne|work | for others not clear | 11:14 |
sonne|work | karlnapf: there are tons of implementation issues though | 11:14 |
karlnapf | Will there be a way to get normed probabilities for multiclass? | 11:14 |
sonne|work | biggest concern is that if we want apply() to still return labels | 11:14 |
karlnapf | Because this currently has to be done in an extra class | 11:14 |
sonne|work | we need to cast | 11:14 |
-!- blackburn [~blackburn@188.122.250.167] has joined #shogun | 11:15 | |
karlnapf | So if I call apply I get just Labels | 11:15 |
karlnapf | but I know that these are binary labels so I would have to cast? | 11:15 |
sonne|work | karlnapf: one can add those... | 11:15 |
sonne|work | karlnapf: yes | 11:15 |
karlnapf | uuuh | 11:15 |
sonne|work | blackburn: morning. hope you didn't have nightmares | 11:15 |
blackburn | hey | 11:16 |
karlnapf | hi blackburn | 11:16 |
n4nd0 | blackburn: did you beat the insomnia? | 11:16 |
sonne|work | karlnapf: you can check the actual type via labels->get_label_type() == LT_BINARY etc | 11:16 |
karlnapf | ah ok | 11:16 |
eric_ | So if I undestand well: any calls to apply() with return a CLabel (base class for all derived labels ?) | 11:16 |
karlnapf | mmmh, perhaps some way to do this automatically? | 11:16 |
sonne|work | and we think about adding apply_binary() to return the actual CBinaryLabel type | 11:16 |
sonne|work | karlnapf: not really. only way is to drop the apply() method from CMachine | 11:17 |
sonne|work | blackburn: could you live with option 4) ? | 11:17 |
karlnapf | mmmh | 11:17 |
karlnapf | what about adding a method to the labels which casts itself (if possible, if not throws error), that would be dirty but might work | 11:18 |
sonne|work | karlnapf: for binary labels we could add a estimate sigmoidal for the confidences | 11:18 |
karlnapf | Label::get_binary_cast | 11:18 |
n4nd0 | sonne|work: PR updated, I think that is the idea | 11:18 |
karlnapf | or so | 11:18 |
sonne|work | or histogram based | 11:18 |
eric_ | if you add a apply_binary(), why not adding apply_multiclass() so ? | 11:18 |
sonne|work | yeah nice | 11:18 |
sonne|work | eric_: yes | 11:18 |
sonne|work | eric_: we will do too | 11:18 |
sonne|work | karlnapf: that is what we will add yes | 11:19 |
blackburn | hehe sorry welcome package arrived | 11:19 |
blackburn | re | 11:19 |
karlnapf | why do we need an apply_binary then? | 11:19 |
eric_ | sonne|work: seems strange coz when apply is called, you know what type of CLabels is in argument no ? | 11:19 |
blackburn | sonne|work: what is 4) option? | 11:19 |
sonne|work | 4) Introduce apply_binary(), apply_multiclass(), apply_regressor() to respective machines needing it. In addition we could have constructors in respective labels e.g. CBinaryLabels(CLabels* labels). In addition, one uses typemaps to %rename apply methods of CMachine etc and creates an apply method for each machine realization like LibLinear, LiblinearRegression returning the correct type always. | 11:19 |
sonne|work | scratch constructors | 11:19 |
sonne|work | converters like in n4nd0's pull requrest | 11:20 |
blackburn | it is very similar to just add apply in appropriate machines | 11:21 |
sonne|work | blackburn: yes - but from the C++ side we still have the CMachine::apply() interface | 11:21 |
blackburn | do we really need it? | 11:22 |
sonne|work | it is like having train() IMHO | 11:23 |
sonne|work | the essence of a machine | 11:23 |
sonne|work | being able to train() and apply() | 11:23 |
blackburn | %rename is confusing then | 11:23 |
sonne|work | I don't think so: | 11:24 |
sonne|work | we only need this for languages that don't support types | 11:24 |
sonne|work | and type casts | 11:24 |
sonne|work | so for such $LANG it is still the same principle | 11:24 |
sonne|work | you call apply() on a machine and get the correct label type | 11:25 |
sonne|work | all others cast as necessary | 11:25 |
n4nd0 | I actually like this strategy quite a lot :) | 11:28 |
n4nd0 | blackburn: but I know you were not much in favour of casting :S | 11:29 |
sonne|work | n4nd0: btw when you do fixes to a pull request. please use git commit --amend | 11:29 |
sonne|work | so we only have one changelog entry | 11:29 |
n4nd0 | oh sorry, a bit too late for this one | 11:29 |
sonne|work | n4nd0: sure just for the future | 11:30 |
sonne|work | you might need to force push though | 11:30 |
n4nd0 | no problem with amend for commits that have already been pushed? | 11:30 |
n4nd0 | I thought that was not recommended to do | 11:30 |
sonne|work | yeah that is not possible except you overwrite the thing with force push | 11:31 |
blackburn | hahah I ca imagine change log of 2.0 | 11:31 |
blackburn | Dear all, everything is changed | 11:31 |
sonne|work | n4nd0: btw you need to return NULL to suppress the compiler warnings | 11:32 |
sonne|work | blackburn: so can you live with that or not? | 11:32 |
blackburn | sonne|work: yes I can | 11:33 |
sonne|work | yes we can! | 11:33 |
sonne|work | so then not too much changes are required... | 11:33 |
sonne|work | we need n4nd0's patch | 11:33 |
sonne|work | then each machine should have a apply_binary() or so method | 11:34 |
sonne|work | and apply() { return apply_binary(); } etc | 11:34 |
sonne|work | I will add typemaps in the evening and we are back to normal | 11:34 |
blackburn | sonne|work: rather apply(CFeatures* data=NULL) | 11:35 |
sonne|work | or that | 11:35 |
blackburn | no more apply() | 11:35 |
blackburn | :D | 11:35 |
sonne|work | blackburn: can you do these changes? | 11:35 |
blackburn | I removed all of them I think | 11:35 |
blackburn | yes | 11:35 |
sonne|work | the apply_binary | 11:35 |
sonne|work | apply_multiclass | 11:35 |
sonne|work | apply_regression | 11:35 |
sonne|work | blackburn: btw I think we can then even rename CRealLabels to CRegressionLabels | 11:36 |
sonne|work | because everything is in confidences then | 11:36 |
blackburn | yes | 11:36 |
n4nd0 | sonne|work: it should be ok by now | 11:41 |
CIA-113 | shogun: iglesias master * r89a638e / (2 files): + helper function to obtain MulticlassLabels from Labels, - previous constructor - http://git.io/Cl5hIA | 11:41 |
CIA-113 | shogun: iglesias master * r5f02a4a / (2 files): + constructor from base class in multiclass labels - http://git.io/YDdU3w | 11:41 |
CIA-113 | shogun: iglesias master * r4562bc0 / (6 files): + obtain from generic Labels in sub-label classes - http://git.io/HO5-0g | 11:41 |
n4nd0 | though the warnings didn't pop up here before | 11:41 |
CIA-113 | shogun: Soeren Sonnenburg master * r6630435 / (6 files): Merge pull request #537 from iglesias/fix-labels - http://git.io/VWH_yA | 11:41 |
n4nd0 | I included the last changes using amend :D | 11:41 |
sonne|work | n4nd0: so did you need to force push? | 11:42 |
n4nd0 | yes | 11:43 |
blackburn | instead of force push you also can git push :branchname and git push branchname | 11:43 |
n4nd0 | I think it does something similar internally | 11:45 |
sonne|work | blackburn: ok so if you can please try to do the changes to all the machines... I will do typemaps this evening but now I have to eat/work for real :D | 11:45 |
blackburn | ok I'll have to go in a hour I hope to get it changed | 11:46 |
n4nd0 | sonne|work: about the optimization problem, I understand by the mails that we skip that constraints for the moment and go with libqp right? | 11:46 |
n4nd0 | brb | 11:47 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 11:47 | |
-!- n4nd0 [~n4nd0@s83-179-44-135.cust.tele2.se] has joined #shogun | 11:48 | |
blackburn | rabotatsch! | 11:48 |
n4nd0 | blackburn, have you got your packet today? | 11:50 |
blackburn | n4nd0: yes just 20 mins before | 11:50 |
n4nd0 | nice | 11:51 |
blackburn | n4nd0: didn't you? | 11:52 |
blackburn | n4nd0: but what about apply(idx)? | 11:53 |
blackburn | any conclusion? | 11:53 |
n4nd0 | blackburn, apply(idx) is oficially dead according to the google docs | 11:53 |
blackburn | oh I should check | 11:53 |
n4nd0 | blackburn, yeah, I got the package this morning too | 11:54 |
-!- vikram360 [~vikram360@117.192.169.190] has quit [Ping timeout: 246 seconds] | 11:56 | |
n4nd0 | apply(idx) is still alive in the code though | 11:56 |
blackburn | hmm I will remove it then | 11:56 |
blackburn | karlnapf: hey what about apply_locked? | 11:59 |
karlnapf | blackburn, sorry? | 12:00 |
karlnapf | about the labels in apply_locked? | 12:00 |
blackburn | karlnapf: apply -> apply_binary, apply_regression, .. | 12:00 |
blackburn | yes | 12:00 |
blackburn | what about apply_locked then | 12:00 |
karlnapf | I think thats straightforward | 12:00 |
blackburn | apply_locked_binary? | 12:00 |
karlnapf | just like in apply | 12:00 |
blackburn | oh my gosh | 12:00 |
karlnapf | mmh | 12:01 |
blackburn | I hate adding new code :D | 12:01 |
karlnapf | not too nice all these new methods :) | 12:01 |
blackburn | not really I even like it in some way | 12:03 |
blackburn | you can use your trained svm for regression | 12:03 |
blackburn | :D | 12:03 |
karlnapf | lol :) | 12:06 |
sonne|work | blackburn, karlnapf: how about adding a boolean to apply then? | 12:49 |
blackburn | boolean?? | 12:49 |
sonne|work | I mean that would then say locked=true? | 12:49 |
karlnapf | locked/non-locked? | 12:49 |
sonne|work | yeah | 12:49 |
sonne|work | n4nd0: I discussed with nico on th ephone | 12:49 |
karlnapf | what about even making this automatic? | 12:49 |
karlnapf | ah | 12:50 |
karlnapf | the signature is different | 12:50 |
sonne|work | n4nd0: so as reference you can implement sth based on mosek #ifdef HAVE_MOSEK though | 12:50 |
karlnapf | apply_locked has indices paramteers | 12:50 |
n4nd0 | sonne|work, all right, thank you | 12:51 |
sonne|work | karlnapf: well if you just pass empty indices it would work or? | 12:51 |
karlnapf | but apply then needs to have indices as parameter doesnt it? | 12:51 |
blackburn | sonne|work: are you ok removing apply(idx)? | 12:51 |
sonne|work | blackburn: from CMachine yes | 12:53 |
sonne|work | iirc I commented it already | 12:53 |
sonne|work | so it is RIP already | 12:53 |
blackburn | no | 12:53 |
sonne|work | but other machines can still use it | 12:53 |
blackburn | you remember it wrong | 12:53 |
blackburn | :) | 12:53 |
sonne|work | what? | 12:53 |
* sonne|work checks | 12:53 | |
blackburn | you commented get_label | 12:54 |
sonne|work | ahh | 12:54 |
sonne|work | ok | 12:54 |
sonne|work | same thing | 12:54 |
sonne|work | yes die die | 12:54 |
blackburn | I am confused | 12:54 |
sonne|work | blackburn: btw some commit must have increased shogun repository size quite a bit | 12:54 |
blackburn | I removed apply from linear machine already | 12:54 |
sonne|work | I suspect that someone added a dataset to shogun | 12:55 |
blackburn | sonne|work: yes, that commit of gunnar's student | 12:55 |
sonne|work | and then removed it | 12:55 |
blackburn | yes I removed | 12:55 |
sonne|work | dammed | 12:55 |
sonne|work | we cannot remove it from git now | 12:55 |
blackburn | I realized it is bad later :( | 12:55 |
sonne|work | we have serious trouble on buildbots due to it | 12:55 |
blackburn | bad bad | 12:56 |
blackburn | sonne|work: so it is something like +100 mb now? | 12:57 |
sonne|work | and everyone cloning shogun will not just get a few MB like before but over hundred I guess | 12:57 |
blackburn | yes was something like 139 | 12:58 |
blackburn | shit | 12:58 |
blackburn | we can't keep it | 12:58 |
sonne|work | blackburn: we would have to rewrite all git history to get rid of it | 12:58 |
sonne|work | invalidating all checkouts watches etc | 12:59 |
blackburn | http://vkokoce.com/wp-content/uploads/2012/03/1317350717_facepalm_3.jpg | 12:59 |
sonne|work | blackburn: do you remember the path of the file? | 13:00 |
blackburn | yes | 13:00 |
blackburn | applications/asp/data | 13:00 |
sonne|work | ok good we will have to do that after labels are good | 13:00 |
blackburn | eb07b040ce533393043d9b3241e79a62e8f390ba | 13:02 |
blackburn | .git is 150M | 13:05 |
blackburn | sonne|work: it seems filter-branch can save us | 13:06 |
sonne|work | blackburn: later | 13:07 |
sonne|work | now labels :) | 13:07 |
blackburn | ok | 13:07 |
-!- karlnapf [~heiko@host86-176-253-113.range86-176.btcentralplus.com] has quit [Quit: Leaving.] | 13:24 | |
sonne|work | blackburn: could we do apply(data=NULL, subset=SGVector<index_t>()) ? | 13:26 |
sonne|work | instead of having additional locked stuff? | 13:26 |
blackburn | sonne|work: why not | 13:26 |
blackburn | bad protocol though | 13:27 |
blackburn | ah no | 13:27 |
blackburn | it is ok | 13:27 |
sonne|work | locked does sth else or? | 13:27 |
blackburn | something like that I think | 13:27 |
blackburn | ok be back in 2 hrs | 13:31 |
n4nd0 | StructuredLabels adapted to the new labels hierarchy :D | 14:00 |
n4nd0 | there are probably missing things and so on but it is a good step I guess | 14:01 |
sonne|work | n4nd0: yeah we should get going | 14:03 |
sonne|work | btw today is the first official gsoc day right? | 14:03 |
n4nd0 | yes | 14:04 |
n4nd0 | I will be back later | 14:04 |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 14:05 | |
-!- wiking [~wiking@vpna132.ugent.be] has joined #shogun | 14:06 | |
-!- wiking [~wiking@vpna132.ugent.be] has quit [Changing host] | 14:06 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 14:06 | |
-!- n4nd0 [~n4nd0@s83-179-44-135.cust.tele2.se] has quit [Ping timeout: 245 seconds] | 14:08 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 14:14 | |
-!- vikram360 [~vikram360@117.192.170.250] has joined #shogun | 14:15 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 252 seconds] | 14:18 | |
-!- wiking_ is now known as wiking | 14:18 | |
-!- eric_ [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has quit [Quit: Page closed] | 14:25 | |
-!- vikram360 [~vikram360@117.192.170.250] has quit [Ping timeout: 260 seconds] | 14:34 | |
-!- vikram360 [~vikram360@117.192.179.211] has joined #shogun | 14:34 | |
-!- eric___ [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has joined #shogun | 14:52 | |
eric___ | hi again all | 14:52 |
sonne|work | re | 15:11 |
eric___ | sonne|work: will you integrate a way to import/export samples features with their multiclasslabels ? | 15:18 |
eric___ | maybe there is smth that already exist ? | 15:18 |
sonne|work | eric___: I don't know what you are saying | 15:18 |
eric___ | I look over all shogun examples and I don't find loading/saving example for Features and associated Labels | 15:20 |
sonne|work | you have to same them separately | 15:21 |
sonne|work | or use libsvm format | 15:21 |
eric___ | I wrote my own export/import to/from xml files and fill the CLabel, Features manually | 15:21 |
-!- gsomix [~gsomix@85.26.165.69] has joined #shogun | 15:49 | |
gsomix | hi all | 15:49 |
sonne|work | hi gsomix | 15:50 |
sonne|work | how is it going? | 15:50 |
gsomix | sonne|work, on the way of improving director kernel. | 15:51 |
sonne|work | gsomix: err? | 15:52 |
sonne|work | I thought the plan was to do it in isolated steps? | 15:52 |
sonne|work | there is no way you can get director kernel to work directly I would say | 15:53 |
gsomix | sonne|work, hm, ok. | 15:53 |
gsomix | I did 1-6 steps. | 15:54 |
gsomix | It works fine. | 15:54 |
gsomix | sonne|work, what to do next? | 15:55 |
sonne|work | gsomix: show me the code :) I'd like to play with it too :) | 15:56 |
gsomix | sonne|work, http://pastebin.com/qEx03QYC http://pastebin.com/fe5GhMKb http://pastebin.com/A65g5XN5 | 15:59 |
gsomix | there is one note. swig don't wrap protected methods/attributes without setting "allprotected" property. | 16:01 |
sonne|work | I see so you cannot call/set things | 16:01 |
sonne|work | gsomix: try the simplest possible class in shogun for that | 16:06 |
sonne|work | gsomix: maybe CSet is a good starting point | 16:08 |
sonne|work | or DynamicArray | 16:09 |
gsomix | sonne|work, ok. | 16:10 |
sonne|work | gsomix: when that works try CList | 16:10 |
sonne|work | and then kernel :) | 16:10 |
* gsomix needs to take a shower | 16:11 | |
gsomix | sonne|work, google sent a cool notepad. | 16:12 |
gsomix | it's happy day | 16:12 |
sonne|work | just in time :) | 16:13 |
-!- gsomix [~gsomix@85.26.165.69] has quit [Quit: Ex-Chat] | 16:14 | |
sonne|work | hmmhh, mentors don't get any such toys | 16:26 |
-!- gsomix [~gsomix@83.234.54.15] has joined #shogun | 17:02 | |
-!- gsomix [~gsomix@83.234.54.15] has quit [Remote host closed the connection] | 17:09 | |
@sonney2k | gsomix | 17:10 |
@sonney2k | ../../shogun/lib/DynamicArray.h:188: Warning 509: Overloaded method shogun::CDynamicArray< float64_t >::CDynamicArray(double const *,int32_t) effectively ignored, | 17:10 |
@sonney2k | ../../shogun/lib/DynamicArray.h:102: Warning 509: as it is shadowed by shogun::CDynamicArray< float64_t >::CDynamicArray(double *,int32_t). | 17:10 |
@sonney2k | ahh you escaped | 17:10 |
-!- n4nd0 [~n4nd0@s83-179-44-135.cust.tele2.se] has joined #shogun | 17:10 | |
-!- gsomix [~gsomix@188.168.5.191] has joined #shogun | 17:11 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 17:11 | |
-!- n4nd0 [~n4nd0@s83-179-44-135.cust.tele2.se] has quit [Client Quit] | 17:12 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 17:25 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 17:28 | |
-!- wiking [~wiking@vpnb050.ugent.be] has joined #shogun | 17:29 | |
-!- wiking [~wiking@vpnb050.ugent.be] has quit [Changing host] | 17:29 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 17:29 | |
-!- uricamic [~uricamic@2001:718:2:1634:2030:5375:f044:5459] has quit [Quit: Leaving.] | 17:34 | |
-!- eric___ [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has quit [Quit: Page closed] | 17:55 | |
blackburn | sh took more time | 18:13 |
blackburn | back | 18:13 |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 18:31 | |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 18:31 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 18:31 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 252 seconds] | 18:35 | |
-!- wiking_ is now known as wiking | 18:35 | |
-!- karlnapf [~heiko@host86-176-253-113.range86-176.btcentralplus.com] has joined #shogun | 18:51 | |
@sonney2k | blackburn, if you have something partial to commit please do | 19:03 |
blackburn | sonney2k: yes both kernel and linear machine are ready but distance machine to finish | 19:03 |
blackburn | sonney2k: I can but will be uncompileable | 19:04 |
@sonney2k | blackburn, why? | 19:04 |
@sonney2k | gsomix, <sonney2k> ../../shogun/lib/DynamicArray.h:188: Warning 509: Overloaded method shogun::CDynamicArray< float64_t >::CDynamicArray(double const *,int32_t) effectively ignored, | 19:04 |
@sonney2k | <sonney2k> ../../shogun/lib/DynamicArray.h:102: Warning 509: as it is shadowed by shogun::CDynamicArray< float64_t >::CDynamicArray(double *,int32_t). | 19:04 |
blackburn | sonney2k: because distance machine is not finished yet | 19:04 |
@sonney2k | well you could commit kernel / linear machine only and push | 19:04 |
@sonney2k | then it would compile or? | 19:05 |
@sonney2k | anyway go on | 19:05 |
-!- cronor [~cronor@fb.ml.tu-berlin.de] has quit [Read error: Connection reset by peer] | 19:05 | |
blackburn | sonney2k: no - I changed machine drastically | 19:05 |
@sonney2k | blackburn, uh? | 19:05 |
@sonney2k | blackburn, btw which apply functions do we have now | 19:05 |
-!- cronor [~cronor@fb.ml.tu-berlin.de] has joined #shogun | 19:05 | |
@sonney2k | apply(CFeatures*) ? | 19:05 |
@sonney2k | anything else? | 19:05 |
blackburn | sonney2k: apply(CFeatures* data=NULL) in machine | 19:05 |
blackburn | calls apply_binary | 19:05 |
blackburn | apply_regression | 19:06 |
blackburn | and apply_multiclass | 19:06 |
-!- cronor [~cronor@fb.ml.tu-berlin.de] has quit [Client Quit] | 19:06 | |
blackburn | depends on problem set in machine | 19:06 |
@sonney2k | blackburn, no I mean apply() functions | 19:06 |
@sonney2k | not apply_* functions | 19:06 |
blackburn | ah | 19:06 |
gsomix | sonney2k, ah, ok. I will fix it. | 19:06 |
blackburn | apply(idx) in all submachines like | 19:06 |
blackburn | linear and kernel | 19:06 |
@sonney2k | blackburn, apply(idx) will go away right? | 19:06 |
@sonney2k | in CMachine at least | 19:07 |
blackburn | sonney2k: yes it can go but I did not remove it yet | 19:07 |
blackburn | I removed it in machine already | 19:07 |
blackburn | implementations are based on apply(idx) so would need some refactoring | 19:07 |
@sonney2k | blackburn, so I just rename the apply(CFeatures*) to apply_generic() | 19:07 |
blackburn | huh why? | 19:07 |
@sonney2k | in typemaps | 19:07 |
blackburn | ah | 19:07 |
blackburn | sonney2k: let me finish distance machine | 19:08 |
@sonney2k | be fast | 19:08 |
blackburn | a few mins | 19:08 |
blackburn | damned | 19:13 |
blackburn | domain adaptation stuff | 19:14 |
@sonney2k | hehe | 19:15 |
blackburn | not my | 19:15 |
@sonney2k | blackburn, the buildbot has now twice the diskspace | 19:16 |
blackburn | sonney2k: do you think we can go for removing that commit from history? | 19:17 |
blackburn | ARGH SCATTER SVM | 19:19 |
@sonney2k | blackburn, yes but after labels | 19:19 |
blackburn | sonney2k: argh! CFeatures* data=NULL should have impl in .cpp | 19:21 |
blackburn | ok mostly done | 19:24 |
@sonney2k | yeah | 19:27 |
@sonney2k | ok | 19:28 |
blackburn | sonney2k: apply(idx) -> apply_one(idx) | 19:29 |
blackburn | sonney2k: guess the reason to rename | 19:29 |
-!- gsomix [~gsomix@188.168.5.191] has quit [Quit: Ex-Chat] | 19:30 | |
blackburn | sonney2k: here it goes | 19:35 |
CIA-113 | shogun: Sergey Lisitsyn master * rc3e643d / (19 files in 6 dirs): Refactoring of apply() methods - http://git.io/FtP79w | 19:35 |
-!- gsomix [~gsomix@188.168.14.173] has joined #shogun | 19:41 | |
CIA-113 | shogun: Soeren Sonnenburg master * r8f5bf6e / src/shogun/machine/MulticlassMachine.cpp : apply -> apply_one - http://git.io/T9rYYQ | 19:47 |
blackburn | oops | 19:51 |
blackburn | sonney2k: so what you wanted to commit? | 19:51 |
-!- karlnapf [~heiko@host86-176-253-113.range86-176.btcentralplus.com] has quit [Ping timeout: 276 seconds] | 20:03 | |
CIA-113 | shogun: Soeren Sonnenburg master * r39bb66e / (9 files in 3 dirs): do apply() renames in typemaps + misc fixes in labels - http://git.io/lX0fuA | 20:05 |
@sonney2k | blackburn, running out of battery. | 20:05 |
blackburn | ok I'll continue | 20:06 |
blackburn | sonney2k: ehm why do you add apply in distance machine? it should be done via get_problem_type - I'll change | 20:07 |
@sonney2k | committed | 20:37 |
@sonney2k | blackburn, why did you add apply_binary, apply_multiclass, apply_regression everywhere? | 20:40 |
blackburn | sonney2k: junk | 20:40 |
CIA-113 | shogun: Sergey Lisitsyn master * rb60ea37 / src/shogun/machine/DistanceMachine.h : Replaced apply with apply_one in distance machine - http://git.io/KV7Y4A | 20:40 |
blackburn | sonney2k: before I did it pure virtual in machine | 20:40 |
CIA-113 | shogun: Sergey Lisitsyn master * r615e2bb / .gitignore : Updated gitignore - http://git.io/li60AQ | 20:41 |
@sonney2k | blackburn, you forgot git pull --rebase ... | 20:42 |
blackburn | I did not | 20:42 |
blackburn | I did that | 20:42 |
@sonney2k | blackburn, I meant why do we need apply_binary etc everywhere? | 20:42 |
blackburn | sonney2k: where everywhere? | 20:42 |
@sonney2k | I mean we could just use it for machines where it makes sense | 20:42 |
@sonney2k | in all machines | 20:42 |
blackburn | sonney2k: I am removing it | 20:43 |
@sonney2k | I wouldn't even mention this in CMachine ... | 20:43 |
blackburn | mention what? | 20:43 |
blackburn | ah | 20:43 |
blackburn | apply_binary? | 20:43 |
@sonney2k | I would keep apply() in all machines | 20:43 |
blackburn | hmm why? | 20:44 |
@sonney2k | and return the most general label if there are multiple options | 20:44 |
@sonney2k | blackburn, because one can just call apply() in every machine | 20:44 |
blackburn | yes it inherited from CMachine | 20:44 |
@sonney2k | and one gets the correct label type back | 20:44 |
@sonney2k | but why did you remove it from distance machine then? | 20:45 |
blackburn | sonney2k: I forgot to set problem type as multicalss in distance machine | 20:45 |
blackburn | this way it will call multiclass apply | 20:45 |
@sonney2k | ahh so CMachine calls the apply_* stuff based on problem type? | 20:46 |
blackburn | yes | 20:46 |
@sonney2k | blackburn, btw while you are at it EClassifierType should probably be named EMachineType | 20:47 |
blackburn | ok | 20:47 |
blackburn | sonney2k: I think it should be a macros like | 20:47 |
blackburn | BINARY_CLASSIFIER | 20:47 |
CIA-113 | shogun: Soeren Sonnenburg master * rfd4e728 / (2 files): rename apply -> apply_one - http://git.io/embBkA | 20:48 |
blackburn | hmm | 20:48 |
blackburn | cool | 20:49 |
blackburn | :D | 20:49 |
blackburn | our commits were merged somehow | 20:49 |
@sonney2k | I pushed this quite some time ago... | 20:50 |
blackburn | sonney2k: no merge commit - I did rebase | 20:51 |
@sonney2k | no idea | 20:53 |
@sonney2k | blackburn, will you do the EClassifierType rename or shall I? | 20:54 |
blackburn | sonney2k: already | 20:54 |
@sonney2k | k | 20:54 |
CIA-113 | shogun: Sergey Lisitsyn master * ra9363e1 / (56 files in 10 dirs): Renamed EClassifierType to EMachineType - http://git.io/_kzwyw | 20:55 |
@sonney2k | blackburn, I would change the SG_NOTIMPLEMENTED to some sg_error msg | 20:55 |
@sonney2k | ok? | 20:55 |
blackburn | right | 20:55 |
@sonney2k | in Machine.cpp | 20:55 |
@sonney2k | doing | 20:55 |
blackburn | you? | 20:55 |
@sonney2k | yes | 20:55 |
blackburn | ok | 20:55 |
@sonney2k | blackburn, don't you think we should do the rename CRealLabels -> CRegressionLabels now too? | 20:56 |
blackburn | yes | 20:56 |
blackburn | I'll do | 20:56 |
@sonney2k | k | 20:56 |
CIA-113 | shogun: Sergey Lisitsyn master * r6e7f947 / src/shogun/machine/MulticlassMachine.h : Removed junk methods from multiclass machine - http://git.io/8WqIAA | 20:56 |
CIA-113 | shogun: Soeren Sonnenburg master * r60b2900 / examples/undocumented/python_modular/classifier_libsvm_modular.py : fix libsvm py example - http://git.io/bLmn0g | 20:58 |
CIA-113 | shogun: Soeren Sonnenburg master * r8d2101e / src/shogun/machine/Machine.cpp : output some more reasonable error messages in CMachine::apply_* methods - http://git.io/9mTGPw | 20:58 |
blackburn | uh | 20:58 |
blackburn | we have a few wrong usages of regression labels | 20:59 |
@sonney2k | blackburn, yes | 20:59 |
@sonney2k | many I suspect | 20:59 |
blackburn | I'll fix | 20:59 |
@sonney2k | blackburn, we also need to fix Evaluation ... | 20:59 |
@sonney2k | blackburn, I am doing the typemap stuff | 21:00 |
blackburn | ok | 21:00 |
blackburn | sonney2k: I need to fix Machine.i | 21:06 |
@sonney2k | blackburn, ? | 21:08 |
@sonney2k | fix what? | 21:08 |
blackburn | Real->Regression | 21:08 |
@sonney2k | blackburn, ok do | 21:08 |
blackburn | and add LinearMulticlassMachine | 21:08 |
@sonney2k | blackburn, why is CGaussianNaiveBayes not deriving from MulticlassMachine? | 21:08 |
@sonney2k | blackburn, just do | 21:08 |
blackburn | sonney2k: should be derived | 21:08 |
@sonney2k | blackburn, please do so too then | 21:09 |
@sonney2k | blackburn, CQDA should derive from MC then too | 21:09 |
blackburn | just like conjugate shit | 21:09 |
@sonney2k | blackburn, please push when you are done touching Machine.i | 21:12 |
@sonney2k | I'd like to continue there | 21:12 |
blackburn | 30 sec | 21:12 |
blackburn | done | 21:13 |
blackburn | ehm | 21:13 |
blackburn | done | 21:13 |
CIA-113 | shogun: Sergey Lisitsyn master * rd91047e / (44 files in 12 dirs): Renamed RealLabels to RegressionLabels - http://git.io/-XX30Q | 21:13 |
blackburn | sonney2k: I want to add new class between GNB and MulticlassMachine | 21:18 |
blackburn | to avoid adding stuff like prepare_machines, etc | 21:19 |
@sonney2k | blackburn, what label type should a one class machine return? | 21:19 |
@sonney2k | err LibSvmOneclass | 21:19 |
blackburn | binary I think? | 21:19 |
blackburn | PlainMulticlassMachine? | 21:19 |
blackburn | are you ok with naming? | 21:20 |
@sonney2k | blackburn, what is plainmulticlassmachine? | 21:20 |
@sonney2k | TrueMulticlassMachine? | 21:20 |
@sonney2k | I mean one that natively does MC? | 21:20 |
blackburn | yes | 21:20 |
@sonney2k | well then True or NativeMulticlassMachine | 21:20 |
blackburn | GNB, ConjugateIndex | 21:20 |
blackburn | oh native ok | 21:20 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 21:21 | |
@sonney2k | argh | 21:25 |
@sonney2k | I need a macro for doing that rename stuff | 21:26 |
@sonney2k | way too many classes | 21:26 |
blackburn | what do you rename? | 21:26 |
@sonney2k | actually not the rename | 21:26 |
@sonney2k | but the %extend | 21:26 |
blackburn | wait so you add it to every class? | 21:27 |
@sonney2k | blackburn, adding type customized apply's yes | 21:27 |
@sonney2k | all child classes... | 21:27 |
@sonney2k | wiking, where do I have to put the -I include config for the vim plugins to find the shogun headers? | 21:30 |
wiking | sonney2k: in root of shogun dir | 21:31 |
@sonney2k | wiking, how exactly? | 21:31 |
blackburn | Example .clang_complete file: > -DDEBUG -include ../config.h -I../common -I/usr/include/c++/4.5.3/ -I/usr/include/c++/4.5.3/x86_64-slackware-linux/ | 21:31 |
wiking | this is the line in it: -I./src -I/opt/local/include/libxml2 | 21:31 |
wiking | and then i open vim . | 21:31 |
@sonney2k | wait so in shogun/src I create a .clang_complete file? | 21:32 |
wiking | sonney2k: i've created in ./shogun | 21:33 |
wiking | sonney2k: so i have ./shogun/.clang_complete | 21:33 |
blackburn | sonney2k: depends where do you run your vim I think | 21:33 |
@sonney2k | I see | 21:33 |
wiking | blackburn: yep | 21:33 |
@sonney2k | ok works | 21:35 |
@sonney2k | thx | 21:35 |
blackburn | sonney2k: do not forget to put let g:clang_close_preview = 1 to .vimrc | 21:35 |
blackburn | really annoying to see that window above | 21:35 |
blackburn | let g:clang_auto_select=0 is useful too - makes first suggestion selected from the very beginning | 21:36 |
CIA-113 | shogun: Sergey Lisitsyn master * r54eef53 / (5 files in 3 dirs): Made GaussianNaiveBayes a multiclass machine - http://git.io/SS-2Og | 21:37 |
@sonney2k | blackburn, in vimrc ? | 21:37 |
blackburn | sonney2k: yes | 21:39 |
@sonney2k | blackburn, is it possible to use ctrl+space to trigger completion? | 21:39 |
blackburn | sonney2k: yes default is Ctrl+X Ctrl+U | 21:40 |
blackburn | let me find | 21:40 |
blackburn | sonney2k: | 21:41 |
blackburn | 88 inoremap <expr> <buffer> <C-X><C-U> <SID>LaunchCompletion() | 21:41 |
blackburn | clang_complete/plugin/clang_complete.vim:88 | 21:41 |
blackburn | sonney2k: try to change that | 21:41 |
@sonney2k | well I failed but lets continue for now | 21:44 |
-!- vikram360 [~vikram360@117.192.179.211] has quit [Ping timeout: 246 seconds] | 21:44 | |
blackburn | sonney2k: | 21:46 |
blackburn | 88 inoremap <expr> <buffer> <C-space> <SID>LaunchCompletion() | 21:46 |
blackburn | 89 imap <C-@> <C-space> | 21:46 |
blackburn | works | 21:46 |
-!- ckwidmer [~chris@HSI-KBW-046-005-237-106.hsi8.kabel-badenwuerttemberg.de] has joined #shogun | 21:50 | |
@sonney2k | blackburn, seems like c-space is doing sth already here | 21:55 |
@sonney2k | pasting marked text | 21:55 |
@sonney2k | no idea how to undefine that | 21:56 |
blackburn | 41 imap <Nul> <Space> | 21:56 |
blackburn | 42 map <Nul> <Nop> | 21:56 |
blackburn | 43 vmap <Nul> <Nop> | 21:56 |
blackburn | 44 cmap <Nul> <Nop> | 21:56 |
blackburn | 45 nmap <Nul> <Nop> | 21:56 |
blackburn | ~ | 21:56 |
blackburn | sonney2k: ^ to .vimrc | 21:56 |
blackburn | it seems I know everything :D lol | 21:56 |
@sonney2k | what is that doing? | 21:56 |
blackburn | sonney2k: undefining C+space | 21:56 |
@sonney2k | 5 lines jsut for that? | 21:57 |
blackburn | sonney2k: different modes | 21:57 |
blackburn | insert, visual, .. you know | 21:57 |
@sonney2k | blackburn, bah still doesn't work | 22:00 |
@sonney2k | now c-space doesn't do anything | 22:00 |
blackburn | did you add imap <C-@> <C-space> to clang_complete.vim? | 22:01 |
@sonney2k | no | 22:01 |
@sonney2k | I don't have that line | 22:01 |
blackburn | (11:46:47 PM) blackburn: 88 inoremap <expr> <buffer> <C-space> <SID>LaunchCompletion() | 22:01 |
blackburn | (11:46:47 PM) blackburn: 89 imap <C-@> <C-space> | 22:01 |
blackburn | it should look like that | 22:01 |
@sonney2k | works! | 22:02 |
@sonney2k | thx | 22:02 |
@sonney2k | and now back to ... | 22:02 |
blackburn | yeah | 22:02 |
-!- cronor [~cronor@e177093001.adsl.alicedsl.de] has joined #shogun | 22:03 | |
@sonney2k | blackburn, did you 'fix' GPs too? | 22:09 |
@sonney2k | gaussianprocessregression that is | 22:09 |
blackburn | sonney2k: why it needs a fix? | 22:11 |
@sonney2k | let me do it | 22:15 |
blackburn | I am moving QDA right now | 22:15 |
blackburn | oh and we need to indicate problem types in each machine | 22:15 |
@sonney2k | blackburn, ...and fix evaluations | 22:17 |
blackburn | yes | 22:17 |
@sonney2k | blackburn, what if a machine can handle two problem types? | 22:17 |
blackburn | sonney2k: just call appropriate | 22:17 |
@sonney2k | ? | 22:18 |
blackburn | apply_regression | 22:18 |
blackburn | or apply_binary | 22:18 |
@sonney2k | I mean when indicating problem type | 22:18 |
blackburn | or.. do you hide it? | 22:18 |
blackburn | what is the example of two problems? | 22:18 |
@sonney2k | liblinear, libsvm ... I mean ok we can split them up to make things explicit | 22:18 |
blackburn | split? | 22:19 |
blackburn | sonney2k: problem type is something by default I think | 22:19 |
CIA-113 | shogun: Soeren Sonnenburg master * r7407407 / (11 files in 5 dirs): introduce macros to easy apply renaming - http://git.io/lMumfw | 22:20 |
@sonney2k | blackburn, no I mean if liblinear (in one class) handles regression, classification, multiclass | 22:20 |
@sonney2k | then we cannot set problem type in constructor | 22:20 |
blackburn | sonney2k: no way | 22:21 |
blackburn | :D | 22:21 |
blackburn | we already have splitted that | 22:21 |
@sonney2k | so we need to split it up | 22:21 |
@sonney2k | yeah | 22:21 |
blackburn | multiclass machines are totally different | 22:21 |
@sonney2k | fixing typemaps seems quite easy with these macros | 22:21 |
@sonney2k | not a lot of work now | 22:21 |
blackburn | and even multiclass part of liblinear is not related at all | 22:21 |
@sonney2k | let me get a few python examples to work | 22:21 |
@sonney2k | blackburn, btw do libshogun examples work already? | 22:22 |
blackburn | no I don't think they work at all | 22:22 |
@sonney2k | blackburn, evaluation / model selection certainly not | 22:22 |
@sonney2k | but the rest? | 22:23 |
* sonney2k checks | 22:23 | |
@sonney2k | blackburn, indeed - but they are trivially fixed | 22:27 |
@sonney2k | doing | 22:27 |
blackburn | I am little stucked with qda right now | 22:28 |
CIA-113 | shogun: Sergey Lisitsyn master * re9382f3 / (8 files in 3 dirs): Rebased QDA - http://git.io/7F20NQ | 22:35 |
n4nd0 | blackburn: speaking of which, I started to move it to multiclass this morning but faced some errors I didn't quite manage to solve | 22:36 |
blackburn | n4nd0: already | 22:36 |
n4nd0 | blackburn: cool, thank you! | 22:36 |
blackburn | hmm while you appeared | 22:36 |
n4nd0 | sorry I didn't get it done | 22:36 |
blackburn | I would like to get you loaded :D | 22:36 |
n4nd0 | loaded of what man? | 22:36 |
n4nd0 | haha | 22:36 |
blackburn | heh yeah not the best wording | 22:37 |
blackburn | lets say overloaded | 22:37 |
n4nd0 | tell me | 22:37 |
blackburn | hmm | 22:37 |
blackburn | okay could you please add proper get_problem_type to *every* classifier? :D | 22:38 |
n4nd0 | ok | 22:38 |
n4nd0 | what are the possibilities | 22:38 |
n4nd0 | some according to labels? | 22:38 |
n4nd0 | like multiclass, binary | 22:38 |
n4nd0 | or? | 22:38 |
@sonney2k | blackburn, MulticlassMachines have no apply_one? | 22:39 |
blackburn | n4nd0: check CMachine | 22:39 |
n4nd0 | blackburn: ok | 22:39 |
blackburn | sonney2k: hmm it has I think | 22:39 |
@sonney2k | blackburn, please check - I am getting compile errros there | 22:44 |
blackburn | checking | 22:45 |
blackburn | sonney2k: works | 22:50 |
@sonney2k | n4nd0, python examples also need some treatment | 22:52 |
blackburn | HEAVY MEDICAL TREATMENT | 22:53 |
n4nd0 | yeah | 22:53 |
blackburn | oh n4nd0 sorry I need to clarify | 22:53 |
blackburn | just 5 mins | 22:53 |
@sonney2k | should be easy though | 22:53 |
n4nd0 | sonney2k: what about the swig functions we talked about? | 22:53 |
n4nd0 | are they ready or something done? | 22:53 |
@sonney2k | n4nd0, they are all ready | 22:54 |
n4nd0 | the ones for ignore apply and apply_binary & co. | 22:54 |
n4nd0 | awesome | 22:54 |
@sonney2k | much easier than expected | 22:54 |
blackburn | gsomix: ping | 22:54 |
@sonney2k | gsomix is hiding all day | 22:55 |
@sonney2k | err afternoon-> evening | 22:55 |
n4nd0 | blackburn: tell me when you get time since I have already started including methods | 22:55 |
@sonney2k | blackburn, could you please look at the libshogun classifier_multiclasslibsvm example? | 22:56 |
blackburn | n4nd0: I think you'd rather should add a macros for that | 22:56 |
@sonney2k | apply_one doesn' t exist there | 22:56 |
n4nd0 | blackburn: why? | 22:56 |
blackburn | n4nd0: less code | 22:56 |
n4nd0 | isn't it more typical around here to use methods? | 22:56 |
n4nd0 | like get_name and the like | 22:57 |
blackburn | n4nd0: yes macros hiding method | 22:57 |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 22:57 | |
gsomix | blackburn, wut? | 22:59 |
n4nd0 | blackburn: somethind like http://snipt.org/ujTc3 | 22:59 |
n4nd0 | ?? | 22:59 |
blackburn | n4nd0: exactly | 23:00 |
blackburn | but naming could be just MULTICLASS_MACHINE | 23:00 |
blackburn | BINARY_MACHINE | 23:00 |
blackburn | REGRESSION_MACHINE | 23:00 |
n4nd0 | I was thinking to do the macro with an argument | 23:00 |
n4nd0 | you prefer one macro for each? | 23:01 |
blackburn | no preference at all - up to you | 23:01 |
blackburn | param macro is ok I think | 23:01 |
@sonney2k | blackburn, had a look? | 23:01 |
blackburn | argh sec | 23:01 |
blackburn | sonney2k: what is the problem? | 23:02 |
blackburn | line 50 apply(i)? | 23:02 |
-!- wiking [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 23:05 | |
-!- wiking [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 23:05 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 23:05 | |
blackburn | gsomix: what do you do? | 23:06 |
blackburn | optics is not the anwer | 23:06 |
gsomix | blackburn, warnings. fixing swig warnings. | 23:07 |
CIA-113 | shogun: Soeren Sonnenburg master * r4830bda / (16 files): various fixes for libshogun examples - http://git.io/t2NTaQ | 23:07 |
CIA-113 | shogun: Soeren Sonnenburg master * rc54276b / (9 files): fix remaining libshogun examples for new label system - http://git.io/i_LzSQ | 23:07 |
@sonney2k | blackburn, do we have apply_one there or what? | 23:08 |
gsomix | blackburn, I'm reading some docs about renaming and ignoring. | 23:08 |
blackburn | sonney2k: yes apply_one instead of apply I think | 23:08 |
@sonney2k | blackburn, but we have apply_one there | 23:09 |
@sonney2k | already I mean | 23:09 |
@sonney2k | it doesn't compile though becauce mc machine doesn't have it | 23:10 |
@sonney2k | so please check | 23:10 |
@sonney2k | most of the exmaples work now but these and the evaluation based ones / train/apply_locked ones | 23:10 |
blackburn | oops | 23:10 |
blackburn | who stole it? | 23:10 |
blackburn | I? | 23:10 |
@sonney2k | certainly not me | 23:11 |
blackburn | ok let me get it back | 23:11 |
n4nd0 | blackburn: I have just seen an small PR | 23:13 |
n4nd0 | blackburn: check it and tell if you like it like that and I will continue to the other machines | 23:13 |
blackburn | ok a min | 23:13 |
CIA-113 | shogun: Soeren Sonnenburg master * r1a6ae98 / (3 files): rename apply(idx) -> apply_one(idx) - http://git.io/-bYF2Q | 23:16 |
CIA-113 | shogun: Soeren Sonnenburg master * r5f9d58b / (11 files): fix various python examples - http://git.io/cBOAog | 23:17 |
blackburn | arght that conflicts with my commit | 23:17 |
@sonney2k | urgs I have to sleep now or I will die tomorrow | 23:17 |
@sonney2k | cu | 23:17 |
blackburn | see you | 23:17 |
blackburn | okay and I am the olny one left :D | 23:17 |
blackburn | w/ commit rights | 23:18 |
n4nd0 | sonney2k: good night | 23:19 |
blackburn | n4nd0: sorry a little more | 23:21 |
n4nd0 | no problem | 23:21 |
blackburn | n4nd0: yes continue with it please | 23:22 |
@sonney2k | blackburn, btw why not have a get_problem_type() in CMachine | 23:22 |
blackburn | sonney2k: ?? :D | 23:23 |
blackburn | sonney2k: it is here | 23:23 |
blackburn | returns PT_BINARY | 23:23 |
@sonney2k | have a EProblemType machine_type member variable | 23:23 |
@sonney2k | and just set the variable in constructors | 23:23 |
@sonney2k | or even better init() | 23:23 |
blackburn | I think virtual method is better for that | 23:23 |
blackburn | variable is pretty redundant | 23:24 |
* sonney2k checks how we do it with Features | 23:24 | |
@sonney2k | get_feature_type()=0... | 23:24 |
@sonney2k | ok | 23:24 |
blackburn | sonney2k: member is always harder to maintain I think | 23:25 |
blackburn | okay apply_one is here again | 23:25 |
CIA-113 | shogun: Sergey Lisitsyn master * re496dce / (2 files): Restored apply_one method of multiclass machine - http://git.io/c-inWg | 23:25 |
@sonney2k | blackburn, yeah but please make it pure virtual - otherwise it is tough to debug why apply() is failing and if we missed a case | 23:26 |
blackburn | ?? | 23:27 |
@sonney2k | or at least SG_ERROR | 23:27 |
blackburn | what should be pure virtual? | 23:27 |
@sonney2k | get_machine problem type returns PT_BINARY | 23:27 |
@sonney2k | by default | 23:27 |
blackburn | ah | 23:27 |
@sonney2k | that is not good | 23:27 |
blackburn | yes should be pure virtual | 23:27 |
@sonney2k | it is hard to detect | 23:27 |
n4nd0 | I will remove that right now | 23:27 |
@sonney2k | SG_ERROR() or =0 | 23:27 |
blackburn | but I can't remove it before *ALL* machines | 23:27 |
blackburn | are marked | 23:27 |
@sonney2k | all multiclass examples still die | 23:29 |
blackburn | sonney2k: I thought you went to bed :) | 23:30 |
n4nd0 | I am going to bed soon too, too tired today :S | 23:31 |
n4nd0 | blackburn: this can wait until tomorrow or? | 23:31 |
blackburn | n4nd0: yes | 23:31 |
blackburn | I think yes | 23:31 |
n4nd0 | great | 23:31 |
@sonney2k | blackburn, you know I am like chuck norris: I can program while asleep | 23:32 |
blackburn | hehe would be cool actually | 23:32 |
@sonney2k | blackburn, examples fail because e.g. QDA has PT_BINARY | 23:32 |
blackburn | however my dreams are usually about some crazy shit like cat becoming jelly | 23:33 |
blackburn | so my code would be bad I think | 23:33 |
n4nd0 | wtf | 23:33 |
n4nd0 | jelly? why?! | 23:33 |
blackburn | n4nd0: no idea I had one dream like that day before yesterday | 23:33 |
n4nd0 | :DD never heard that in my life | 23:33 |
@sonney2k | blackburn, it is the shogun cat dissolving | 23:33 |
CIA-113 | shogun: Soeren Sonnenburg master * r8d4b65b / (4 files): fix a few MC examples - http://git.io/ZVhFFQ | 23:34 |
@sonney2k | ok some work now | 23:34 |
@sonney2k | rest is probably LT_BINARY crap due to wrong problem type | 23:34 |
* sonney2k off | 23:35 | |
n4nd0 | well good night guys | 23:35 |
blackburn | good night | 23:35 |
blackburn | I tihkn I have one more hour to code | 23:35 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 23:35 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 23:39 | |
blackburn | hmm ok let me fix evaluations then | 23:41 |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 245 seconds] | 23:42 | |
-!- wiking_ is now known as wiking | 23:42 | |
--- Log closed Tue May 22 00:00:05 2012 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!