| --- Log opened Thu Jun 13 00:00:43 2013 | ||
| -!- iglesiasg [d58f3258@gateway/web/freenode/ip.213.143.50.88] has quit [Quit: Page closed] | 00:38 | |
| @wiking | okey | 00:41 |
|---|---|---|
| @wiking | i think i have bagging done | 00:41 |
| -!- travis-ci [~travis-ci@ec2-23-23-10-96.compute-1.amazonaws.com] has joined #shogun | 01:14 | |
| travis-ci | [travis-ci] it's Viktor Gal's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/8034062 | 01:14 |
| -!- travis-ci [~travis-ci@ec2-23-23-10-96.compute-1.amazonaws.com] has left #shogun [] | 01:14 | |
| -!- HeikoS [~heiko@nat-189-140.internal.eduroam.ucl.ac.uk] has joined #shogun | 01:30 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 01:30 | |
| -!- HeikoS [~heiko@nat-189-140.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 01:41 | |
| shogun-buildbot | build #426 of nightly_default is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/426 | 03:45 |
| -!- nube [~rho@49.244.81.158] has quit [Quit: Leaving.] | 04:49 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 05:41 | |
| -!- nube [~rho@116.90.239.3] has quit [Ping timeout: 246 seconds] | 06:18 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 07:11 | |
| -!- Yanglittle [deb20af8@gateway/web/freenode/ip.222.178.10.248] has joined #shogun | 08:12 | |
| -!- lambday [67157f4e@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.127.78] has joined #shogun | 08:19 | |
| lambday | sonney2k: sonne|work: morning :) | 08:21 |
| Yanglittle | hey, i have a problem. I download the fm_train_real.dat and fm_test_real.dat, and run chi2square it says "can't convert string to float" | 08:27 |
| sonne|work | lambday: hey good morning! | 08:38 |
| sonne|work | lambday: and moin moin too :D | 08:41 |
| lambday | sonne|work: morgen morgen :D | 08:41 |
| sonne|work | hehe | 08:43 |
| -!- lambday [67157f4e@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.127.78] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 08:54 | |
| -!- patrickp [~patrickp@84-75-165-165.dclient.hispeed.ch] has joined #shogun | 09:00 | |
| -!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has joined #shogun | 09:02 | |
| hushell | Morning, guys | 09:02 |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 09:02 | |
| @iglesiasg | hushell, patrickp hi! | 09:02 |
| @iglesiasg | sorry for the delay :S | 09:02 |
| patrickp | iglesiasg: hi, no worries, also just joined 2 mins ago | 09:03 |
| hushell | iglesiasg: You said hi to me last week, but I missed :( | 09:03 |
| @iglesiasg | hushell: yeah! I was going to ask you something about optimization | 09:03 |
| @iglesiasg | but I ended up convincing myself about it :) | 09:04 |
| hushell | iglesiasg: I am not very familiar with opt :( | 09:04 |
| hushell | iglesiasg: about SSVM? | 09:04 |
| @iglesiasg | hushell: it was something about the cutting plane algorithm for SSVM | 09:04 |
| @iglesiasg | yeah | 09:05 |
| @iglesiasg | but never mind, it is fine now :) | 09:05 |
| hushell | iglesiasg: then I know a little bit :) | 09:05 |
| hushell | But I am sure Patrick knows much more than me | 09:05 |
| patrickp | iglesiasg: for next time, feel free to send me an email, I'll try to answer in a timely manner :) | 09:06 |
| @iglesiasg | hushell, patrickp so how is it going with the design of the SO project? | 09:06 |
| @iglesiasg | patrickp: ok, I will do, thanks! | 09:06 |
| hushell | patrickp: Did you send them the newest doc? | 09:06 |
| patrickp | nope, not yet, sorry | 09:07 |
| patrickp | https://docs.google.com/document/d/1xkJ1N4nV3rJrDJwvp4IdKwGStlmBDbcJdcALarL1tV8/edit?usp=sharing | 09:07 |
| patrickp | one thing we still have to figure out: how flexible is CStructuredLabels and CFeatures | 09:08 |
| hushell | yeah, feel free to say something about the new plan | 09:08 |
| @iglesiasg | I am checking the document | 09:09 |
| @iglesiasg | what would you like to do with CStructuredLabels and CFeatures? | 09:09 |
| patrickp | iglesiasg: vector<CStructuredInput> and vector<CStructuredOutput> are placeholders, it might be that CFeatures and CStructuredLabels are sufficient | 09:09 |
| @iglesiasg | ok, was going to ask about that right now :) | 09:10 |
| @iglesiasg | about the second point in idea/motivation | 09:10 |
| @iglesiasg | subclass vs. function pointers | 09:10 |
| patrickp | well, the thing is SOP can be used for very different problems: factor graphs, multi class, parse trees, matchings | 09:11 |
| @iglesiasg | ok, I understand | 09:11 |
| patrickp | it would be good if the "input" and "output" is somewhat flexible | 09:11 |
| hushell | We try to make the things similar as the SVMStruct | 09:11 |
| @iglesiasg | yes, the idea is that one is able to inherit from CStructuredLabels to create labels for these different types of structures | 09:12 |
| patrickp | and I'm not sure what's the best way to support this, an abstract input/output type that we subclass for each problem domain | 09:12 |
| @iglesiasg | patrickp: what could be an alternative? | 09:12 |
| hushell | The struct input and output space are important for such a framework | 09:12 |
| patrickp | that's probably the only solution, yes | 09:13 |
| hushell | iglesiasg: Maybe you can talk about the design you came up last year | 09:13 |
| @iglesiasg | hushell: ok | 09:14 |
| @iglesiasg | so there is this abstract class for the structured model | 09:14 |
| hushell | then we could think about where should be refined, since for the generalized SO, lots of things need to reimplement | 09:14 |
| @iglesiasg | the idea is that for each problem domain you inherit from this class and implement the joint feature map, the loss and the inference | 09:16 |
| patrickp | ok, that seems like what we thought, and what I think we would like to keep | 09:16 |
| @iglesiasg | ok | 09:17 |
| @iglesiasg | now, about parameter estimation | 09:17 |
| @iglesiasg | we have this CStructuredOutputMachine that inherits from CMachine in Shogun | 09:17 |
| patrickp | CMachine is used elsewhere in Shogun, I suppose, right? | 09:18 |
| @iglesiasg | yes, it is used in many places in Shogun | 09:18 |
| @iglesiasg | all the SVMs, many classifiers, etc origin in CMachine | 09:19 |
| sonne|work | patrickp: yeah it is the most generic learning machine | 09:19 |
| patrickp | sorry for the silly questions, still working on getting my head around the shogun sources :) | 09:19 |
| hushell | patrickp: the SOSVM ~= StructuredSVMMachine | 09:19 |
| @iglesiasg | patrickp: sure :) | 09:19 |
| @iglesiasg | in this way you can get nice things working for all the machines e.g. model selection and x-validation | 09:19 |
| patrickp | cool | 09:20 |
| sonne|work | machines basically have train() and apply() functions | 09:20 |
| patrickp | apply = predict? | 09:20 |
| hushell | yep | 09:20 |
| sonne|work | train gets features as input, apply too and returns label | 09:20 |
| patrickp | great, understood | 09:21 |
| sonne|work | whatever label may mean (graphs, vectors ...) | 09:21 |
| sonne|work | patrickp: the name is apply because it is not always prediction - machines could do anything | 09:21 |
| hushell | but why we have m_loss in CStructuredOutputMachine? | 09:21 |
| @iglesiasg | hushell: normally you use the hinge loss, it is not the only choice though | 09:22 |
| patrickp | sonne|work: what do you mean by "do anything"? | 09:22 |
| @iglesiasg | I believe | 09:22 |
| hushell | this could be included in CStructuredModel seems | 09:22 |
| @iglesiasg | hushell: mmmm I am not entirely sure what makes more sense | 09:22 |
| @iglesiasg | it could be, yeah | 09:22 |
| hushell | iglesiasg: because then user can specify loss in his inherited model class | 09:23 |
| hushell | loss seems independent of solver | 09:23 |
| @iglesiasg | hushell: but isn't this loss something that is just used for parameter estimation? | 09:23 |
| patrickp | iglesiasg: currently it seems there is some reference to it in both, no? | 09:23 |
| @iglesiasg | there are two losses in here | 09:24 |
| @iglesiasg | one is the structured or | 09:24 |
| sonne|work | patrickp: on apply machines just do some operation on the data and return a Label object - so they are free to do whatever they want | 09:24 |
| @iglesiasg | sorry, or \Delta loss -- this one is in the structured model | 09:24 |
| @iglesiasg | the most common one here is the Hamming loss | 09:24 |
| patrickp | i see, ok, thanks for the clarification | 09:24 |
| @iglesiasg | but apart from that, you have the loss you use during parameter estimation | 09:25 |
| @iglesiasg | I think you can say it is the loss you use to evaluate the risk you want to minimize during training | 09:25 |
| patrickp | iglesiasg: but do you support anything but max-margin | 09:25 |
| patrickp | otherwise that's true, you can either do max-margin or log-loss or something else | 09:25 |
| @iglesiasg | I am not sure about this, let's ellaborate | 09:26 |
| patrickp | sonne|work, iglesiasg: why are these virtual CBinaryLabels* apply_binary(CFeatures* data=NULL); etc in the CMachine base class? | 09:26 |
| @iglesiasg | patrickp: I think it is because apply in general returns CLabels*, these methods are specialized to return one of the specific types like CBinaryLabels, CMulticlassLabels, CStructuredLabels | 09:27 |
| sonne|work | patrickp: we have an issue with interfaces not supporting any means of casting | 09:28 |
| sonne|work | patrickp: e.g. when using apply() you just get labels back | 09:28 |
| sonne|work | but then you are stuck with a CLabels object in python | 09:28 |
| sonne|work | you cannot cast it into CBinaryLabels | 09:28 |
| sonne|work | because there is no cast | 09:28 |
| patrickp | I see, hmm, but if you would only support C++ you wouldn't need them | 09:28 |
| sonne|work | yes | 09:29 |
| patrickp | just to understand | 09:29 |
| patrickp | great, thanks | 09:29 |
| @iglesiasg | revolution, we throw away the interfaces! :P | 09:29 |
| sonne|work | I think we should move these away - into CLabelsFactory | 09:29 |
| patrickp | :) wasn't saying that, just surprised to see these methods there | 09:29 |
| @iglesiasg | patrickp: just kidding :) | 09:30 |
| sonne|work | patrickp: no no it is awful IMHO and IIRC gsomix has found a way to do that in python | 09:30 |
| sonne|work | I mean transparent | 09:30 |
| sonne|work | so whenever you call apply() it will return the real type | 09:30 |
| patrickp | that sounds good | 09:30 |
| hushell | iglesiasg: Where is the argmax() being used? | 09:31 |
| @iglesiasg | hushell: you use it both doing parameter estimation to solve the loss-augmented inference and in apply | 09:31 |
| hushell | iglesiasg: I mean in solvers like libbmrm | 09:31 |
| @iglesiasg | the apply in SO machines is basically the argmax | 09:31 |
| patrickp | cool, that sounds reasonable | 09:32 |
| hushell | I didn't see this being called | 09:32 |
| @iglesiasg | hushell: in CPrimalMosekSOSVM is there, let me see about BMRM | 09:32 |
| hushell | iglesiasg: in svm_bmrm_solver() I didn't see it | 09:33 |
| @iglesiasg | hushell: I am not familiarized with the BMRMs | 09:33 |
| @iglesiasg | but they are cutting plane methods as well, so they must use them to find the most violated constraints or so | 09:34 |
| hushell | iglesiasg: Sorry I didn't check the mosek one | 09:34 |
| @iglesiasg | hushell: they use them from risk | 09:34 |
| @iglesiasg | in the BMRM | 09:34 |
| @iglesiasg | the use the risk method in the StructuredModel which in turn uses/implements the argmax | 09:35 |
| @iglesiasg | they* | 09:35 |
| @iglesiasg | however it seems to me there is a "risk" of being redundant here | 09:35 |
| @iglesiasg | patrickp: coming back to the loss in the SOMachine again | 09:37 |
| hushell | iglesiasg: I see. Thanks :) | 09:37 |
| patrickp | iglesiasg: waiting for that, yes, i'm curious | 09:37 |
| @iglesiasg | so, even if you are doing max-margin with the SO-SVM | 09:37 |
| @iglesiasg | isn't it possible to use different losses apart from the hinge loss? | 09:38 |
| patrickp | yes, but it should be the same that you define in the model, no? | 09:38 |
| @iglesiasg | no, I don't think so | 09:39 |
| patrickp | i mean max-margin = hinge | 09:39 |
| @iglesiasg | is it? | 09:39 |
| hushell | generalized hinge loss | 09:39 |
| hushell | we can say | 09:39 |
| @iglesiasg | I am not actually sure, I thought one can apply different losses to the max-margin or SVM approach | 09:39 |
| @iglesiasg | not just in structured learning, but in any SVM | 09:39 |
| patrickp | sorry if I am a bit confusing, let me try to clarify | 09:39 |
| @iglesiasg | ok | 09:40 |
| patrickp | what type of loss are you talking about? Hamming, squared etc? | 09:40 |
| patrickp | i.e. Delta(y_gt, y_pred)? | 09:40 |
| @iglesiasg | patrickp: no, not about the Delta loss | 09:41 |
| patrickp | so you are talking about the surrogate loss then | 09:41 |
| patrickp | max-margin, log-loss etc | 09:41 |
| @iglesiasg | it can be | 09:42 |
| @iglesiasg | I am not sure because I probably don't use the right name (surrogate it seems to be) to call them :) | 09:42 |
| patrickp | that's fine, it's a general problem in the field | 09:42 |
| hushell | patrickp: maybe you talk beyond the SSVM, I didn't see people use log-loss for structured learning | 09:42 |
| patrickp | sure, yes, SSVM = max-margin | 09:43 |
| patrickp | there are just two versions: slack and margin rescaling | 09:43 |
| patrickp | but that's about it | 09:43 |
| hushell | for CRF, some people like Michael Collins use the log-loss | 09:43 |
| patrickp | CRF = log-loss | 09:44 |
| @iglesiasg | patrickp: so it doesn't really make sense to train a SSVM using a logistic loss or square loss instead of the hinge loss | 09:44 |
| patrickp | that's the difference between SSVM and CRF, the surrogate loss | 09:44 |
| @iglesiasg | ? | 09:44 |
| hushell | patrickp: SSVM can also used for CRF? Am I right? | 09:44 |
| @iglesiasg | hushell: you can use the SSVM for parameter estimation of CRFs I think | 09:45 |
| hushell | iglesiasg: THis is what I mean | 09:45 |
| patrickp | well, SSVM and CRF in the end do the same thing: they estimate the parameters of a structured model, the difference is the objective used for learning | 09:45 |
| @iglesiasg | hushell: ok | 09:45 |
| @iglesiasg | patrickp: aham | 09:45 |
| patrickp | CRF uses log-loss, SSVM uses max-margin. CRF in the end has a probabilistic interpretation, but you might not care about this too much | 09:46 |
| hushell | patrickp: well, I would like to call CRF a type of graphical model, but I understand what you are saying | 09:46 |
| patrickp | yes, sure. but the terminology is quite loaded. | 09:47 |
| hushell | okay, let's back to Shogun, this seems not big issues | 09:47 |
| patrickp | :) | 09:47 |
| @iglesiasg | I am wondering then, whether it is possible to use the same training algorithm only changing the part where the loss is evaluated | 09:47 |
| hushell | :) good to learn | 09:47 |
| @iglesiasg | indeed :) | 09:47 |
| patrickp | iglesiasg: yes, and no: usually you have a specialized solver for each surrogate loss, depending on its properties | 09:48 |
| patrickp | also, you might need to compute different things from your structured model | 09:48 |
| patrickp | argmax was partition function | 09:49 |
| patrickp | vs. that is | 09:49 |
| hushell | iglesiasg: user need to specify the delta function, but he/she can choose SSVM or CRF to estimate params | 09:49 |
| @iglesiasg | I see | 09:49 |
| hushell | SSVM and CRF use different surrogate losses | 09:50 |
| @iglesiasg | patrickp: so with yes and no you mean there are actually algorithms for parameter estimation that work with different surrogate losses? | 09:50 |
| patrickp | stochastic gradient descent is probably one such example | 09:50 |
| patrickp | should work well with both surrogate losses | 09:51 |
| patrickp | but the surrogate loss computation would require different methods from your structuredmodel | 09:51 |
| @iglesiasg | that is very interesting I think | 09:51 |
| hushell | patrickp: you think we should also implement the log-loss for training? | 09:51 |
| -!- foulwall [~foulwall@li379-21.members.linode.com] has joined #shogun | 09:51 | |
| patrickp | hushell: at least in the beginning I would not go into this | 09:52 |
| -!- Yanglittle [deb20af8@gateway/web/freenode/ip.222.178.10.248] has quit [Ping timeout: 250 seconds] | 09:52 | |
| patrickp | because then you need to support partition function computations in your structured model, which is a pain | 09:52 |
| hushell | So what should we add or modify the the StructuredOutputMachine and StructuredModel? | 09:53 |
| patrickp | ? | 09:53 |
| @iglesiasg | I think the idea is to add other StructuredModels and SOMachines rather, I may be wrong | 09:54 |
| hushell | I mean in the doc, we have the new class SOSVM, this seems the same as CStructuredOutputMachine | 09:54 |
| @iglesiasg | yes, I think there is no need for it. The current should suffice | 09:54 |
| hushell | patrickp: for the partition function, this is all about the inference, I am also curious how many functionality about inference we'd like to add to Shogun | 09:55 |
| @iglesiasg | there is another question in the google docs regarding eigen vectors | 09:56 |
| @iglesiasg | my opinion is use them in your implementation code but try to stick to shogun vectors for the methods that could be used from the interfaces in the other languages | 09:57 |
| patrickp | iglesiasg: thanks for the clarification wrt eigen | 09:58 |
| hushell | iglesiasg: so SGVector is preferred? | 09:58 |
| patrickp | for the interface, i guess | 09:58 |
| patrickp | if you do something internally use eigen, is that right? | 09:58 |
| lisitsyn | yes | 09:58 |
| @iglesiasg | patrickp: yes, internally do it as you prefer | 09:58 |
| @iglesiasg | eigen is probably a good option for it | 09:58 |
| hushell | I see, no confusion for users | 09:59 |
| patrickp | hushell: partition function: i would really concentrate on argmax | 09:59 |
| lisitsyn | we have no typemaps for eigen types | 09:59 |
| lisitsyn | that's why :) | 09:59 |
| @iglesiasg | hushell: exactly, it is a reason for the typemaps rather than confusion | 09:59 |
| @iglesiasg | hushell: with the typemaps I mean | 09:59 |
| @iglesiasg | say you have | 09:59 |
| hushell | :) | 09:59 |
| @iglesiasg | Eigen::Vector get_vector() in a StructuredModel | 10:00 |
| -!- nube [~rho@116.90.239.3] has quit [Ping timeout: 276 seconds] | 10:00 | |
| @iglesiasg | that would probably fail from an interface (say python) if there are no typemaps for Eigen::Vector | 10:00 |
| @iglesiasg | on the other hand, we have typemaps for SGVector so that method could be used in python | 10:01 |
| lisitsyn | iglesiasg: with prob = 1 :D | 10:01 |
| @iglesiasg | and you would get a nice numpy.array | 10:01 |
| @iglesiasg | lisitsyn: :D | 10:01 |
| patrickp | another question: you provide labels/features in structuredModel but also in the Machines | 10:01 |
| patrickp | why this duplication? | 10:01 |
| @iglesiasg | patrickp: yeah, I also wondered about a couple of weeks ago :) | 10:02 |
| patrickp | but that's not some form of convention used in shogun, right? | 10:02 |
| lisitsyn | patrickp: no if it can be unentangled it would be better | 10:02 |
| -!- foulwall [~foulwall@li379-21.members.linode.com] has quit [Ping timeout: 264 seconds] | 10:03 | |
| patrickp | cool, i'm sure one can get rid of it in one place, the question is more where | 10:03 |
| @iglesiasg | patrickp: I think it may be because Machine has an attribute CLabels* m_labels | 10:03 |
| patrickp | hmm, i see | 10:03 |
| @iglesiasg | and since the StructuredOutputMachine inherits from it, it gets it | 10:03 |
| patrickp | same with features? | 10:04 |
| @iglesiasg | because IIRC the duplication is only with labels, isn't it? | 10:04 |
| @iglesiasg | I think it is only with the labels yeah | 10:04 |
| patrickp | yes, that's probably true, only labels | 10:04 |
| patrickp | hmm, quite ugly :), I'll think about it | 10:05 |
| @iglesiasg | yes | 10:05 |
| hushell | patrickp: CStructuredInput and CStructuredOutput can be just CFeatures and CStructuredLabels? | 10:06 |
| @iglesiasg | patrickp: note that CLinearStructuredOutputMachine's getter and setter for the features is done through the StructuredModel | 10:06 |
| patrickp | hushell: yes, I think so | 10:06 |
| @iglesiasg | so about avoiding the duplication | 10:06 |
| patrickp | iglesiasg: that makes sense, cool, so now I understand this a bit better | 10:06 |
| @iglesiasg | one could either remove the CStructuredLabels in the CStructuredModel | 10:07 |
| hushell | patrickp: great, we are merging to current framework | 10:07 |
| @iglesiasg | which would be easier than removing CLabels in CMachine | 10:07 |
| @iglesiasg | however, at least for me, that would be sort of weird | 10:07 |
| @iglesiasg | since the labels would be in the Machine and the features in the StructuredModel -- I don't like how that would look | 10:07 |
| patrickp | iglesiasg: yes, I agree, have to think about this a bit more | 10:08 |
| @iglesiasg | yes | 10:09 |
| @iglesiasg | I suggest, let's stick to that for the moment and later we can try to improve that | 10:09 |
| patrickp | cool | 10:09 |
| @iglesiasg | IIRC I took care so when you set the labels in the StructuredModel they are also set in the StructuredMachine | 10:09 |
| patrickp | ok, now a more practical question: how should we proceed with the partial "reimplementation": I guess a new feature branch in git, right? | 10:10 |
| @iglesiasg | or maybe I didn't :S | 10:10 |
| @iglesiasg | patrickp: what do you mean with re-implementation? | 10:11 |
| @iglesiasg | make your new stuff? | 10:11 |
| patrickp | cleaning up the SO framework a bit, I still feel there are a bit too many dependencies. But it wouldn't be a new implementation. | 10:12 |
| patrickp | but it might be that we change quite a lot of things and break backwards compatibility, at least for some time. | 10:12 |
| @iglesiasg | aham I understand | 10:12 |
| @iglesiasg | I'd say try to change things so that backwards compatibility is not broken :) but than can be sub-optimal taking into account the new development | 10:13 |
| @iglesiasg | I am unsure actually | 10:14 |
| patrickp | sure, that's a bit my question: I think it might slow down development quite a bit, but maybe we just start off with keeping back-wards compatibility and see how it goes | 10:14 |
| @iglesiasg | the issues that I see are | 10:14 |
| @iglesiasg | patrickp: yes, I like that option better | 10:14 |
| patrickp | and in case it slows shell down too much, we can still switch modes | 10:14 |
| @iglesiasg | yes, I agree | 10:14 |
| @iglesiasg | I will try to get a couple of unit tests done ASAP | 10:15 |
| @wiking | patrickp: start a new branch | 10:15 |
| hushell | I hope would be a problem to merge to old code in the end | 10:15 |
| @iglesiasg | so that we can easily figure out if something old gets broken | 10:15 |
| patrickp | iglesiasg: that would be great | 10:15 |
| hushell | I mean would not be | 10:16 |
| patrickp | branching: well, then maybe the patches might be rather small initially, say "remove-loss-from-machine" | 10:16 |
| @wiking | patrickp: and u can remove the setting of labels/features into the machine itself and keep it in the structmodel... and what u can do (if u want) that set the reference to the labels/features of structmodel to the machine's labels/features classes... | 10:16 |
| @iglesiasg | wiking: but the reference to the labels in the machine is in CMachine | 10:17 |
| @wiking | iglesiasg: and? | 10:17 |
| @iglesiasg | wiking: I guess whole shogun will get broken if we remove that one :D | 10:17 |
| @wiking | iglesiasg: no you don't need to remove that | 10:17 |
| @wiking | but either don't set it | 10:18 |
| @iglesiasg | true | 10:18 |
| @wiking | or if it's really necessary then set it just in the constructor of structedmachine by getting a reference to the labels in structredmodel | 10:18 |
| @iglesiasg | patrickp, wiking the StructureOutputMachine constructor can be easily changed to not accept this argument | 10:18 |
| @iglesiasg | the duplication would still be there... but less visible :) | 10:19 |
| @wiking | but structuredMachine should have something like this as ctor: StructuredMachine(StructuredModel) | 10:19 |
| hushell | If we keep most of things the same in CStructuredModel and CStructuredOutputMachine, shouldn't be many problems, right? | 10:19 |
| @wiking | about the loss function you can argue where u want to put it | 10:19 |
| @iglesiasg | hushell: no, there shouldn't be problems then | 10:19 |
| patrickp | wiking: that's true, passing structured model to the machine makes a lot of sense | 10:19 |
| @wiking | within the model (makes more sense for me) or within the machine | 10:19 |
| patrickp | i would also put it in the model | 10:20 |
| @wiking | so just do that | 10:20 |
| @wiking | it's not breaking anything | 10:20 |
| @wiking | just make sure of those changes... and that's it | 10:20 |
| patrickp | cool, that sounds good | 10:20 |
| @wiking | hushell patrickp both gsocers? | 10:21 |
| patrickp | hushell: shall we make this your first target, so that you get to fiddle around a bit with the structured machine in shogun? | 10:21 |
| patrickp | wiking: hush ell is a grocers, i'm his mentor | 10:21 |
| hushell | wiking: I am the student :) | 10:21 |
| @wiking | patrickp: hehe ok :) | 10:22 |
| @wiking | hushell: ok | 10:22 |
| patrickp | but unfortunately don't know too much about the shogun internals :( | 10:22 |
| hushell | patrickp: good idea | 10:22 |
| @wiking | hushell can u plz tag me in your PRs directly | 10:22 |
| @wiking | hushell: so that i can see immedietly and give you feedback | 10:22 |
| hushell | wiking: ok, once I have one | 10:22 |
| @wiking | as i've been working with structedmachines quite some last year | 10:23 |
| hushell | wiking: Thanks :) | 10:23 |
| @wiking | changed a lot in the codes around october/november | 10:23 |
| hushell | wiking: I see. the latent things | 10:23 |
| @iglesiasg | wiking is the latent guy :D | 10:23 |
| @wiking | hushell: yeah still some git stashes are in my local git repo | 10:24 |
| @wiking | that never got into shogun yet | 10:24 |
| hushell | You did so many things last year :D | 10:24 |
| @wiking | need to fixt that soon | 10:24 |
| patrickp | wiking: I see, ignored the latent things completely so far. | 10:24 |
| patrickp | how far progressed is that | 10:24 |
| @wiking | patrickp: well i have the fully working latentSOmachine here locally | 10:24 |
| hushell | wiking: Did you implement the loss based learning? | 10:24 |
| @wiking | patrickp: works with both of the machines in shogun | 10:25 |
| @wiking | but i had to create for example | 10:25 |
| @wiking | a proxy class | 10:25 |
| @wiking | that proxied between | 10:25 |
| @iglesiasg | hushell, patrickp : regarding the other part of the google doc, the FactorGraph | 10:25 |
| @wiking | StructedModel and LatentModel | 10:25 |
| @wiking | hushell: loss based learning....? where? | 10:25 |
| @iglesiasg | hushell, patrickp : I am not sure inherit from CStructuredModel | 10:26 |
| @wiking | iglesiasg: where's that doc? :) | 10:26 |
| @iglesiasg | if it should* (I am eating words for breakfast :D) | 10:26 |
| hushell | wiking: I remember you referenced a ICML12 paper, Pawan Kumar | 10:26 |
| @iglesiasg | wiking: https://docs.google.com/document/d/1xkJ1N4nV3rJrDJwvp4IdKwGStlmBDbcJdcALarL1tV8/edit# | 10:26 |
| @wiking | hushell: ah yeah | 10:26 |
| @wiking | ok | 10:27 |
| @wiking | i have an objection | 10:27 |
| @wiking | :)))) | 10:27 |
| hushell | iglesiasg: FactorGraph is an application like Multiclass | 10:27 |
| @iglesiasg | aham my understanding about FactorGraphs is limited | 10:28 |
| @wiking | SGVector<float64_t> feature_map(CStructuredInput*, CStructuredOutput*); | 10:28 |
| @wiking | not good idea | 10:28 |
| @iglesiasg | I thought of it like something more general | 10:28 |
| hushell | so we call it general SO problem | 10:28 |
| @iglesiasg | as a data structure basically | 10:28 |
| hushell | HMM, CRF, MRF are basically factor graph | 10:28 |
| hushell | expressed in FG, precisely | 10:29 |
| hushell | wiking: why? | 10:29 |
| @wiking | because the feature_map this way REQUIRES that the mapped feature vector is always a dense vector | 10:29 |
| patrickp | wiking: can you elaborate? | 10:29 |
| @wiking | and this is what i already hated last year | 10:29 |
| patrickp | ah, cool, so what do you suggest? | 10:30 |
| @wiking | because imho it would be a good idea to support both dense and sparse vectors | 10:30 |
| @iglesiasg | SGSparseVector? | 10:30 |
| @wiking | as feature vectors | 10:30 |
| patrickp | sure, that's very true | 10:30 |
| @wiking | this limitation for no reason | 10:30 |
| @wiking | just because of ease of development | 10:30 |
| @wiking | the problem is that we already had last year | 10:30 |
| patrickp | is there a basic vector class that has dense and sparse subclasses? | 10:31 |
| @wiking | that we dont have an abstract class for Vectors | 10:31 |
| patrickp | i see | 10:31 |
| @wiking | patrickp: yep that's the problem | 10:31 |
| hushell | people usually implement two versions, another one for sparse | 10:31 |
| @wiking | yeah | 10:31 |
| @wiking | hushell: but how can you have either one or the other be non-abstract ;) | 10:32 |
| @wiking | or just have 2 of those functions | 10:32 |
| @wiking | in the clasee | 10:32 |
| @wiking | but of course | 10:32 |
| @wiking | here comes the limitation of c++ | 10:32 |
| hushell | wiking: That's true | 10:32 |
| @wiking | same function with different return values are not possible | 10:32 |
| @iglesiasg | wiking: have you tried in any task the joint feature map with sparse and non-sparse vectors? | 10:33 |
| @wiking | i mean you cannot just have SGVector<float64_t> feature_map(CStructuredInput*, CStructuredOutput*); and SGSparseVector<float64_t> feature_map(CStructuredInput*, CStructuredOutput*); | 10:33 |
| @wiking | and one more thing | 10:33 |
| patrickp | yes? | 10:33 |
| @wiking | i would love that the feature_map function's argument | 10:33 |
| @wiking | is more free | 10:33 |
| hushell | then don't return a vector | 10:33 |
| patrickp | even more? like what? | 10:33 |
| @wiking | something like | 10:33 |
| @wiking | ReturnValue featureMap (CStructuredInput*, CStructuredOutput*, ..); | 10:34 |
| @wiking | ReturnValue featureMap (CStructuredInput*, CStructuredOutput*, ...); | 10:34 |
| @wiking | or | 10:34 |
| @wiking | ReturnValue featureMap (CStructuredInput*, CStructuredOutput*, vargs); | 10:34 |
| @wiking | because this way for example the latentSOMachine can use the same StructedModel | 10:35 |
| patrickp | so that you can pass some auxiliary parameters in there? | 10:35 |
| @wiking | but for that i need the feature map to support more than 2 parameters as input | 10:35 |
| @iglesiasg | I guess that is to pass the latent features or so | 10:35 |
| @wiking | since i have the latentVariable as well | 10:35 |
| @wiking | yes | 10:35 |
| patrickp | i see, cool, yeah you mean \phi(x,y,z) | 10:35 |
| @wiking | patrickp: indeed | 10:35 |
| @wiking | \phi(x,h,y) | 10:36 |
| @wiking | where h = latent | 10:36 |
| patrickp | i use z, but doesn't matter ;) | 10:36 |
| @wiking | yeah | 10:36 |
| patrickp | cool, yeah, this makes a lot of sense | 10:36 |
| @wiking | regarding this question: "use of Eigen vectors or rather the ones from shogun" | 10:36 |
| @wiking | some of the SGVector functions are actually wrapped functions of Eigen3 functions for vectors... | 10:37 |
| @wiking | if of course Eigen is available | 10:37 |
| @wiking | "function pointers" = cant do it because of modular interfaces | 10:37 |
| patrickp | thanks for your inputs! | 10:38 |
| @wiking | nw | 10:38 |
| @wiking | i hope i'm not being too redundant, i.e. you already might have heard this answers :P | 10:38 |
| patrickp | wiking: very few, but it's always useful to see a different angle | 10:39 |
| patrickp | wiking: also, what is your experience with CFeatures and CStructuredLabels, are they flexible in your opinion | 10:39 |
| hushell | wiking: what's the ReturnValue you mentioned? a class? | 10:39 |
| @wiking | hushell: yeah some class... now the question is of course SGVector or SGSparseVector or what | 10:40 |
| hushell | wiking: maybe let them all be SGVector | 10:41 |
| @wiking | patrickp: well that's a good question | 10:41 |
| @wiking | hushell: well i would love to be able to return a sparse variant as well :P | 10:41 |
| @wiking | but then again | 10:42 |
| @wiking | dont waste time on that now | 10:42 |
| patrickp | wiking: i definitely agree on the sparse part, but might be tricky. Dynamic typing would be nice, he? | 10:43 |
| hushell | wiking: :D leave this to future | 10:43 |
| @wiking | hushell: yeah something like that | 10:43 |
| @wiking | patrickp: yeah something would be good ;P | 10:43 |
| patrickp | just did something like this in matlab and it was two lines of code ;( | 10:43 |
| patrickp | anyway, back to CFeatures and StructuredLabels | 10:44 |
| patrickp | what's your opinion? | 10:44 |
| @wiking | well atm i dont see a better solution | 10:44 |
| @wiking | but if you have ideas i'm listening :) | 10:44 |
| @wiking | as StructuredLabels can be basically anything | 10:45 |
| @wiking | i dont see a better way to implement it as it is now | 10:45 |
| patrickp | cool, that's good enough, just wanted some opinion of a user | 10:45 |
| @wiking | i mean we need to fit into *Labels class hierarchy of shogun that's for sure | 10:45 |
| @iglesiasg | I don't really see why to concern about the flexibility here, I mean is it something that looks like a limitation | 10:46 |
| patrickp | exactly | 10:46 |
| patrickp | iglesiasg: no, I don't really know. I just want to make sure that in the end it will be very easy to get different applications going | 10:47 |
| @iglesiasg | patrickp: aham I see | 10:47 |
| patrickp | and it would be a bummer if we make the model and machines as general as possible, but then there are hidden assumptions in features and labels | 10:47 |
| patrickp | that's all | 10:47 |
| @iglesiasg | so for the moment I have used it for multiclass classification (proof-of-concept basically) and label sequence learning | 10:47 |
| @iglesiasg | and got to it to work fine with it | 10:48 |
| @iglesiasg | well I have also done some grid graphs but re-using the labels for label sequence learning | 10:48 |
| patrickp | cool, that sounds encouraging | 10:48 |
| patrickp | well with a factorgraphlabel this should all be the same | 10:48 |
| hushell | iglesiasg: Is your image seg working now? | 10:49 |
| @iglesiasg | as you may have seen CStructuredLabels are pretty much a subtype of CLabels | 10:49 |
| @iglesiasg | that contains a list of CStructuredData | 10:49 |
| @iglesiasg | CStructuredData is another abstract type | 10:49 |
| @iglesiasg | and you can inherint from it to put pretty much anything you need | 10:49 |
| @iglesiasg | for instance I have done a CStructuredData that is a CSequence for label sequence learning | 10:50 |
| patrickp | yes, I saw this, thanks for the pointer | 10:50 |
| @iglesiasg | and another that is just a number for multiclass classification | 10:50 |
| @iglesiasg | hushell: at the end I gave up the idea of doing a real world segmentation example | 10:50 |
| @iglesiasg | I just did a lame simplification of segmentation | 10:51 |
| hushell | iglesiasg: you could make some synthetic images | 10:51 |
| @iglesiasg | yeah exactly | 10:51 |
| @iglesiasg | just straight bars of different colours I did | 10:51 |
| @iglesiasg | hushell: have a look https://dl.dropboxusercontent.com/u/11020840/pfc/fjig_pfc.pdf | 10:52 |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 10:52 | |
| hushell | iglesiasg: For inference you reuse something from the Pystruct? | 10:52 |
| @iglesiasg | patrickp: I guess the style of the document is familiar :) | 10:52 |
| @iglesiasg | hushell: I used the linear programming relaxation | 10:53 |
| patrickp | iglesiasg: nice! | 10:53 |
| @iglesiasg | hushell: a couple of figures with results are on page 65 of the printed document (79 of the pdf) | 10:53 |
| hushell | cong! You graduated! | 10:54 |
| @iglesiasg | well not really | 10:54 |
| @iglesiasg | I am doing my presentation tomorrow! | 10:54 |
| hushell | iglesiasg: Nice work! | 10:54 |
| @iglesiasg | I am nervous as fuck hahaha | 10:54 |
| hushell | :D | 10:54 |
| @iglesiasg | I am preparing the presentation now, I finished the slides yesterday | 10:54 |
| @iglesiasg | patrickp: I hope you don't mind I basically copied the style from the sample you've got in github :S | 10:55 |
| patrickp | ok, I think I'll have to go. thanks to everyone for the inputs! hushell: I'll send you an email sometime soon with hopefully an updated work plan, I think it's a good idea to first "fix" the two things discussed today, to get to know the internals a bit better. More about this soon | 10:56 |
| patrickp | iglesiasg: no worries, sure, that's why I put it on github :) | 10:56 |
| patrickp | and good luck with your presentation | 10:56 |
| hushell | patrickp: okay, Thanks for the schedule, I'll begin to work tomorrow | 10:57 |
| @iglesiasg | thanks! | 10:57 |
| -!- patrickp [~patrickp@84-75-165-165.dclient.hispeed.ch] has quit [Quit: patrickp] | 10:57 | |
| hushell | I need to go to sleep now. Have a nice day guys | 10:58 |
| @iglesiasg | bye, great talking to you guys | 10:58 |
| hushell | CU | 10:58 |
| -!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Quit: WeeChat 0.3.7] | 10:58 | |
| lisitsyn | wiking: so you say spinlock is not being detected on your machine? | 11:38 |
| -!- gsomix [~Miranda@88.200.242.102] has joined #shogun | 11:40 | |
| gsomix | hello! | 11:40 |
| @wiking | lisitsyn: noup | 11:46 |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 11:46 | |
| lisitsyn | wiking: can you please try to compile that test .cpp then? | 11:46 |
| @wiking | lisitsyn: oh lol | 11:49 |
| @wiking | lisitsyn: case sensitive! :) | 11:49 |
| lisitsyn | wiking: where have I been insensitive? | 11:49 |
| @wiking | there | 11:54 |
| @wiking | mmm where's the announcebot :S | 11:54 |
| @wiking | anyhow it is SpinLock and not Spinlock | 11:55 |
| lisitsyn | wiking: I see | 11:55 |
| lisitsyn | wiking: I didn't mean to be insensitive sorry I hurt you ;) | 11:55 |
| @wiking | :>> | 11:56 |
| @wiking | fucking hell i cannot find a decision tree implementation that's decent enough | 11:56 |
| @wiking | i've checked yesterday night | 11:56 |
| @wiking | C50 | 11:56 |
| @wiking | maaaan fuck | 11:56 |
| @wiking | that code is craaaaaaaaazy | 11:56 |
| @wiking | i mean it's gpl | 11:56 |
| @wiking | but actually no sane person would take that code into their codebase | 11:57 |
| @wiking | full of globals and weird typedefs | 11:57 |
| lisitsyn | wiking: hehe | 11:57 |
| @wiking | lisitsyn: if u know anything let me know | 11:57 |
| lisitsyn | wiking: yeah sure | 11:57 |
| lisitsyn | wiking: I guess trees are too difficult engineering wise for the most of researchers | 11:58 |
| lisitsyn | you know their code quality hah | 11:58 |
| @wiking | i found this... it's not thaaat bad: https://sites.google.com/site/rtranking/ | 11:58 |
| lisitsyn | ahh yeah I have seen that | 11:58 |
| lisitsyn | didn't check the code | 11:58 |
| @wiking | it's not that bad | 11:59 |
| @wiking | it needs some hacking around to get it into shogun | 11:59 |
| @wiking | but it's certainly more useable than c50 | 11:59 |
| lisitsyn | wiking: ohh that's fantastic quality comparing to other code by kilian | 11:59 |
| lisitsyn | wiking: his MT-LMNN is totally embarrassing | 11:59 |
| lisitsyn | spaghetti of horror | 12:00 |
| @wiking | hehehe | 12:00 |
| @wiking | ok brb | 12:00 |
| -!- travis-ci [~travis-ci@ec2-23-23-10-96.compute-1.amazonaws.com] has joined #shogun | 12:10 | |
| travis-ci | [travis-ci] it's Viktor Gal's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/8046078 | 12:10 |
| -!- travis-ci [~travis-ci@ec2-23-23-10-96.compute-1.amazonaws.com] has left #shogun [] | 12:10 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Quit: Leaving] | 12:12 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 12:12 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Remote host closed the connection] | 12:15 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 12:15 | |
| -!- HeikoS [~heiko@nat-181-18.internal.eduroam.ucl.ac.uk] has joined #shogun | 12:16 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 12:16 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Read error: No route to host] | 12:17 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 12:18 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 12:21 | |
| lisitsyn | votjakovr: long time no see! | 12:22 |
| votjakovr | lisitsyn: Hi, I'm glad to see you too | 12:23 |
| lisitsyn | votjakovr: what's up? | 12:31 |
| votjakovr | lisitsyn: sorry, i didn't warn, that i would be missing. But now I'm finally back | 12:33 |
| lisitsyn | votjakovr: ;) | 12:33 |
| -!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has quit [Quit: Page closed] | 12:43 | |
| -!- gsomix [~Miranda@88.200.242.102] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] | 13:07 | |
| -!- nube [~rho@116.90.239.3] has quit [Ping timeout: 246 seconds] | 13:19 | |
| -!- nube [~rho@116.90.239.3] has joined #shogun | 13:57 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Quit: Leaving.] | 14:35 | |
| -!- lambday [67157e4e@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.126.78] has joined #shogun | 14:42 | |
| lambday | HeikoS: exact log job thing tested | 14:43 |
| lambday | :) | 14:43 |
| -!- iglesiasg [c1934d18@gateway/web/freenode/ip.193.147.77.24] has joined #shogun | 14:59 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 14:59 | |
| -!- nube [~rho@116.90.239.3] has quit [Ping timeout: 252 seconds] | 15:03 | |
| @wiking | HeikoS: fyi: https://github.com/shogun-toolbox/shogun/commit/a1dec8b38b974009ee225f26f33bafd032f6c08e | 16:21 |
| @HeikoS | lambday: nice! send the PR :) | 16:23 |
| @HeikoS | wiking: nice! :) | 16:24 |
| @wiking | HeikoS: it's in the new branch | 16:25 |
| @HeikoS | wiking: where is the unit test? otherwise I cannot guarantee you that clone works | 16:25 |
| @wiking | i mean it's coming with random forest i hope | 16:25 |
| @wiking | ah the unit test | 16:25 |
| @wiking | yeah i haven't got around that | 16:25 |
| @wiking | because actually i read that if we would have a decision tree implementation then we could create a random decision tree and then that we could just put in for bagging :P | 16:26 |
| -!- iglesiasg [c1934d18@gateway/web/freenode/ip.193.147.77.24] has quit [Ping timeout: 250 seconds] | 16:26 | |
| @wiking | so the first part is missing actually, i.e. the decision tree | 16:26 |
| @wiking | HeikoS: what's with __ ? | 16:28 |
| @HeikoS | wiking: c++ style says one should not do this | 16:28 |
| @wiking | mmmm | 16:28 |
| @HeikoS | there was a mail some time ago aon this | 16:28 |
| @wiking | really? :) | 16:28 |
| @wiking | okeey | 16:28 |
| @HeikoS | wiking: not a big deal though | 16:28 |
| @wiking | okey | 16:29 |
| @HeikoS | wiking: pretty cool the bagging things! | 16:30 |
| @HeikoS | excited to see that in action | 16:30 |
| -!- gsomix [~gsomix@88.200.242.102] has joined #shogun | 16:49 | |
| gsomix | hi | 16:49 |
| -!- gsomix [~gsomix@88.200.242.102] has quit [Remote host closed the connection] | 17:09 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] | 17:19 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 17:34 | |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun [] | 17:37 | |
| -!- nube [~rho@36.252.6.239] has joined #shogun | 17:37 | |
| -!- nube [~rho@36.252.6.239] has quit [Read error: Connection reset by peer] | 17:42 | |
| -!- nube [~rho@36.252.6.239] has joined #shogun | 17:42 | |
| -!- nube1 [~rho@49.244.57.13] has joined #shogun | 17:48 | |
| -!- nube [~rho@36.252.6.239] has quit [Ping timeout: 246 seconds] | 17:51 | |
| -!- gsomix [~gsomix@88.200.242.102] has joined #shogun | 18:16 | |
| -!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 18:45 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 276 seconds] | 18:58 | |
| -!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has joined #shogun | 20:36 | |
| -!- HeikoS [~heiko@nat-181-18.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 21:32 | |
| lisitsyn | yay! | 22:17 |
| lisitsyn | sonney2k: cheng soon ong is my action editor | 22:18 |
| lisitsyn | that must be good for me | 22:18 |
| @sonney2k | lisitsyn, no it is no... | 22:49 |
| @sonney2k | he will be extra tough | 22:49 |
| lisitsyn | sonney2k: he knows what progress is done though | 22:49 |
| @sonney2k | lisitsyn, but actually he gets the paper because he had it before and so will reviewers | 22:50 |
| lisitsyn | sonney2k: I see | 22:50 |
| lisitsyn | sonney2k: we will see | 22:51 |
| -!- lambday [67157e4e@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.126.78] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 23:30 | |
| --- Log closed Fri Jun 14 00:00:44 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!