--- Log opened Tue Jun 25 00:00:03 2013 | ||
@iglesiasg | good night my friends | 00:13 |
---|---|---|
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 00:13 | |
shogun-buildbot | build #971 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/971 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:14 |
shogun-buildbot | build #1139 of bsd1 - libshogun is complete: Failure [failed test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1139 blamelist: Soeren Sonnenburg <sonne@debian.org> | 00:21 |
shogun-buildbot | build #1261 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1261 | 00:23 |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 02:47 | |
-!- foulwall` [~user@2001:da8:215:503:4fa:3f4c:6816:3fe8] has joined #shogun | 02:50 | |
-!- linus_ [b612b18a@gateway/web/freenode/ip.182.18.177.138] has joined #shogun | 02:50 | |
-!- travis-ci [~travis-ci@ec2-54-226-106-169.compute-1.amazonaws.com] has joined #shogun | 02:51 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg'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/8400237 | 02:51 |
-!- travis-ci [~travis-ci@ec2-54-226-106-169.compute-1.amazonaws.com] has left #shogun [] | 02:51 | |
-!- nube [~rho@49.244.71.235] has quit [Ping timeout: 248 seconds] | 02:57 | |
-!- foulwall` [~user@2001:da8:215:503:4fa:3f4c:6816:3fe8] has quit [Ping timeout: 245 seconds] | 02:59 | |
-!- linus_ [b612b18a@gateway/web/freenode/ip.182.18.177.138] has quit [Quit: Page closed] | 03:03 | |
-!- foulwall` [~user@2001:da8:215:503:61fb:3cf5:6e5b:5a35] has joined #shogun | 03:06 | |
-!- zxtx [~zv@12.231.120.253] has quit [Ping timeout: 246 seconds] | 03:17 | |
-!- foulwall` [~user@2001:da8:215:503:61fb:3cf5:6e5b:5a35] has quit [Ping timeout: 245 seconds] | 03:42 | |
-!- mode/#shogun [+o sonney2k] by ChanServ | 03:52 | |
-!- travis-ci [~travis-ci@ec2-54-234-65-138.compute-1.amazonaws.com] has joined #shogun | 03:52 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg'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/8400770 | 03:52 |
-!- travis-ci [~travis-ci@ec2-54-234-65-138.compute-1.amazonaws.com] has left #shogun [] | 03:52 | |
-!- foulwall` [~user@2001:da8:215:6901:14c1:888e:6755:f0f] has joined #shogun | 04:09 | |
shogun-buildbot | build #438 of nightly_default is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/438 | 04:25 |
-!- travis-ci [~travis-ci@ec2-54-234-65-138.compute-1.amazonaws.com] has joined #shogun | 04:27 | |
travis-ci | [travis-ci] it's Heiko Strathmann'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/8401128 | 04:27 |
-!- travis-ci [~travis-ci@ec2-54-234-65-138.compute-1.amazonaws.com] has left #shogun [] | 04:27 | |
-!- travis-ci [~travis-ci@ec2-23-22-205-184.compute-1.amazonaws.com] has joined #shogun | 04:58 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg'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/8402692 | 04:58 |
-!- travis-ci [~travis-ci@ec2-23-22-205-184.compute-1.amazonaws.com] has left #shogun [] | 04:58 | |
-!- foulwall` [~user@2001:da8:215:6901:14c1:888e:6755:f0f] has quit [Ping timeout: 245 seconds] | 05:07 | |
-!- travis-ci [~travis-ci@ec2-23-22-205-184.compute-1.amazonaws.com] has joined #shogun | 05:11 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg'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/8402861 | 05:11 |
-!- travis-ci [~travis-ci@ec2-23-22-205-184.compute-1.amazonaws.com] has left #shogun [] | 05:11 | |
-!- travis-ci [~travis-ci@ec2-54-226-106-169.compute-1.amazonaws.com] has joined #shogun | 05:35 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg'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/8403906 | 05:35 |
-!- travis-ci [~travis-ci@ec2-54-226-106-169.compute-1.amazonaws.com] has left #shogun [] | 05:35 | |
-!- nube [~rho@116.90.239.3] has joined #shogun | 05:44 | |
-!- nube [~rho@116.90.239.3] has quit [Ping timeout: 240 seconds] | 06:21 | |
-!- nube [~rho@116.90.239.3] has joined #shogun | 06:23 | |
-!- hushell [~hushell@c-67-160-139-116.hsd1.or.comcast.net] has joined #shogun | 06:43 | |
@sonney2k | good morning hushell! | 06:43 |
hushell | hi sonney2k | 07:13 |
hushell | wiking: So you think the StructuredOutputMachine::set_labels() should be removed? | 07:14 |
hushell | wiking: regarding another question about risk(), you still think putting risk() in StructuredModel better than in StructuredOutputMachine? | 07:17 |
hushell | wiking: Thanks for participating the discussion, it's really hard to optimize the code by my own ... | 07:19 |
-!- lambday [67157f4f@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.127.79] has joined #shogun | 07:19 | |
lambday | sonney2k: good morning... you're back :D | 07:19 |
lambday | wiking: saw your comment... I'll change it :) | 07:20 |
@wiking | lambday: thnx | 07:21 |
lambday | I didn't SG_ADD the parameters.. will add it too and sent the PR.. | 07:21 |
lambday | so, all classes need to have this init, right? | 07:22 |
@wiking | hushell: just woke up :) | 07:24 |
@wiking | hushell: i'm happy to discuss but in 30 mins or so | 07:24 |
hushell | wiking: short discussion is more than enough | 07:26 |
hushell | wiking: okay. We got 3 issues. Let me list here: | 07:27 |
hushell | 1) about labels, so we keep it a member var in StructuredModel, right? and remove the set_labels() in SOMachine | 07:28 |
hushell | 2) for risk(), I'd like to have like this: risk(ENUM_Objective_formulation) as a router, and there are implmentations like risk_nslack_margin_rescaling() etc. | 07:30 |
-!- gsomix [~Miranda@46.20.65.164] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] | 07:31 | |
hushell | 3) the libqp functions need the risk(), if we put this in StructuredModel, then is the original design. But I'd like to see it becomes independent of the model, so I want to put it in SOMachine, so now I pass a CDualLibQPMachine* to libqp to call the risk() | 07:32 |
@wiking | hushell: just a sec i'm reading it | 07:37 |
hushell | wiking: No hurries :) | 07:37 |
hushell | Acutually my other part of GSOC is independent of the SSVM stuff. I don't mind if we need more discussion before the refinement | 07:39 |
hushell | For a little bit more clear, you may want to look at this paper, which lists the 4 basic opt problems: http://tfinley.net/research/joachims_etal_09a.pdf | 07:39 |
@wiking | 1) yes i would to that, as although it's not strictly model dependent but you need those for being able to train.... | 07:39 |
@wiking | although one could argue of course that it's totally model independent, but then you would need to remove both Features and Labels from the StructuredModel's ctor | 07:40 |
hushell | yes, indeed. and we need to access m_labels for implementing argmax() etc | 07:40 |
hushell | keep m_features and m_labels in StructuredModel make life easier | 07:41 |
@wiking | so in this case i would remove the labels part from the machine and maybe just keep reference to it, if it's inevitable to have it in the machine as well | 07:41 |
hushell | in machine, it has a reference to model, so during training m_features and m_labels can be obtained | 07:42 |
@wiking | 2) i'll put some code up today for latentSOMachine, and you'll see there some enum magic for choosing SOSVM solver... this way maybe we can avoid having more enums... | 07:42 |
hushell | Happy to learn this! :D | 07:43 |
@wiking | 3) i know why you need to pass CDualLibQPMachine* (reference to risk() function) but i feel it that semantically it's totally misleading :( | 07:43 |
@wiking | sonney2k: ping | 07:44 |
hushell | because the libqp is kind of C code | 07:44 |
hushell | We need pass the class pointer to access the risk() | 07:44 |
@wiking | hushell: it's not kind of ;) it is ansi c code :P | 07:44 |
hushell | :) | 07:44 |
@wiking | hushell: let's try to think of a better alternative for 3) | 07:45 |
hushell | before it calls like this: model->risk() | 07:45 |
@wiking | hushell: although i have currently no better idea... :P | 07:45 |
@wiking | hushell: you'll see from latentSOSVM hacks how it's done.... as obviously the risk() is a bit different in case of latentSOSVM | 07:45 |
hushell | I was thinking put all libqp functions into DualLibQPSOSVM | 07:45 |
@wiking | hushell: noup do do that... libqp should be separate | 07:46 |
@wiking | hushell: as it's totally independent... | 07:46 |
hushell | okay | 07:46 |
@wiking | hushell: i mean libqp is an external lib that we keep on updating when libqp itself is being updated | 07:46 |
hushell | another way maybe change the arguments of risk() | 07:46 |
hushell | so move risk() out of any class | 07:47 |
hushell | and pass a StructuredModel pointer to risk() | 07:47 |
hushell | so it can access m_features m_labels and StructuredModel::argmax() | 07:47 |
@wiking | hushell: we might have troubles with swig interfaces when passing around function pointers.. | 07:47 |
@wiking | ah that way | 07:48 |
@wiking | risk(StructedModel*, ...) | 07:48 |
@wiking | ? | 07:48 |
hushell | yes | 07:48 |
@wiking | and where would risk be implemented? | 07:48 |
hushell | a little bit strange anyway | 07:48 |
@wiking | it'd be still part of DualLibQPSOSVM? | 07:48 |
@wiking | mmm have to think about this a bit | 07:49 |
hushell | Patrick like to see it be a part of LinearSOMachine | 07:49 |
@wiking | why exactly LinearSOMachine ? :)))) | 07:49 |
hushell | because for online solver also need this | 07:49 |
hushell | the subgradient ... | 07:49 |
hushell | maybe StructuredMachine? | 07:49 |
hushell | I mean in StructuredMachine | 07:50 |
@wiking | yeah i would actually put it on the top of the hierarch | 07:50 |
hushell | It's hard to incorporate C and C++ !!! | 07:51 |
@wiking | no not that much :P | 07:51 |
@wiking | both of them is C :> | 07:51 |
hushell | not very compatible | 07:52 |
hushell | so why do you think BmrmStatistics svm_bmrm_solver( ||| get_col [shogun] | 07:53 |
hushell | CDualLibQPBMSOSVM *machine | 07:53 |
hushell | it's not good? | 07:53 |
@wiking | because basically u are passing the solver itself | 07:53 |
@wiking | svm_bmrm_solver is the BMRM solver (one of them) | 07:54 |
@wiking | and you are passing CDualLibQPBMSOSVM | 07:54 |
@wiking | to it which is actually just the wrapper class for the BMRM solver itself... | 07:54 |
hushell | yes, you mean inside DualLibQPSOSVM, svm_bmrm_solver being called? | 07:54 |
hushell | yes, semantically, it's wierd | 07:55 |
@wiking | i mean because CDualLibQPBMSOSVM is just a wrapper c++ class for the different BMRM solvers... | 07:55 |
hushell | In my opinion, the best way is letting svm_bmrm_solver etc be member functions | 07:56 |
hushell | but now we cant | 07:56 |
hushell | so maybe passing CDual* is not bad | 07:57 |
@wiking | mmm i'm strongly against this approach :) | 07:57 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 07:57 | |
hushell | Well, I don't have a preference here, so keep risk() in StructuredModel seems the only solution | 07:59 |
hushell | we don't have other classes to put this function | 07:59 |
@wiking | hushell: let's ask the others as well ;) | 08:00 |
hushell | okay, I will copy and paste our discussion and email to Patrick and Fernando, is there anybody else know this well? | 08:01 |
sonne|work | wiking: how come you are awake? | 08:17 |
@wiking | sonne|work: dunno man.... | 08:17 |
@wiking | sonne|work: we need a factory of Features ;) | 08:17 |
sonne|work | wiking: oki then back to wrk! | 08:18 |
-!- gsomix [~Miranda@46.20.65.164] has joined #shogun | 08:36 | |
gsomix | hi | 08:36 |
hushell | wiking: okay, I sent a long email :) | 08:38 |
@wiking | cool thnx | 08:39 |
-!- nube [~rho@116.90.239.3] has quit [Ping timeout: 276 seconds] | 08:44 | |
-!- foulwall` [~user@2001:da8:215:c252:2c89:bf3f:5f7a:c953] has joined #shogun | 08:54 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 09:04 | |
-!- foulwall` [~user@2001:da8:215:c252:2c89:bf3f:5f7a:c953] has quit [Ping timeout: 245 seconds] | 09:17 | |
sonne|work | lambday: hey there! | 09:20 |
lambday | sonne|work: hey :D | 09:20 |
lambday | where were you? :-o | 09:21 |
sonne|work | lambday: just an update - the json serialization issue you found was actually a bug in the lib json-c 0.10.0 | 09:21 |
sonne|work | upgrading to 0.11.0 helped | 09:21 |
sonne|work | don't ask how long it took me to figure that out | 09:21 |
lambday | :-s okay not asking!! but it got fixed yayy | 09:21 |
lambday | is the failing unit-tests for pythom_modular also due to this? | 09:22 |
sonne|work | lambday: so please add the tests back | 09:22 |
sonne|work | lambday: failing unit test? | 09:23 |
sonne|work | nothing should fail currently | 09:23 |
sonne|work | yes all good http://shogun-toolbox.org/buildbot/waterfall | 09:23 |
sonne|work | only wiking needs to update json-c on his bsd1 bot | 09:23 |
lambday | awesome! so travis will go green again :) | 09:24 |
lambday | I'll check the tests.. | 09:24 |
sonne|work | wiking: we also need to require newer json-c on travis... | 09:30 |
-!- nube [~rho@116.90.239.3] has joined #shogun | 09:32 | |
-!- foulwall` [~user@2001:da8:215:c252:8c3c:7aac:23e9:fb11] has joined #shogun | 09:33 | |
sonne|work | hey foulwall`! | 09:38 |
sonne|work | I hope I manage to have a current version of the demo running soon on nn.7nn.de | 09:39 |
lambday | sonne|work: the initialize we're talking about is for precomputing some stuffs that will be needed by other methods later... what would be a good name for that? | 09:47 |
sonne|work | precompute_* | 09:47 |
lambday | sonne|work: and also, shall I change the "init" to "register_params" now? | 09:47 |
lambday | sonne|work: alright :) | 09:47 |
sonne|work | lambday: the init() rename is a big effort I guess best done with some eclipse style UI | 09:48 |
sonne|work | so rather no not now but we should really do this | 09:48 |
sonne|work | init() is such a useless name | 09:48 |
@wiking | sonne|work: mmmm well there's the package that comes with ubuntu... if that's not good enough then we can have the wget hack as we have for gmock | 09:49 |
lambday | sonne|work: okay.. yes I use vim so big trouble for me | 09:49 |
sonne|work | wiking: there is a newer one in debian | 09:49 |
sonne|work | wiking: http://packages.qa.debian.org/j/json-c.html | 09:50 |
@wiking | sonne|work: or that ;) | 09:50 |
sonne|work | wiking: in any case please do - otherwise travis won't go back to green | 09:52 |
@wiking | sonne|work: don't we have a detect for json version in ./configure?: ) | 10:01 |
sonne|work | yes we do but ? | 10:02 |
sonne|work | tests need them | 10:02 |
@wiking | but that's stupid | 10:02 |
@wiking | if json is not found because of being too old | 10:02 |
@wiking | test based on json | 10:03 |
@wiking | shouldn't be ran at all | 10:03 |
sonne|work | then we will never know if we break sth in json | 10:05 |
sonne|work | we should have all deps installed on the buildbots | 10:05 |
@wiking | ic | 10:06 |
lisitsyn | sonne|work: I was thinking about a way to provide casts for interfaces automatic way | 10:13 |
sonne|work | lisitsyn: like gsomix did you mean? | 10:13 |
lisitsyn | one way is CRTP but I am not sure you'd like it | 10:13 |
lisitsyn | sonne|work: yes obtain_from_generic | 10:13 |
lisitsyn | sonne|work: this makes SGObject template | 10:13 |
lisitsyn | and all derived classes are inherited this way: | 10:14 |
lisitsyn | class MyClass: public SGObject<MyClass> | 10:14 |
lisitsyn | then we can get static polymorphism for these casts | 10:14 |
sonne|work | lisitsyn: how would you do that with swig then? | 10:14 |
lisitsyn | sonne|work: I didn't try but is there any problem? | 10:15 |
sonne|work | well you need to assign a name to each templated class | 10:15 |
lisitsyn | derived classes are not templated | 10:15 |
sonne|work | so SGObject<MyClass> needs to be e.g. MyCLassSGObject | 10:15 |
sonne|work | yeah but SGObject ones | 10:16 |
lisitsyn | what happens when we don't rename it? | 10:16 |
lisitsyn | one other issue is that it needs some fancier thing for SGObject -> A -> B case | 10:17 |
lisitsyn | class B : public SGObject<B,A> | 10:17 |
lisitsyn | class A : public SGObject<A,Empty> | 10:17 |
lisitsyn | like that | 10:17 |
lisitsyn | sonne|work: I am afraid of that way too | 10:18 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["normal"] | 10:18 | |
lisitsyn | but these manually tinkered obtain_from_generic are wrong indeed | 10:18 |
sonne|work | I think swig will say that the base class is unknown | 10:18 |
lisitsyn | argh okay discard then | 10:19 |
sonne|work | lisitsyn: or we have a templated function doing A -> B | 10:19 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 10:20 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 10:20 | |
lisitsyn | sonne|work: what do you mean? | 10:20 |
sonne|work | I don't see how to do that automatically but we could have a *single* templated obtain_from_generic function to convert A -> B | 10:24 |
sonne|work | at least in C++. in swig we again have the issue that we need to use %template | 10:24 |
-!- foulwall` [~user@2001:da8:215:c252:8c3c:7aac:23e9:fb11] has quit [Ping timeout: 245 seconds] | 10:26 | |
-!- thoralf [~thoralf@enki.zib.de] has joined #shogun | 10:26 | |
thoralf | Hey. | 10:26 |
lisitsyn | sonne|work: no it has to be defined everywhere | 10:26 |
lisitsyn | sonne|work: what matters is return type | 10:26 |
lisitsyn | so no place for templates here | 10:26 |
lisitsyn | sonne|work: would be nice to *always* convert to real type | 10:27 |
@wiking | sonne|work lisitsyn do we support mixed features, i.e. real and string features mixed? | 10:27 |
sonne|work | wiking: sure | 10:28 |
@wiking | sonne|work: which featuretype is that? | 10:28 |
sonne|work | combinedfeatures / combineddotfeatures | 10:28 |
@wiking | mmm | 10:28 |
sonne|work | mmm? | 10:28 |
@wiking | checking the api | 10:29 |
sonne|work | wiking: just check out the examples... | 10:33 |
sonne|work | you can stack together dense/sparse/byte/float/whatever/stringfeatures | 10:34 |
lambday | wiking: using CRamdon::std_normal_distrib(), the unit-tests fails.. with a large margin :( | 11:04 |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 11:05 | |
lambday | wiking: may be I am using it wrong :-/ I'm pushing to my fork may be you can take a look? | 11:07 |
@iglesiasg | is it normal to get like a thousand txt, json, hdf5, and xml files after running make in tests/unit? | 11:09 |
@iglesiasg | ok maybe not a thousand :) | 11:09 |
@iglesiasg | wow I just got my GSoC package! | 11:15 |
lambday | iglesiasg: congrats :) I haven't got mine yet :( | 11:16 |
lambday | iglesiasg: regarding unit-tests, yes, those things I did :( | 11:16 |
@iglesiasg | hehe ok | 11:16 |
@iglesiasg | lambday: let's just add them to gitignore | 11:16 |
lambday | iglesiasg: okay.. :) | 11:17 |
-!- foulwall` [~user@2001:da8:215:c252:6c33:cca0:7f6e:f184] has joined #shogun | 11:22 | |
lambday | wiking: https://github.com/lambday/shogun/commit/a6d4a82ff8d8949d3d4a6a52523f441a0ad7a4ec#L16R46 | 11:22 |
-!- foulwall` [~user@2001:da8:215:c252:6c33:cca0:7f6e:f184] has quit [Ping timeout: 245 seconds] | 11:27 | |
lambday | iglesiasg: added.. | 11:33 |
@iglesiasg | thank you | 11:33 |
thoralf | Given a SVMLight file with binary labels in first column - is there an easy way to load only the labels into an BinaryLabels? | 12:02 |
thoralf | Without writing plenty of boiler plate code? :) | 12:03 |
-!- nube [~rho@116.90.239.3] has quit [Quit: Leaving.] | 12:07 | |
@iglesiasg | lisitsyn, sonne|work : I should set the doodle for the next GSoC meeting, so when do you think it should be? | 12:11 |
@iglesiasg | before workshop? | 12:12 |
@iglesiasg | after workshop and before midterm? | 12:12 |
-!- vgorbati [~vgorbati@212.2.159.34] has joined #shogun | 12:15 | |
-!- vgorbati_ [~vgorbati@212.2.159.34] has joined #shogun | 12:22 | |
-!- vgorbati [~vgorbati@212.2.159.34] has quit [Ping timeout: 248 seconds] | 12:24 | |
-!- vgorbati_ is now known as vgorbati | 12:24 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 12:29 | |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has quit [Read error: Operation timed out] | 12:38 | |
lambday | got my welcome package yahoo! | 12:39 |
lambday | oops! got my welcome package google! | 12:39 |
-!- gsomix [~Miranda@46.20.65.164] has quit [Read error: Connection reset by peer] | 12:46 | |
-!- gsomix [~Miranda@46.20.65.164] has joined #shogun | 12:47 | |
gsomix | lambday: huh, congrats. | 12:47 |
lambday | gsomix: ty ty :D | 12:47 |
-!- foulwall` [~user@2001:da8:215:6100:5d2a:4700:d2a9:32e7] has joined #shogun | 12:52 | |
@wiking | lambday: ok checking | 13:09 |
@wiking | lambday: oh nooo not good | 13:09 |
lambday | wiking: how to use it then? | 13:09 |
@wiking | lambday: see comments | 13:11 |
lambday | wiking: alright.. yes got it.. thanks | 13:11 |
lambday | I'm checking and will let you know | 13:11 |
@wiking | ok cool | 13:11 |
lambday | wiking: thanks.. it works :) but log-det sample unit-test needs to draw more samples to pass 0.1 precision test it seems.. | 13:16 |
lambday | checking... | 13:16 |
lambday | wiking: works! :D, raised it to 10,000 from 1,000 and it passes | 13:18 |
-!- nube [~rho@49.244.126.8] has joined #shogun | 13:18 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] | 13:19 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 14:04 | |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 9ccdc30 / src/shogun/multiclass/KNN.h: https://github.com/shogun-toolbox/shogun/commit/9ccdc3094289093631cf2a5ea710935e3c52c6ec | 14:04 |
shogun-notifier- | shogun: remove commented out function | 14:04 |
vgorbati | sonney2k: hello, are you here? | 14:11 |
sonne|work | vgorbati: yes! | 14:22 |
vgorbati | @sonne|work: I've started some work on implementing NN's, and since they should be inherited from 'CMachine', and thus implement 'train' method, I have a question: how do you usually handle a case, when there are multiple suitable training algorithms? | 14:24 |
sonne|work | vgorbati: multiple machines! | 14:24 |
sonne|work | vgorbati: e.g. libsvm, svmlight, ... | 14:24 |
vgorbati | @sonne|work: so, different class for each training method, right? | 14:25 |
sonne|work | yes with a common base class (e.g. CSVM) | 14:25 |
shogun-buildbot | build #1140 of bsd1 - libshogun is complete: Failure [failed test test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1140 blamelist: Soeren Sonnenburg <sonne@debian.org> | 14:27 |
shogun-buildbot | build #972 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/972 blamelist: Soeren Sonnenburg <sonne@debian.org> | 14:28 |
vgorbati | @sonne|work: that doesn't sound sensible for NN's.. I mean, for one architecture - say multilayered perceptron, you can use quite a lot of training algorithms - one reaches global minimum, but it is slower, another reaches local, but is much faster, the third one is randomized and so on. And it makes no sense to me to name a class like 'BackpropagationMultilayeredPerceptron' or 'LevenbergMarquardtMultilayeredPerceptron') | 14:30 |
vgorbati | @sonne|work: but anyway, if it a preferred way:) | 14:32 |
vgorbati | @sonne|work: *it is a preferred way | 14:32 |
-!- FSCV [~FSCV@187.210.54.166] has joined #shogun | 14:37 | |
sonne|work | vgorbati: well it is the same with svms. | 14:42 |
sonne|work | vgorbati: however, we have other algorithms like liblinear that internally can handle various loss functions | 14:43 |
-!- FSCV_ [~FSCV@50.7.50.60] has joined #shogun | 14:43 | |
sonne|work | so another option is to set the training algorithm | 14:43 |
-!- FSCV [~FSCV@187.210.54.166] has quit [Ping timeout: 255 seconds] | 14:45 | |
vgorbati | @sonne|work: you mean, like some field, say 'm_TrainingAlgorithm', of a neural network class? | 14:48 |
-!- FSCV_ [~FSCV@50.7.50.60] has quit [Quit: Leaving] | 14:51 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Quit: Leaving.] | 14:57 | |
sonne|work | vgorbati: yes but recall all lowercase and _ separated | 14:57 |
shogun-buildbot | build #1263 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1263 blamelist: Soeren Sonnenburg <sonne@debian.org> | 15:00 |
vgorbati | @sonne|work: okay, just to make sure I got everything right: 1. Add a base class 'CTrainer'. All concrete training algorithm will inherit from it. 2. Add a field 'CTrainer m_trainer' to the base neural network class. 3. The method NeuralNetwork.train(data) will just call m_trainer.train(this, data). | 15:05 |
sonne|work | or if you have certain re-occurring patterns your CTrainer just defines a few functions that are used in the NN's train method and can be overridden | 15:22 |
vgorbati | @sonne|work: got it, thanks | 15:24 |
-!- foulwall` [~user@2001:da8:215:6100:5d2a:4700:d2a9:32e7] has quit [Ping timeout: 245 seconds] | 16:20 | |
-!- vgorbati [~vgorbati@212.2.159.34] has quit [Ping timeout: 268 seconds] | 16:25 | |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 16:29 | |
-!- vgorbati [~vgorbati@37.19.160.111] has joined #shogun | 16:33 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Read error: Connection reset by peer] | 16:50 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 16:51 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 17:04 | |
-!- hushell [~hushell@c-67-160-139-116.hsd1.or.comcast.net] has quit [Ping timeout: 246 seconds] | 17:16 | |
-!- vgorbati [~vgorbati@37.19.160.111] has quit [Quit: vgorbati] | 17:24 | |
-!- travis-ci [~travis-ci@ec2-23-22-205-184.compute-1.amazonaws.com] has joined #shogun | 17:39 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg'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/8422417 | 17:39 |
-!- travis-ci [~travis-ci@ec2-23-22-205-184.compute-1.amazonaws.com] has left #shogun [] | 17:39 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 17:51 | |
-!- hushell [~hushell@67.23.197.94] has joined #shogun | 17:51 | |
-!- kevin_ [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 18:16 | |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Ping timeout: 264 seconds] | 18:19 | |
-!- lambday [67157f4f@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.127.79] has quit [Ping timeout: 264 seconds] | 18:20 | |
-!- FSCV [~FSCV@187.210.54.166] has joined #shogun | 18:28 | |
-!- kevin_ [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 18:58 | |
-!- gsomix_ [~Miranda@46.20.65.164] has joined #shogun | 19:13 | |
-!- lisitsyn [~lisitsyn@46.20.65.164] has joined #shogun | 19:20 | |
-!- zxtx [~zv@cpe-66-68-190-37.austin.res.rr.com] has joined #shogun | 19:20 | |
-!- Netsplit *.net <-> *.split quits: gsomix, nube | 19:21 | |
-!- vgorbati [~vgorbati@212.2.159.34] has joined #shogun | 19:26 | |
-!- Netsplit over, joins: nube | 19:29 | |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 19:50 | |
lisitsyn | pickle27: hey there | 19:55 |
lisitsyn | how is it going? | 19:55 |
pickle27 | hey good! | 19:55 |
-!- vgorbati [~vgorbati@212.2.159.34] has quit [Ping timeout: 260 seconds] | 20:15 | |
-!- vgorbati_ [~vgorbati@212.2.159.34] has joined #shogun | 20:15 | |
-!- vgorbati_ [~vgorbati@212.2.159.34] has quit [Client Quit] | 20:17 | |
-!- hushell [~hushell@67.23.197.94] has quit [Ping timeout: 245 seconds] | 20:19 | |
-!- hushell [~hushell@67.23.197.94] has joined #shogun | 20:26 | |
-!- hushell [~hushell@67.23.197.94] has quit [Ping timeout: 260 seconds] | 20:31 | |
@sonney2k | lisitsyn, wiking we got the rooms for the post workshop hands on session :D | 20:39 |
lisitsyn | sonney2k: c-base? | 20:39 |
@sonney2k | lisitsyn, tu berlin | 20:39 |
lisitsyn | sonney2k: oh nice | 20:40 |
@sonney2k | for 2 days | 20:40 |
lisitsyn | sonney2k: what should we do here though.. :D | 20:40 |
lisitsyn | sonney2k: my visa is ready btw | 20:42 |
@sonney2k | lisitsyn, hack shogun of course! | 20:46 |
@sonney2k | make plans and talk to each other | 20:46 |
lisitsyn | sonney2k: you are going to be away, richtig? | 20:46 |
@sonney2k | yeah on holidays | 20:47 |
lisitsyn | sonney2k: schlecht! | 20:47 |
@sonney2k | why? | 20:47 |
lisitsyn | sonney2k: we will be missing you ;) | 20:47 |
@sonney2k | it is ok if you miss me but you are all grown ups | 20:47 |
@sonney2k | and yes I will miss you too :D | 20:48 |
-!- vgorbati [~vgorbati@212.2.159.34] has joined #shogun | 21:09 | |
@wiking | jesus fuck | 21:12 |
@wiking | sonney2k: ah ok | 21:12 |
@wiking | sonney2k: cool how long we can stay in c-basE? | 21:12 |
@wiking | i.e. the real hacking time... ?:) | 21:12 |
-!- iglesiasg [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 21:29 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 21:29 | |
-!- lambday [67157d4f@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.125.79] has joined #shogun | 21:35 | |
@iglesiasg | hey lisitsyn, how are you doing? | 21:44 |
lisitsyn | iglesiasg: hey, mostly fine what about you? | 21:44 |
@iglesiasg | lisitsyn: fine too :) | 21:44 |
@iglesiasg | lisitsyn: let me ask you, how do you want we take care of my PRs for the metric learning project? | 21:45 |
@iglesiasg | should I take care of merging them myself or are you going to review them? | 21:45 |
lisitsyn | iglesiasg: oops sorry I forgot to comment it | 21:45 |
lisitsyn | iglesiasg: I am mostly ok with everything here | 21:46 |
@iglesiasg | lisitsyn: ok, just tell me in github what should I change | 21:46 |
@iglesiasg | no need to be now, when you find some time ;) | 21:46 |
lisitsyn | iglesiasg: I think nothing so far | 21:46 |
@iglesiasg | any clue why serialization_complex crashes? | 21:50 |
@iglesiasg | lisitsyn: what about the next meeting btw? before or after workshop? | 21:54 |
lisitsyn | iglesiasg: I'd choose before, lets see what sonney2k thinks | 21:54 |
@iglesiasg | lisitsyn: ok, I'd say before mid-term is enough -- so after workshop, before mid-term | 21:55 |
@iglesiasg | but yeah, let's see | 21:55 |
@iglesiasg | hey lambday | 21:55 |
@iglesiasg | how are you doing? | 21:55 |
lambday | iglesiasg: good :) how're you doing? :) | 21:56 |
@iglesiasg | lambday: fine! | 21:56 |
lambday | iglesiasg: I couldn't set the PIN of the debit card tonight | 21:56 |
@iglesiasg | lambday: aham! why so? | 21:56 |
lambday | called the number up that they had given, but couldn't hear clearly what the voice was saying :-/ | 21:57 |
lambday | iglesiasg: how did you do it? | 21:57 |
@sonney2k | wiking, we have the workshop on the 12 (friday) and the hands on session at TU on saturday & sunday 12/13 | 21:58 |
@sonney2k | so real hacking time is the whole weekend | 21:58 |
@iglesiasg | lambday: haven't do it for the one I got today | 21:58 |
@iglesiasg | lambday: last year I just called from skype and talked to them, I got no trouble | 21:58 |
@iglesiasg | lambday: try later again, maybe it gets better with another speaker | 21:58 |
lambday | like, talked to people or just recorded IVRS stuffs :-/ | 21:59 |
@iglesiasg | lambday: BTW, it seems NormalSampler unit test fails on travis, have you seen? https://travis-ci.org/shogun-toolbox/shogun/jobs/8418573 | 21:59 |
lambday | iglesiasg: let me check | 21:59 |
@iglesiasg | around line 2842 in the log above | 21:59 |
@sonney2k | iglesiasg, lisitsyn I won't have time anyway so just do it as you can | 22:00 |
@iglesiasg | sonney2k: all right | 22:00 |
@iglesiasg | lisitsyn: I guess I could fit both before or after workshop, so why do you prefer before? | 22:00 |
lambday | iglesiasg: oh no! yeah I'll make it 100,000 then :-/ no idea why it works on my system and fails on travis! | 22:00 |
lisitsyn | iglesiasg: my preference is not that strong | 22:00 |
lambday | or make the precision less | 22:01 |
@iglesiasg | lisitsyn: so my point is that we have to make it before the mid-term to talk about it | 22:01 |
lisitsyn | iglesiasg: did you book a flight? ;) | 22:01 |
@iglesiasg | provided that, I think the closer to the mid-term the better | 22:02 |
@iglesiasg | lisitsyn: still lot of places left in the plane to get the type of ticket I like | 22:02 |
@iglesiasg | economy one :P | 22:02 |
@iglesiasg | haha | 22:02 |
lisitsyn | iglesiasg: ho(s)tel? | 22:02 |
@iglesiasg | neither | 22:03 |
@iglesiasg | I checked available places two days ago, seems to be no trouble either ;) | 22:03 |
-!- vgorbati [~vgorbati@212.2.159.34] has quit [Ping timeout: 240 seconds] | 22:03 | |
lisitsyn | iglesiasg: one friend of mine choosed one let me find | 22:03 |
@iglesiasg | lisitsyn: oh thanks! | 22:04 |
lisitsyn | http://www.hostel-anlema.de/englisch/home/ | 22:04 |
@iglesiasg | lisitsyn: it seems very nice! thanks | 22:04 |
@iglesiasg | lisitsyn: is your friend coming to the workshop too? | 22:05 |
lisitsyn | iglesiasg: yes from cz | 22:05 |
@iglesiasg | lisitsyn: cool | 22:05 |
lisitsyn | iglesiasg: guy from my city | 22:05 |
lisitsyn | :D | 22:05 |
@iglesiasg | I like the prices very much, best ones I see so far | 22:05 |
lisitsyn | russians all around the globe | 22:05 |
@iglesiasg | lisitsyn: ah what did you mean with cz then? | 22:05 |
lisitsyn | iglesiasg: czech republic | 22:05 |
@iglesiasg | yeah sure | 22:06 |
lisitsyn | iglesiasg: he is from my city but studies here and I expect will never come back :D | 22:06 |
@iglesiasg | I just got confused when you said from your city, later I got it with the Russians around the globe | 22:06 |
@iglesiasg | hehe | 22:06 |
lambday | iglesiasg: sonney2k lisitsyn: in one PR it some method works and in another it doesn't :( https://travis-ci.org/shogun-toolbox/shogun/builds/8421937 | 22:06 |
pickle27 | lisitsyn: got a question | 22:07 |
lambday | its because its random isn't it | 22:07 |
lisitsyn | pickle27: yes? | 22:07 |
pickle27 | well two actually | 22:07 |
pickle27 | in the end are we going to include all of the ADJ methods in shogun or just the best one? | 22:08 |
pickle27 | trying to decide how much effort I should put into cleaning up JADE right now vs moving onto FFdiag | 22:08 |
lisitsyn | pickle27: is there the best one? | 22:08 |
pickle27 | and second | 22:08 |
@iglesiasg | lambday: it should be due to randomness indeed | 22:08 |
pickle27 | lisitsyn: I don't think there is a clear best one but JADE is old, like 1993 | 22:08 |
lambday | iglesiasg: its really tough to set any bounds to those unit-tests :-/ | 22:09 |
@iglesiasg | I can imagine | 22:09 |
lambday | oh btw your PR fails for my old code, right? in the next PR I changed its implementation to use CRandom::std_normal_distrib instead of CMath::randn_double... may be that will solve it :-/ | 22:10 |
lambday | increased the number of samples too | 22:11 |
lambday | 1000 to 5000 | 22:11 |
lambday | once it gets merged I mean | 22:11 |
pickle27 | Andreas said JADE is like a standard Im just wondering how we wanted this to look in the end | 22:11 |
@iglesiasg | lambday: aham! when was it merge? | 22:11 |
@iglesiasg | merged* | 22:11 |
lisitsyn | pickle27: oh then we should have it I think | 22:11 |
lisitsyn | pickle27: SVM is quite near to 1993 too ;) | 22:12 |
lambday | iglesiasg: sunday, I think | 22:12 |
lisitsyn | well closer to 1970s :D | 22:12 |
@iglesiasg | lambday: mmm I updated this morning before I did the PR so your new code should be there | 22:12 |
pickle27 | lisitsyn: okay, because I have the R version ported and working but it isn't the easiest to re-work | 22:12 |
lambday | I sent a PR today which contains the changes.. which is not merged yet | 22:12 |
lisitsyn | pickle27: ported to C++? | 22:12 |
pickle27 | lisitsyn: the author of JADE posted a C implementation which is broken down better | 22:13 |
lambday | iglesiasg: no no today's code isn't merged yet :-( | 22:13 |
pickle27 | yeah the R package had a C function for the inner loop processing | 22:13 |
lambday | sorry for the confusion :( | 22:13 |
@iglesiasg | lambday: aham! no problem :) | 22:13 |
pickle27 | its the inner loop function that does most the work but its really hard to follow what its doing and I didn't have to touch this function for the port | 22:13 |
pickle27 | so if we want JADE in Shogun I think I might re-work it from the Author's C release | 22:14 |
pickle27 | because from that angle I'll be able to produce a more readable algorihtm | 22:14 |
pickle27 | also | 22:15 |
pickle27 | a related question | 22:15 |
lisitsyn | pickle27: if the code is changeable go for it sure | 22:15 |
@iglesiasg | lambday: I guess we should wait for Heiko to review your PR and merge them | 22:15 |
pickle27 | because I am working separately from Shogun at the moment how should I share code for the time being? | 22:15 |
lambday | iglesiasg: yes... because travis passed for this new PR... I hope it will pass | 22:16 |
@iglesiasg | it probably will :) | 22:16 |
pickle27 | lisitsyn: this will probably help explain the situation http://pastebin.com/gvHxCTFV | 22:16 |
pickle27 | lisitsyn: I wrote the top function but the second function is directly from the R package | 22:17 |
pickle27 | I just think it would be quite difficult to redo jadiagw using Eigen etc because the code isn't really commented at all | 22:18 |
pickle27 | so it depends what we want, because it works its just not readable. So if we want to include I think it would be best if I ported the authors code and used Eigen3 | 22:19 |
pickle27 | or maybe its not as bad as I think and I just need to spend some more time looking at the code | 22:19 |
lisitsyn | pickle27: no I think there is no need to rewire jadiagw | 22:21 |
pickle27 | lisitsyn: okay then I will leave it | 22:22 |
lisitsyn | rewrite* | 22:22 |
pickle27 | lisitsyn: then I'll focus on double checking that my result matches the jointDiag package before continuing onto FFdiag | 22:24 |
lisitsyn | pickle27: yes makes sense to me | 22:24 |
pickle27 | lisitsyn: any thoughts on what I should do about making my code available before its ready to merge in? | 22:25 |
pickle27 | pickle27: I mean I can keep making pastes when I want to discuss something | 22:25 |
lisitsyn | pickle27: do you have some test in mind? | 22:25 |
lisitsyn | pickle27: same thing as PR is better | 22:25 |
lisitsyn | as others can comment too and no need to say 'line XXX: something' | 22:26 |
pickle27 | okay so make PRs to shogun | 22:26 |
pickle27 | lisitsyn: as for the test yes I have something worked out. Its a synthetic example from the R package | 22:27 |
lisitsyn | pickle27: I'd say that code is quite simple though :D | 22:27 |
lisitsyn | pickle27: I integrated the SLEP library last gsoc | 22:28 |
lisitsyn | that was much more crazy C code | 22:28 |
lisitsyn | that's why I am unsure it works :D | 22:28 |
lisitsyn | well I compared matrices and numbers and so on | 22:28 |
lisitsyn | but one never knows what the code works in all the cases | 22:28 |
pickle27 | lisitsyn: yeah i mean its not that bad but it would take time to convert to eigen if thats what was wanted | 22:29 |
pickle27 | but if you think its okay as loops then Im okay with it | 22:29 |
lisitsyn | pickle27: as far as I can see it won't be much better with eigen | 22:29 |
pickle27 | lisitsyn: I was kind of thinking that too | 22:29 |
pickle27 | but I wouldn't mind a few more comments | 22:29 |
lisitsyn | I don't really imagine how such code is written | 22:29 |
pickle27 | anyways | 22:29 |
pickle27 | for the test I have a synth example but it is randomly generated each time | 22:30 |
pickle27 | so I need to save the input case to disk so I can run the C++ code and the R package on the same data | 22:30 |
-!- lambday [67157d4f@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.125.79] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 22:30 | |
pickle27 | make sure they get the same result | 22:30 |
lisitsyn | please keep that test too | 22:30 |
pickle27 | lisitsyn: of course! | 22:31 |
pickle27 | its bascially a unit test as is | 22:31 |
lisitsyn | pickle27: heiko has an idea about that like comparing with libraries | 22:31 |
lisitsyn | yes though we can't really compare R and C++ in our unit-tests | 22:31 |
pickle27 | oh the test itself is self contained | 22:32 |
pickle27 | because in the end you can test if the matrix is a permutation matrix | 22:32 |
pickle27 | so if it is then the test passes | 22:32 |
@sonney2k | iglesiasg, why do you need a custommahalanobis distance? | 22:32 |
pickle27 | otherwise fail | 22:32 |
pickle27 | its the same self contained test in both R and C++ but they each gen new data each time | 22:33 |
pickle27 | its just a one time check to make sure they give the same result | 22:33 |
lisitsyn | pickle27: I see | 22:33 |
@iglesiasg | sonney2k: I didn't find any other distance which allowed me to compute (x_i - x_j)^T M (x_i - x_j) for a given matrix M | 22:33 |
lisitsyn | sonney2k: do you mean to allow custom matrices in mahalanobis? | 22:34 |
pickle27 | lisitsyn: okay I have to head out for a bit now | 22:36 |
pickle27 | I'll be back later | 22:36 |
lisitsyn | pickle27: see you! | 22:37 |
-!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 22:37 | |
@sonney2k | lisitsyn, it basically is the CMahalanobisdistance with a custom icov | 22:39 |
lisitsyn | sonney2k: yes | 22:39 |
@sonney2k | quite some code duplication | 22:39 |
@iglesiasg | sonney2k: yes, that is exactly the idea, the custom icov not to duplicate code :) | 22:39 |
@sonney2k | can't we generalize mahalanobisdistance to learn icov | 22:41 |
@iglesiasg | it sounds pretty reasonable | 22:41 |
@sonney2k | I don't mind it getting the eigen3 treat btw | 22:42 |
lisitsyn | sonney2k: oh I need your opinion on changing a bit in our io | 22:42 |
lisitsyn | sonney2k: https://github.com/lisitsyn/formatting I can change shogun to use it | 22:43 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 22:48 | |
shogun-notifier- | shogun: Soeren Sonnenburg :develop * 29e2882 / src/.version.sh: https://github.com/shogun-toolbox/shogun/commit/29e2882cac5c3c6de8e569c697daebc60d75a232 | 22:48 |
shogun-notifier- | shogun: use the current branch as merge base when creating version strings | 22:48 |
lisitsyn | {} instead of %d %s %i et | 22:49 |
lisitsyn | etc | 22:49 |
@sonney2k | lisitsyn, what will it do with pointers and what with SGObjects? | 22:49 |
lisitsyn | sonney2k: currently prints what lies under the pointer | 22:50 |
lisitsyn | easy to specialize for SGObjects | 22:50 |
lisitsyn | with ->name() | 22:50 |
-!- hushell [~hushell@67.23.197.94] has joined #shogun | 22:50 | |
@sonney2k | how can I print the pointer itself for an SGObject? | 22:50 |
lisitsyn | sonney2k: static_cast<void*>(obj) could do that | 22:51 |
lisitsyn | is that usual case? | 22:51 |
lisitsyn | sonney2k: it has implementation class which is specialized so I think we can tune it if we go for that | 22:53 |
lisitsyn | when generic it just << the object/value | 22:53 |
@sonney2k | shouldn't appear to often - we use it when printing objects (memory debugging IIRC Combined* etc) | 22:53 |
lisitsyn | sonney2k: other way would be to add an adapter like | 22:54 |
@sonney2k | and how do you do formatting - I mean saying you want two digits for a double etc? | 22:55 |
lisitsyn | sonney2k: that's more difficult question | 22:55 |
lisitsyn | I didn't come with good solution so far | 22:55 |
@sonney2k | or print a hex insteaf of an int? | 22:55 |
lisitsyn | sonney2k: I would do that through adapters like that | 22:55 |
@sonney2k | I mean I don't like our SGIO* but it probably is not the biggest issue we have atm | 22:55 |
lisitsyn | format("{}", hex(3)); | 22:56 |
lisitsyn | sonney2k: no that was just my experiment | 22:56 |
@sonney2k | lisitsyn, would be cool to have your modelselection syntax | 22:56 |
@sonney2k | anyway no more time cu | 22:56 |
lisitsyn | sonney2k: see you | 22:56 |
@iglesiasg | good night | 22:56 |
lisitsyn | mod.sel. is on the way but I don't like some thing | 22:57 |
lisitsyn | iglesiasg: what do you think about string keys? | 22:57 |
lisitsyn | obj.parameter("width") | 22:57 |
@iglesiasg | I don't see it, tell me more | 22:58 |
lisitsyn | iglesiasg: I hate getters and setters | 22:58 |
lisitsyn | that's it :D | 22:58 |
lisitsyn | I mean writing them all around | 22:59 |
lisitsyn | that's terrible thing I always feel pain right in my ass | 22:59 |
lisitsyn | and that's not the medical issue :D | 22:59 |
@iglesiasg | :D yeah I also feel quite stupid when doing them | 22:59 |
lisitsyn | I spend my days writing getters in java | 23:00 |
lisitsyn | I would be younger and happier w/o them | 23:00 |
lisitsyn | and now I am 73 and I am still writing them | 23:00 |
@iglesiasg | well eclipse helps you quite a bit in java with them right? | 23:00 |
@iglesiasg | hehe | 23:00 |
lisitsyn | iglesiasg: oh no eclipse, idea | 23:00 |
lisitsyn | idea is much much better | 23:00 |
lisitsyn | iglesiasg: I wish there was such an ide for C++ :D | 23:03 |
@iglesiasg | yeah I wish it too sometimes | 23:04 |
shogun-buildbot | build #973 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/973 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:04 |
@iglesiasg | on the other hand, I sometimes thinks it helps too much | 23:05 |
-!- hushell [~hushell@67.23.197.94] has quit [Ping timeout: 264 seconds] | 23:05 | |
shogun-buildbot | build #1141 of bsd1 - libshogun is complete: Failure [failed test test_1] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/1141 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:12 |
-!- hushell [~hushell@67.23.197.94] has joined #shogun | 23:16 | |
-!- travis-ci [~travis-ci@ec2-54-226-106-169.compute-1.amazonaws.com] has joined #shogun | 23:17 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg'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/8440044 | 23:17 |
-!- travis-ci [~travis-ci@ec2-54-226-106-169.compute-1.amazonaws.com] has left #shogun [] | 23:17 | |
-!- hushell [~hushell@67.23.197.94] has quit [Ping timeout: 276 seconds] | 23:22 | |
shogun-buildbot | build #1264 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/1264 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:46 |
--- Log closed Wed Jun 26 00:00:05 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!