Open in new window / Try shogun cloud
--- Log opened Mon Sep 02 00:00:41 2013
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]01:18
-!- hushell [~hushell@c-98-232-178-161.hsd1.or.comcast.net] has joined #shogun02:45
-!- sonne|osx_ [~sonne@f053040230.adsl.alicedsl.de] has joined #shogun03:38
-!- sonne|osx [~sonne@g225080229.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]03:40
-!- sonne|osx_ is now known as sonne|osx03:40
-!- gsomix [~gsomix@85.26.232.136] has joined #shogun06:56
gsomixsonney2k, sonne|osx hey. I will be available today at evening.06:57
gsomixI finally finished all works at home.06:59
gsomixgtg06:59
-!- gsomix [~gsomix@85.26.232.136] has quit [Client Quit]06:59
-!- sonne|osx [~sonne@f053040230.adsl.alicedsl.de] has quit [Quit: sonne|osx]06:59
-!- sonne|osx [~sonne@82.113.121.20] has joined #shogun08:09
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun08:19
shogun-notifier-shogun: Soeren Sonnenburg :develop * c00c71a / examples/undocumented/python_modular/ (167 files): https://github.com/shogun-toolbox/shogun/commit/c00c71a6cf13ed166dc52bb6395d4ec82874189408:19
shogun-notifier-shogun: drop shogun.* structure and import from modshogun instead08:19
-!- sonne|osx [~sonne@82.113.121.20] has quit [Quit: sonne|osx]08:25
-!- travis-ci [~travis-ci@ec2-54-211-15-52.compute-1.amazonaws.com] has joined #shogun09:00
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/1088229609:00
-!- travis-ci [~travis-ci@ec2-54-211-15-52.compute-1.amazonaws.com] has left #shogun []09:00
shogun-buildbotbuild #1951 of deb1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/195109:08
shogun-buildbotbuild #1579 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1579  blamelist: Soeren Sonnenburg <sonne@debian.org>09:13
shogun-buildbotbuild #1664 of deb3 - modular_interfaces is complete: Failure [failed test python_modular]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1664  blamelist: Soeren Sonnenburg <sonne@debian.org>09:43
shogun-buildbotbuild #1363 of cyg1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/cyg1%20-%20libshogun/builds/1363  blamelist: Soeren Sonnenburg <sonne@debian.org>09:50
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun09:53
shogun-buildbotbuild #1042 of rpm1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/rpm1%20-%20libshogun/builds/104209:59
-!- van51 [~van51@ppp-94-66-92-175.home.otenet.gr] has joined #shogun10:55
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]11:19
-!- lambday [67157d4c@gateway/web/freenode/ip.103.21.125.76] has joined #shogun11:22
-!- iglesiasg [~iglesias@n157-p43.kthopen.kth.se] has joined #shogun11:29
-!- mode/#shogun [+o iglesiasg] by ChanServ11:30
@iglesiasgsonney2k, ping11:36
-!- van51 [~van51@ppp-94-66-92-175.home.otenet.gr] has quit [Quit: Leaving.]11:37
@iglesiasgsomeone around here who has used / is using the octave modular interface?11:37
-!- van51 [~van51@94.66.92.175] has joined #shogun11:37
-!- thoralf [~thoralf@enki.zib.de] has joined #shogun12:11
thoralfHey.12:12
@iglesiasgHello12:12
-!- HeikoS [~heiko@nat-169-160.internal.eduroam.ucl.ac.uk] has joined #shogun12:13
-!- mode/#shogun [+o HeikoS] by ChanServ12:13
thoralfiglesiasg: You're the guy who did the SO-learning in shogun, right?  Then you probably know something about the bundle method implementation?12:13
thoralfHeikoShi12:13
@HeikoSthoralf: hi!12:14
@iglesiasgthoralf, at the phone12:18
lisitsynthoralf: I know a bit12:22
@iglesiasgthoralf, here I am12:25
@HeikoSlambday: hi!12:25
@iglesiasgthoralf, I have a very high level understanding of the method. Very little idea bout Michal's implementation12:26
@iglesiasgonly that it is hardcore C code12:26
thoralflisitsyn: Okay, I'm using simple BMRM and getting mean results.  (First of all it had some severe memory issues, but I fixed it.)  So I'm thinking of using the other implemented methods and I'm not sure if it's worth fixing them as well. ;)12:26
@iglesiasgI think there were even gotos :O12:26
@iglesiasgthoralf, Michal mentioned that the other methods were much faster12:27
thoralflisitsyn: I have very high dimensional data (2^32) and it takes loooong time to converge, lots of memory (no wonder ;))12:27
@HeikoSthoralf: it would be cool if you could make these things work and maybe even probide some examples and unit-tests ;)12:27
thoralfHeikoS: I'm not surprised that you're mentioning unit-tests. :)12:28
@HeikoSthoralf: haha :)12:28
@HeikoSthoralf: well, without them, this is what you get: memory issues and loads of problems12:28
@HeikoSespecially if the original author is gone12:28
thoralfHeikoS is the unit-test man.  While wiking is the RTFM man. :D12:28
@HeikoSand noone has an idea how things work12:28
@HeikoSthoralf: just trying to make our code sustainable ;)12:29
@HeikoShaha, yeah very true ,th12:29
@HeikoS, thoralf12:29
lisitsynthoralf: so what's the question? ;)12:29
thoralflisitsyn: Just some experience about the other methods.  Accuracy, time, memory, convergence... ;)12:30
thoralflisitsyn: But iglesiasg already answered that. :)12:30
thoralflisitsyn: Of course, only empirically.12:30
lisitsynthoralf: ah I see12:31
thoralflisitsyn: Btw. did you check that the implementation is correct?  Or can tell pathological cases to test that?12:32
@iglesiasgthoralf, but I suggest you to have a look at their paper12:32
lisitsynthoralf: well it works as multiclass svm12:32
@iglesiasgthoralf, Vojtech and Michal have a paper about these methods IIRC12:32
@iglesiasgthoralf, I tested it in multiclass SVM and HM-SVM and worked well. Michal tested that in his GSoC too12:33
@iglesiasgbut I found some problems later on with my grid graph model12:33
thoralfiglesiasg: I know the referenced papers (Teo, C.H., Vishwanathan, S.V.N, Smola, A. and Quoc, V.Le. as well as Tsochantaridis, I., Hofmann, T., Joachims, T., Altun, Y.)12:33
thoralfiglesiasg: But I'll have a look at their paper.12:33
@iglesiasgTsochantaridis doesn't talk about bundle methods, does it?12:34
thoralfiglesiasg: He doesn't.12:34
@iglesiasgabout Teo, I am not sure if it is just BMRM or the other ones as well12:34
thoralfiglesiasg: But he has been cited in DualLibQPBMSOSVM.h12:34
@iglesiasgI see12:34
@iglesiasgthoralf, I have also spoken with Michal a few times over google chat and he has been pretty helpful, so I guess you can count on that too12:36
thoralfiglesiasg: Yeah, but I should read the paper first.12:37
thoralfYou helped a lot so far.12:37
@iglesiasgBundle Methods for Structured Output Learning--Back to the Roots12:39
@iglesiasgthoralf, I think that one contains what in Shogun is called PPBMRM and P3BMRM12:40
thoralfiglesiasg: Btw. I've been pimping the SO-model/-machine implementation to parallelize across 32 cores. :)12:40
@iglesiasgthoralf, cool!12:40
@iglesiasgare you using some framework for parallelizing it?12:40
thoralfiglesiasg: No, yes.  I tried both pthreads and openmp.12:41
thoralfiglesiasg: But the resulting code looks more beautiful with openmp.12:41
@iglesiasgnice12:41
@HeikoSthoralf: go for openmp, we will soon have some mechanism for this in shogun12:41
@HeikoSand openmp is less work ;)12:41
thoralfHeikoS: I know. :)12:41
thoralf(both)12:41
@HeikoSthoralf: currently playing with PBS backend for independent jobs12:42
@HeikoSworks pretty nice12:42
thoralfPBS?12:42
@HeikoSand this gives a unified interface for any parallel thing12:42
@HeikoSthoralf: batch cluster system12:42
@HeikoSthoralf: where one can submit jobs to12:42
thoralfHeikoS: Cool.  Which system?12:42
thoralfHeikoS: SUN?12:42
@HeikoSthoralf: the qsub based one, we call it PBS here12:43
@HeikoSbut the sun interface is same I think12:43
thoralfHeikoS: qsub/sqsub... should be the same.12:44
@HeikoSthoralf: yep12:44
@HeikoSall the batch systems are similar, there is also this SLURM12:44
@HeikoSand its nice to (ab)use them for parallelization within algorithms12:45
@HeikoSdoesnt make always sense, but sometimes its very useful12:45
@HeikoSthoralf: we also want to hapen openmp style parallelization12:46
thoralfHeikoS: Cross validation/parameter tuning makes sense.12:46
@HeikoSthoralf: yep exactly, this will be one bigger example12:46
thoralfHeikoS: I already have a experiment running using openmp/pthreads to parallelize locally.12:47
@HeikoSthoralf: cool, maybe we can share experience12:47
@HeikoSthoralf: I want to tackle this later in the year or early next one12:47
@HeikoSthoralf: maybe with lambday if he has time12:47
thoralfHeikoS: I already did some fixed with this cross-validation-pthread-issue if you remember.12:48
thoralfHeikoS: So shogun is ready for this.12:48
@HeikoSthoralf: nice!12:48
@HeikoSthoralf: if we had thread safe subsets then we can also parallelize x-bvalidation12:48
thoralfHeikoS: (If you don't remember: It's the issue where I refused to do unit tests. ;))12:49
@HeikoSthoralf: currently, svm and x-validation doesnt work from mutliple threads12:49
@HeikoSthoralf: I remember :D12:49
@iglesiasgHeikoS, I remember now what I wanted to ask you the other day! haha12:50
thoralfHeikoS: Building examples is very time consuming, so I'll take any help I get, because I really would like to help, but have other things to do. :)12:50
@HeikoSthoralf: I know this is why I am asking people all the time12:50
@HeikoSiglesiasg: ha! ok :)12:50
@iglesiasgHeikoS, about the ipython notebook. I have these i.pynb_checkpoints directory, no problem removing it I guess?12:50
@HeikoSiglesiasg: I think not12:51
thoralfHeikoS: I have many other local changes to prepare for sparse computations.  (In my cases speeding up to factor 20)12:51
@HeikoSits all for storing the kernel12:51
@HeikoSthoralf: nice!12:51
@HeikoSvery cool!12:51
thoralfHeikoS: It's no rocket sience - just lot of work and testing. ;)12:51
thoralfGotta work, see you later and thanks for helping.12:52
@HeikoSok, thanks also, bye!12:52
-!- van51 [~van51@94.66.92.175] has quit [Quit: Leaving.]12:54
lambdayHeikoS: hey12:56
@HeikoSlambday: hi!12:56
@HeikoSlambday: how are things?12:56
lambdayHeikoS: sorry I didn't notice12:56
lambdayHeikoS: CG-M is bad :(12:56
lambdayI am currently running each and every thing step by step12:56
lambdayCG-M related12:56
@HeikoSlambday: what is bad?12:56
lambdaysomething is really off12:56
@HeikoSwhat exactly happens?12:56
@HeikoSlambday: and what works?12:57
lambdaythe test I am doing, I took a small matrix.... and then solving it just for one shift... and then comparing it with a CG-solver moving that one shift into the diag12:57
@HeikoSok?12:57
lambdayHeikoS: ideally these two should be converging towards the same point12:58
lambdaybut CG-M moves somewhere else12:58
lambdaytrying to figure out what causes this.. and if there is a mistake in my implementation than that of paper12:58
@HeikoSlambday: CIterativeShiftedLinearFamilySolver right?12:58
lambdayHeikoS: then I will try this approach - in the paper (the mail I sent you) they plotted the residual12:58
lambdayHeikoS: that's where it computes the shifted  stuffs12:59
lambdayzeta/beta/alpha_sh things12:59
lambdayHeikoS: well, one idea is thsi12:59
@HeikoSlambday: with these kind of problems, you should try to test all parts, starting from the very smallest12:59
lambdaythe plot of residual in the paper - it seems to have a weird zigzag nature13:00
lambdayHeikoS: yes that's what I am trying to do13:00
@iglesiasgKTH completely closed one day due to Obama coming!13:00
@HeikoSlambday: then thats good, there are probably also some bugs in the code, there always are13:00
@iglesiasgno office for me on Wednesday :(13:00
@HeikoSlambday: so this will be good anyway13:00
@HeikoSiglesiasg: haha ;)13:00
lisitsyniglesiasg: instead of russia ;)13:00
@HeikoSlambday: keep in mind, usually errors are caused by simple thing13:01
@HeikoSs13:01
@HeikoSso dont get too involved in alternatives, testing is the best way to understand whats the problem13:01
lambdayHeikoS: I need to make it work :( .. I will plot the residual and then will see...13:01
lambdayyes13:01
@HeikoSso if you can find the exact point where things fail, this will be useful13:01
@HeikoSlambday: dont get stressed out, I am sure you will find the problem soon13:02
lambdayHeikoS: yes.. but its impossible to know prior to the iterations whether something will converge or not for shifted family solver13:02
lambdaythat'13:02
@HeikoSlambday: try to focus on simpler things first, not too many other methods and plots13:02
lambdays what the paper says13:02
lambdayalright13:02
@HeikoSlambday: you have to explain that ^13:02
lambdayHeikoS: we cannot know whether a shifted family with cg-m solver will converge or not13:03
thoralflambday: You're sure that the solution/the first step is canonical?13:03
lambdaythere is another convergence test (after running the algorithm)13:03
lambdayHeikoS: I didn't get... first step??13:04
@HeikoSlambday: how do you terminate currently?13:04
lambdayHeikoS: based on the tolerence on residual13:04
lambdaywhich is 1E-513:04
@HeikoSlambday: I mean if this is the case, then there has to be a warning to the user to increase accuracy, or even a restart with increased accuracy13:04
lambdayby default13:04
lambdayumm.. yes...13:05
@HeikoSlambday: its just important to be aware of that13:05
@HeikoSlambday: but I believe there is a bug or something13:05
@HeikoSlambday: the matrices you were using were all easy13:05
lambdaycurrently I have that "did not converge"...13:05
@HeikoSand the ones I tested were too13:05
@HeikoSlambday: what if you increase accuracy or number of its qiute a bit, what happens?13:06
lambdayHeikoS: yeah that's what I think... just like the probing sampler thing, it took me quite a long time where the mistake was coming from13:06
@HeikoSlambday: yeah13:06
@HeikoSlambday: so just keep on testing different things, this we you also know what you can rely on13:06
@HeikoSlambday: but make sure you use some non-trivial problems in the tests at some point to simulate difficulty13:07
lambdaywhat I have noticed, sometimes it doesn't converge at all... I tried with tolerence 0.01 even still doesn13:07
lambday't work13:07
hushellwiking: hey, how do we set up Mosek in CMake?13:07
lambdayHeikoS: yes.. but first things have to work for small things at least..13:07
@HeikoSlambday: yep true13:07
@HeikoSlambday: ok, keep on pushing it :) I will today finish the cluster stuff13:08
lambdayHeikoS: did you notice anything regarding CG-M convergence in your implementation13:08
@HeikoSlambday: I solved individually since I was in a rush13:08
@HeikoSlambday: but you can of course ask daniel/erlend13:08
@HeikoSthough again, I would search for bugs first and try to understand why things break13:09
@HeikoSwhen does it diverge etc?13:09
lambdayyes that's what I was going to say13:09
lambday:)13:09
@HeikoSdoes it depend on the smallest eigenvalues?13:09
@HeikoSor on something else13:09
@HeikoSusually those bastards cause trouble ;)13:09
lambdaynah.. not eigenvalues :(13:09
lambday:D13:09
lambdaythe ozone matrix has really horrible cond number13:10
lambday:-o13:10
@HeikoSlambday: yes13:10
@HeikoSin fact its almost inf13:10
@HeikoSI added a ridge on the diagonal ;)13:10
@HeikoSbe back soon13:10
lambdayokie13:10
lambdayI too am getting back to work :)13:10
lambdayciao :)13:10
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun13:25
@iglesiasgis there a reason why we are changing in python to import everything from modshogun instead of shogun.*?13:48
lisitsyniglesiasg: I can say yes13:48
lisitsynbut can't say why13:48
lisitsynI don't remember13:48
@iglesiasghaha ok13:48
@iglesiasgso should I expect that any time soon shogun.* imports won't be supported any more?13:48
lisitsynanything shogun.Whatever is just an alias to modshogun13:49
lisitsynyou can from shogun.Features import SVM13:49
@iglesiasghahaha13:49
@iglesiasgok13:49
@iglesiasgthat is a good reason to stop doing that then13:49
lisitsynthat's just backcompatibility13:49
@iglesiasgit just adds a layer of confusion IMHO13:49
lisitsynyes the seventh layer of hell13:50
lisitsynor whatever level :)13:50
@iglesiasghehe yeah13:51
@iglesiasgI am changing my local examples to modshogun then13:53
-!- sonne|work [~sonnenbu@91-64-72-127-dynip.superkabel.de] has joined #shogun13:57
@iglesiasgsonne|work, hello hello14:04
@iglesiasggot a question about octave modular14:04
@iglesiasgsonne|work, if I open an octave session and do modshogun and then exit14:04
@iglesiasgit segfaults ?rettu badly14:05
@iglesiasgoh shit, ?rettu, was supposed to be pretty (bad hand position)14:05
@iglesiasgis that expected behaviour?14:05
sonne|workiglesiasg: no14:07
@iglesiasgthen we've got a problem14:07
@iglesiasgthoralf, very nice unit tests in that PR ;)14:09
@HeikoSiglesiasg: no need to do that I always do from shogun.Bla import Bla14:09
@HeikoSvotjakovr: hi!14:10
@iglesiasgHeikoS, in Octave?14:10
@HeikoSiglesiasg: o that I dont know, just read the first bits of your dialog with sergey14:10
@iglesiasgI didn't know  that from .. import works in Octave as well14:10
@HeikoSvotjakovr: could you give me a quick status update on what parts you are currently working?14:10
@iglesiasgHeikoS, aah all right. I actually prefer importing everything from modshogun. And now even more after knowing that all shogun.Bla are just alias for modshogun. I don't like the idea that from shogun.Features import SVM works14:11
@HeikoSiglesiasg: why? because its not really doing that but just faking it?14:12
@iglesiasgHeikoS, well what's the point on having to remember all shogun.Features, shogun.Classifier, etc if they just import from modshogun?14:13
@iglesiasgI rather just remember modshogun14:13
@HeikoSiglesiasg: yeah agreed14:13
@iglesiasgand even better do stuff like14:13
@iglesiasgimport modshogun14:13
@iglesiasgmodshogun.RealFeatures() ...14:13
@iglesiasgalthough I have not tried if that works yet14:13
@iglesiasgI guess it does14:13
votjakovrHeikoS: hi! I'm currently working on gradient model selection, i've found some problems and thinking on it.14:20
@HeikoSvotjakovr: what problems? which part exactly, being curious here ;)14:21
votjakovrHeikoS: problem #1: As you said, we need to perform gradient descent on some subset of the all possible parameters14:23
@HeikoSvotjakovr: yep, thats important. It is in principle possible via changing the parameter trees. However, since the GP model selection assumes that all parameters are there ,this breaks. Any plans for improving this oddity?14:24
votjakovrHeikoS: for doing this we need to pass current parameter combination to GradientMachineEvaluation class14:25
@HeikoSvotjakovr: yes, thats the way to go14:25
votjakovrHeikoS: and then pass it to inference classes to find the derivatives14:25
@HeikoSvotjakovr: that seems very sensible14:26
@HeikoSvotjakovr: should be hidden to the outside world though, getting derivatives via parameter combinations14:27
@HeikoSvotjakovr: since its a bit weird, a parameter combination is a fixed set of parameters with values14:27
@HeikoSvotjakovr: and here you rather want a set of parameters as strings14:27
votjakovrHeikoS: hmm.. don't understand a little bit, what you mean14:29
@HeikoSvotjakovr: a parameter combination should not be passed to the GP objects14:30
@HeikoSvotjakovr: parameter combinations are there to apply a fixed set of parameters to a machine14:30
@HeikoSvotjakovr: asking for derivatives should rather work for the currently active paramters (set from parameter combination before), and the parameter could be selected via a set of strings or so14:30
@HeikoSvotjakovr: but pls dont pass the parameter combination around14:31
@HeikoSvotjakovr: see what I mean?14:31
sonne|workiglesiasg: the reason for all that is that we really had different modules under shogun - really shogun.Features etc14:32
@iglesiasgsonne|work, aham, then it made sense before14:32
sonne|workiglesiasg: however these created issues like the one you just said - octave crashed when two modules got loaded14:33
sonne|workserialization was a problem14:33
sonne|workit was a problem to keep objects accross modules14:33
votjakovrHeikoS: yeah, but now we have, that derivatives are computed wrt all of the possible parameters (kernel, likelihood, etc) of the machine14:33
@iglesiasgsonne|work, any idea what can be wrong with this octave issue?14:33
sonne|workiglesiasg: so that is why we removed this14:33
@iglesiasgsonne|work, it works fine when I do octave some_example.m14:34
@iglesiasgno segfault then14:34
@HeikoSvotjakovr: I agree this is not good, one should provide a set of strings to select14:34
sonne|workiglesiasg: well we don't have withe the stuff on the buildbot right?14:34
@HeikoSvotjakovr: do you think that would work?14:34
sonne|workiglesiasg: well give us a valgrind / gdb backtrace14:34
@HeikoSvotjakovr: and then model selection applies the current parameter combinatzion first, then asks for derivatives via this set of strings?14:34
@iglesiasgsonne|work, all right. I will open an issue in a few minutes14:34
votjakovrHeikoS: we could use current param_dict but as a parameter, not build it there14:35
@HeikoSvotjakovr: and this string set is created from parameter tree that user gave14:35
votjakovrHeikoS: yeah, that what i mean14:35
@HeikoSvotjakovr: param dict should be ok14:36
@HeikoSvotjakovr: ah no14:36
@HeikoSvotjakovr: please dont pass those around14:37
@HeikoScontains too much14:37
@HeikoSpointers to data etc14:37
@HeikoSrather the gradients should be selected by name, this is sufficient information and everything else just makes things complicated14:37
@HeikoSnames can be extracted easily internally14:37
@HeikoSget_derivatives(set of strings)14:37
votjakovrHeikoS: Map<char*, SGObject*>?14:38
@HeikoSvotjakovr: why an sg object when you call a method on the object?14:38
@HeikoSgp->get_derivatives(strings ) should do it shouldnt it?14:38
votjakovrHeikoS: what if you have kernel and likelihood with the same parameter name?14:39
@HeikoSvotjakovr: good point, what is currently done with that?14:39
@HeikoSare the TParameter instances matched?14:39
@HeikoSactually, you might be right, the param_dict might be the best way to do it14:40
@HeikoSmatch the unique TParameter instance rather than just name14:40
@HeikoSalthough its still a bit dirty, but ok, should do it14:40
votjakovrHeikoS: now it isn't done14:41
@iglesiasguhm something wrong with features_string_file_char_modular.py and features_string_file_modular.py_14:42
@HeikoSvotjakovr: yeah I remember, that why we started the discussion ;)14:42
@iglesiasghttps://travis-ci.org/shogun-toolbox/shogun/jobs/1089016814:42
@iglesiasgI will restart the job just in case it was something random, maybe worth to look at in any case14:42
votjakovrHeikoS: also i'd like to ask about public m_parameters and m_model_selection_parameters members... Please could you explain why it is done like this?14:45
@HeikoSvotjakovr: what exactly dont you like?14:46
votjakovrHeikoS: i'm just asking:) when should i use m_parameters instead of m_model_selection_parameters?14:47
@HeikoSvotjakovr: about m_parameters, you have to ask sonne|work, sonney2k, I added the model-selection parameters a few years ago during gsoc14:47
@HeikoSvotjakovr: ah I see14:47
@HeikoSvotjakovr: so shogun classes have parameters14:47
@HeikoSfor serialization/clone/equals14:47
@HeikoSeverything is registered14:47
@HeikoSvotjakovr: and then the model-selection parameters are a subset of those, for which model-selection is possible14:48
@HeikoSvotjakovr: but these things are pointing to the very same memory14:48
@HeikoSvotjakovr: so all model-selection parameters are also in m_parameters14:48
votjakovrHeikoS: yep, i see, thanks :) So is model selection working only with m_model_selection_parameters?14:50
@HeikoS votjakovr, yes14:51
@HeikoSvotjakovr: everything else should be blocked ;)14:51
votjakovrHeikoS: i'm a little bit confused when i see m_parameters in build_parameter_dictionary() method since build_parameter_dictionary() is used only in GPs gradients14:51
@HeikoSvotjakovr: yep, thats weird, feel free to improve this14:52
votjakovrHeikoS: ok :) problem #2: don't get random values from the parameter tree14:53
@HeikoSvotjakovr: you want to remove that?14:54
@HeikoSvotjakovr: I totally agree, rather, use the currently set parameters to start. This way users can define starting values the same way as in GPML14:55
votjakovrHeikoS: i think we should use current machine parameters instead of picking random form the tree14:55
@HeikoSvotjakovr: I am with you there14:55
@HeikoSvotjakovr: random search model selection should stay though, as its kind of nice to get initial good values14:55
@HeikoSvotjakovr: another nice things would be not having to previously specify the range of the parameters to search for14:57
@HeikoSvotjakovr: so the parameter tree would just consist of names and sgobjects, but no values14:57
votjakovrHeikoS: yeah! i'd like to ask you about that, but you've done this first :)14:58
@HeikoSvotjakovr: good! ok I got another point, things should be unit-tested and made work for regression.14:59
@HeikoSvotjakovr: once this is done, classification should be easy to add right?14:59
votjakovrHeikoS: yeah14:59
@HeikoSvotjakovr: ok then, on which things of the discussed are you currently working?15:00
@HeikoSvotjakovr: how long do you think this will take?15:00
votjakovrHeikoS: 1-2 day without testing15:00
votjakovrHeikoS: 3 days15:00
votjakovrHeikoS: with testing15:00
votjakovr:)15:00
votjakovrHeikoS: i'd like to ask: can we now use the tree without specifying particular range of values for parameters?15:02
@HeikoSvotjakovr: I am not sure about that. But if not, this should be easy to change15:02
@HeikoSvotjakovr: there is a field in the tree elements which contains the data15:02
@HeikoSvotjakovr: and it can be NULL or so15:02
@HeikoSchecking15:02
@HeikoSvotjakovr:15:03
@HeikoSvoid* m_values;15:03
votjakovrHeikoS: ok, great :)15:03
@HeikoSvotjakovr: the way I suggest to do this is to create trees with just names and no data15:03
@HeikoSand if assertions are in the way (I might have put them there), remove them :)15:04
votjakovrHeikoS: yeah15:04
@HeikoSvotjakovr: and you will have to excuse the code in there, its from when I started to really learn about c++. I wasnt a programmer as good as you back then ;)15:04
votjakovrHeikoS: ok, no problem :)15:05
votjakovrHeikoS: btw when thing will be done for regression we can use it for classification too without any changes, i think15:06
votjakovrHeikoS: we'll minimize negative marginal likelihood in both cases15:09
votjakovrHeikoS: btw, have a look at: http://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/machine/gp/InferenceMethod.cpp#L5315:13
thoralfiglesiasg: Thanks for your comment.  Didn't realize that point - but you're right.15:13
votjakovrHeikoS: why is model selection not available for mean there?15:14
@iglesiasgthoralf, it is fun to check the runtime of algorithms :)15:21
thoralfiglesiasg: Normally this is my part - I must have been distracted. ;)15:25
@iglesiasghehe15:25
@iglesiasgthoralf, let me know if you think the change I suggest makes sense15:26
thoralfiglesiasg: I think you're wrong.  The while(left<=right) loop only produces a partition with (left: all elements < pivot) and (right: all elements >= pivot), but does not compare them pairwise.  So If I'm giving you a list with [10 times random(1,10)] + [10 times random(11,20)], then the swap-count is zero, but the list is still not sorted. ;)15:31
thoralfiglesiasg: BUT: Having a is_sorted() check at the beginning does something like you said. ;)15:31
@iglesiasgthoralf, the swap count wouldn't be zero for the initial array15:32
@iglesiasgthoralf, it would be zero for the sorted half, in case it turns out that one of the splittings does not include anything from the random part15:32
@iglesiasglet me double-check in any case15:33
thoralfiglesiasg: But it doesn't help us, since I found an example where the count is zero but the lists are still not sorted.15:33
@iglesiasgthoralf, mmm no15:33
@iglesiasgthoralf, I mean15:33
thoralf[1;0;4;3] <-- Try this15:33
thoralfsplit:=215:34
thoralfNo swap takes place.15:34
@iglesiasgsplit is the value of the element I think15:34
thoralfcount would be zero15:34
@iglesiasgthen split = 415:34
thoralfT split=output[size/2] <--415:34
@iglesiasgyep15:35
thoralfOkay, you're right.  Need another example.15:35
@iglesiasg:)15:35
thoralf[1;0;3;4] <-- Try this15:35
thoralfpivot:=list[4/2]=315:36
thoralfiglesiasg: A completly different argument: qsort is proved to have nlogn best-case complexity.  In case you're right, many other people would be wrong. ;)15:37
thoralfI clever person is overruled by many dump persons.  Like Galileo. :D15:37
thoralfs/I/A/15:38
@iglesiasgthoralf, does it break in your example?15:38
@iglesiasgI think there is actually a swapin there15:38
thoralfiglesiasg: Shall I write an example program? ;)15:38
@iglesiasgthoralf, well now we are talking about your example first :)15:39
@HeikoSthoralf, iglesiasg so you are taking care of the PR? :) I was just about to merge15:39
@iglesiasgHeikoS, merge merge15:39
@HeikoSsince it doesnt really hurt15:40
@HeikoSbut doing15:40
@iglesiasgjust discussing15:40
@HeikoSif (!sorted)15:40
@HeikoS    sort15:40
@HeikoSis not so nice15:40
@HeikoSthat was my point15:40
@HeikoSanyway15:40
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun15:40
shogun-notifier-shogun: Thoralf Klein :develop * 8a2fe8a / / (3 files): https://github.com/shogun-toolbox/shogun/commit/8a2fe8a57c7c9acf82d14fee655cf71823a7933f15:40
shogun-notifier-shogun: Added method "is_sorted()" to SGVector15:40
shogun-notifier-shogun: * plus unit tests for SGVector::qsort() and SGVector::is_sorted().15:40
shogun-notifier-shogun: Heiko Strathmann :develop * dbe34ba / / (3 files): https://github.com/shogun-toolbox/shogun/commit/dbe34baedc02fad0f67674b2a133f07c70c5b86615:40
shogun-notifier-shogun: Merge pull request #1507 from tklein23/sgvector_is_sorted15:40
shogun-notifier-shogun:15:40
shogun-notifier-shogun: Added method "is_sorted()" to SGVector15:40
lisitsynoh guys you keep overloading sgvector with stuff ;)15:41
@iglesiasgthat is a good point15:42
@iglesiasgthoralf, but I think you must be right due to the best-case complexity argument15:43
votjakovrHeikoS: should model selection be available for mean function? http://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/machine/gp/InferenceMethod.cpp#L6015:43
@iglesiasgthoralf, but I am not 100% :P15:44
@HeikoSvotjakovr: no, since the only way to do this is via grid-search15:44
@iglesiasg100% sure15:44
@HeikoSvotjakovr: I would just register the ML2 things, i.e. real parameters15:44
votjakovrHeikoS: Great! Thanks :)15:45
thoralfiglesiasg: Again, you're right.  But different than you might think:15:45
thoralfiglesiasg: it swaps output[2] against output[2]15:45
@iglesiasgyeah15:45
@iglesiasgI noticed that15:45
@iglesiasghehe15:45
thoralfiglesiasg: But I think this is a bug. ;)15:45
votjakovrHeikoS: no sgobjects like kernel, likelihood function?15:45
@HeikoSvotjakovr: ah sorry, I think you need to register them since they have sub-parameters15:46
@HeikoSvotjakovr: so the mean function also should be registered15:46
@HeikoSvotjakovr: but since it has no sub-parameters for ZeroMean, no need to register anything in there15:46
thoralfHeikoS: Thanks for merging.15:47
@iglesiasgthoralf, yes, it might be that the if should only be executed for left<right15:47
votjakovrHeikoS: but we may use not only ZeroMean15:47
@iglesiasgthoralf, not <=15:47
@HeikoSvotjakovr: yeah so register it15:47
votjakovrHeikoS: ok :)15:47
@HeikoSvotjakovr: if we have a mean with a sub-parameter its useful15:48
@iglesiasgthoralf, anyhow I am cool with the is_sorted method and the current qsort15:48
-!- besser82 [~besser82@fedora/besser82] has joined #shogun15:48
thoralfiglesiasg: There are two left<=right :)15:48
@HeikoSvotjakovr: oh and one thing, it would be good to have some "default" mode, where a user doesnt have to pass a parameter tree, and *all* parameters are optimised by defauilt15:48
@HeikoSvotjakovr: since this is the usual case people want, and no need for parameter trees there15:49
@iglesiasgthoralf, the if, I said15:49
besser82Just want to say hello and tell you I am going to package shogun for Fedora && RHEL ;)15:49
votjakovrHeikoS: yeah, that would be nice15:49
@iglesiasgbesser82, cool, thanks!15:49
@HeikoSvotjakovr: but its easy to add once other things work15:50
besser82igleasiasg, ^^15:50
@HeikoSbesser82: thats great! maybe we could add a buildbot for that?15:50
@HeikoSor even add it to our nightly generated packages?15:50
@HeikoSbesser82: you should talk to sonney2k and/or wiking about that once you have made some progress, that would be very useful for us15:50
besser82HeikoS, sure you can do, but I'm going to bring this into official repos ;)15:50
lambdayHeikoS: FIXED IT :D :D :D15:51
@HeikoSbesser82: sweet! :)15:51
@HeikoSlambday: whoooo!15:51
lambdaymore more more tests15:51
@HeikoSwhat was it?15:51
@HeikoS:D15:51
lambdayARGH!!15:51
lambdaylot of them15:51
@HeikoSwrong {} ? _D15:51
lambdayI am the biggest idiot on the face of the earth :D15:51
lambdayno no15:51
lambdaymany mistakes combination15:51
lambdayphew!15:51
lambdaywait wait!15:51
lambday:D15:51
@HeikoShehe :) so send the PR. and make sure all those bugs are added to tests ;)15:52
@iglesiasgbesser82, I have no idea how all this packaging works, so maybe this is a stupid question. The code to do this will be in the Shogun repo or somewhere else?15:52
lambdayHeikoS: I added way too many debug msgs15:52
lambdayah crunched each and every number15:52
besser82HeikoS, thx ;) Will talk to sonney2k and wiking about this, but can I have you on some further words in a 1:1? I think we are both on same native (German) :)15:52
@HeikoSbesser82: sure!15:52
lambdayHeikoS: brb :D15:53
@HeikoSlambday: ok! looking forward to the PR :)15:53
besser82iglesiasg, the spec-file to build the rpms will be in fedora's SCM-git ;) The resulting rpms inside Fedora Repo or EPEL repo, so you can easy install with `yum install ...` ;)15:53
lambdayHeikoS: will send real soon15:53
@iglesiasgbesser82, got it, thanks!15:54
shogun-buildbotbuild #1580 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1580  blamelist: Thoralf Klein <thoralf.klein@zib.de>16:03
thoralfHeikoS: if (!sorted) sort <-- Won't help out, because it's called recursively and will check sorting over-and-over on every iteration. :D16:05
@iglesiasgsonne|work, BTW, the pictures are not yet in the webpage! Do you have the ones you took with your phone? I can put them in the our team page if so16:06
@iglesiasgor maybe we can put the picture with all of us that Cheng sent to the mailing list16:06
@HeikoSiglesiasg: can you access the buildbot site?16:08
votjakovrHeikoS: i've just sent a PR with some minor fixes, please, have a look (i'm trying not to blow up diffs in PRs)16:08
@iglesiasgHeikoS, http://buildbot.shogun-toolbox.org/? Access meaning change stuff of it?16:08
@HeikoSiglesiasg: didnt we have fedora in there a while ago?16:09
@iglesiasgHeikoS, there is this rmp1 libshogun16:10
@iglesiasgrpm1 sorry16:10
@HeikoSwhat os is that?16:10
@HeikoSredhat16:10
@iglesiasgaham, besser82 mentioned about rpms in Fedora Repo, that's why I thought16:11
shogun-notifier-shogun: Roman Votyakov :develop * b871fbb / src/shogun/machine/gp/ (11 files): https://github.com/shogun-toolbox/shogun/commit/b871fbb81e36b7d660f81325dc9f2cf490e6239316:18
shogun-notifier-shogun: minor fixes in GP framework16:18
shogun-notifier-shogun: Heiko Strathmann :develop * 88efc31 / src/shogun/machine/gp/ (11 files): https://github.com/shogun-toolbox/shogun/commit/88efc31c40e5d25d28c6a43a1782f473d47c9eac16:18
shogun-notifier-shogun: Merge pull request #1511 from votjakovr/feature/gp_refactoring16:18
shogun-notifier-shogun:16:18
shogun-notifier-shogun: Minor fixes in GP framework16:18
@HeikoSvotjakovr: ^16:18
votjakovrHeikoS: thanks :)16:19
votjakovrHeikoS: btw i think we need a review for kernel's classes, probably write missing unit-tests, etc. But after GSoC16:21
@HeikoSvotjakovr: absolutely! put it on your list :)16:22
besser82sonne|work: are you free for a minute? Or shall I ping you later?16:33
shogun-buildbotbuild #1581 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1581  blamelist: Roman Votyakov <votjakovr@gmail.com>16:35
lambdayHeikoS: sending the PR16:36
lambdayHeikoS: added a new test for log-det also, using CG-M16:37
lambday:D16:37
lambdaygives equal accuracy as direct solver16:37
lambdayHeikoS: will add ozone data examples now in this week16:37
sonne|workbesser82: just quick please - gtg in 5 mins16:38
shogun-buildbotbuild #1364 of cyg1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/cyg1%20-%20libshogun/builds/1364  blamelist: Thoralf Klein <thoralf.klein@zib.de>16:39
besser82sonne|work: i want to know more about the elwms-interface...16:39
sonne|workiglesiasg: yes no pictures no talk uploads...16:40
sonne|workiglesiasg: we suck publicity wise16:40
@iglesiasgwe shall continue being annoying with wiking for the talk uploads16:41
@iglesiasgI guess he will probably do them soon16:41
lambdayHeikoS: please have a look at the PR.. I'll come back later.. starving :)16:41
@iglesiasgsonne|work, but you do have the pictures, right? Just mail them to me if so16:41
shogun-buildbotbuild #1582 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1582  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>16:42
-!- lambday [67157d4c@gateway/web/freenode/ip.103.21.125.76] has quit []16:42
shogun-buildbotbuild #1583 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1583  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>16:47
shogun-notifier-shogun: lambday :develop * 675b19d / / (9 files): https://github.com/shogun-toolbox/shogun/commit/675b19d9e98134be132e598eaad9c3787a13e0fc16:47
shogun-notifier-shogun: CG, COCG, CG-M solver fixed (log-det)16:47
shogun-notifier-shogun: Heiko Strathmann :develop * b2b8af9 / / (9 files): https://github.com/shogun-toolbox/shogun/commit/b2b8af95e9b811bf0a659a1f6ad3a8e48a3ddd7e16:47
shogun-notifier-shogun: Merge pull request #1512 from lambday/feature/log_determinant16:47
shogun-notifier-shogun:16:47
shogun-notifier-shogun: CG, COCG, CG-M solver fixed (log-det)16:47
-!- travis-ci [~travis-ci@ec2-174-129-83-121.compute-1.amazonaws.com] has joined #shogun16:50
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/1089421416:50
-!- travis-ci [~travis-ci@ec2-174-129-83-121.compute-1.amazonaws.com] has left #shogun []16:50
@HeikoSthoralf: MulticlassOCASTest.train fails16:52
@HeikoSis that your fault?16:52
@HeikoSI merged before travis was green  :(16:52
thoralfHeikoS: I ran the tests locally and they were all green.16:52
@HeikoSthoralf: ok dont know what that is than16:53
@HeikoSthen16:53
thoralfHeikoS: I'll double check in a second.16:53
@HeikoSthoralf: thanks!16:54
votjakovrHeikoS: have a look at the issue: http://github.com/shogun-toolbox/shogun/issues/141116:54
@HeikoSvotjakovr thanks!16:54
@HeikoSthoralf: ^16:54
thoralfHeikoS: Ah, okay.16:55
shogun-buildbotbuild #1665 of deb3 - modular_interfaces is complete: Failure [failed test python_modular]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1665  blamelist: Thoralf Klein <thoralf.klein@zib.de>16:57
-!- sonne|osx [~sonne@89.204.139.210] has joined #shogun16:58
sonne|osxbesser82: I have another 15 mins :)16:59
besser82sonne|osx: What is the elwms-interface about? Is it worth to pacakage this for fedora/rhel?16:59
sonne|osxbesser82: I would focus on libshogun and its developer files first, then do python_modular, octave_modular maybe java_modular. These are IMHO the most important interfaces. Some will cry ruby_modular but hmmhh.17:01
besser82sonne|osx: kk, will do ;) thx! and how about to run the integration tests in recent git-checkout?17:01
sonne|osxbesser82: so rather leave out all static interfaces like elwms_* and python_*17:01
besser82sonne|osx: I think you meant *_static???17:02
sonne|osxbesser82: unit or integration tests?17:02
sonne|osxbesser82: yes17:02
besser82sonne|osx: preferably both of them ;)17:02
@iglesiasgsonne|osx, BTW, there is not current way to build static, right? I realized yesterday that the configure script is gone.17:02
sonne|osxbesser82: our current build system runs unit tests already upon build17:02
sonne|osxbesser82: well there is now17:03
besser82sonne|osx: will need them in %check-target of spec.  Other Fedora maintainer will complain on review otherwise ;)17:03
sonne|osxbesser82: agh ok then run ctest manually17:03
sonne|osxbesser82: you can look up how to separate the steps by reproducing what we do on the buildbot17:04
besser82sonne|osx: kk, any source where to find the whole cli-switches needed?17:04
sonne|osxbesser82: look here http://buildbot.shogun-toolbox.org/waterfall17:04
sonne|osxand then deb3 - modular interfaces17:04
besser82sonne|osx: thx! Will do.17:04
sonne|osxthe stdio in the very beginning lists you exactly what we call cmake with17:04
besser82sonne|osx: thx, ctest I'll find there as well, I guess?17:05
sonne|osxbesser82: yes that is part of cmake17:05
* besser82 takes a look inside sonne|osx's provided link ;)17:06
sonne|osxbesser82: btw once you have sth - we could run it during our nightly builds...17:06
besser82sonne|osx: sth?17:06
sonne|osxbesser82: might be easier this way to not break stuff. when I do deb's I intend to do the same17:06
sonne|osxbesser82: something17:06
besser82sonne|osx: kk, long line today ;P17:07
besser82sonne|osx: I could give you access to Koji as well. so you can run builds from my spec on RHEL and Fedora ;)17:07
sonne|osxbesser82: btw your work is highly anticipated by some ...17:08
sonne|osxwe got a couple of complaints lets say :)17:08
besser82sonne|osx: why? what? ???17:08
besser82what did I do wrong ???17:09
sonne|osxwell users that don't like compiling shogun from source :)17:09
sonne|osxbesser82: nothing17:09
sonne|osxthey want .rpm's17:09
besser82:D17:10
besser82sonne|osx: nice joke ;)17:10
sonne|osxbesser82: go please them :)17:11
besser82sonne|osx: I'll do !17:11
besser82sonne|osx: think I can push-out whole thing for review during this week...17:12
besser82If someone want's to join-in: I can bring new contributors to Fedora ;)17:13
* besser82 is Packager-Sponsor for Fedora ;)17:13
besser82and knows half folks from Fedora's sci-tech SIG17:14
sonne|osxbesser82: I am a debian developer... but nice try :)17:14
shogun-buildbotbuild #1584 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1584  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>17:14
sonne|osxbesser82: but seriously I can have a look at the spec17:15
besser82sonne|osx: sound good! Thanks for the offer will bring my spec to github asap.  btw .debian-folks didn't want me some years back :(17:15
sonne|osxbesser82: it always depends whom you get in touch with... I had a pretty good sponsor so it was fun back then when I still had lots of time17:17
shogun-buildbotbuild #72 of osx1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/osx1%20-%20libshogun/builds/72  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Soeren Sonnenburg <sonne@debian.org>, Thoralf Klein <thoralf.klein@zib.de>, Roman Votyakov <votjakovr@gmail.com>17:17
sonne|osxnow I am mostly overwhelmed and doing shogun only at least ATM17:17
besser82sonne|osx: yes, it surely depends on the persons you get in touch with...17:18
shogun-notifier-shogun: Soeren Sonnenburg :develop * 6723325 / examples/undocumented/python_modular/graphical/ (39 files): https://github.com/shogun-toolbox/shogun/commit/6723325cd5bdb82ce23209054899d26230661aca17:18
shogun-notifier-shogun: replace shogun.* modules with modshogun17:18
shogun-buildbotbuild #1666 of deb3 - modular_interfaces is complete: Failure [failed install test python_modular]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1666  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Roman Votyakov <votjakovr@gmail.com>17:19
besser82sonne|osx: thanks for the nice talk, I'll get back back to get my shogun.spec ready and in shape ;)17:20
sonne|osxbesser82: thanks and I gtg anyway now17:20
besser82sonne|osx: Which will be the upcoming version in Oct?17:20
sonne|osxbesser82: thanks for your work and keep us updated17:20
besser82sonne|osx: 2.2.0?17:20
sonne|osx3.0.017:20
* sonne|osx off17:20
-!- sonne|osx [~sonne@89.204.139.210] has quit [Quit: sonne|osx]17:20
besser82So I guess I'll package 3.0.0 pre-release-snap from git ;)17:21
@HeikoSvotjakovr: are you there?17:21
shogun-buildbotbuild #1365 of cyg1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/cyg1%20-%20libshogun/builds/1365  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, Roman Votyakov <votjakovr@gmail.com>17:22
shogun-buildbotbuild #1046 of rpm1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/rpm1%20-%20libshogun/builds/1046  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>17:24
shogun-buildbotbuild #1957 of deb1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1957  blamelist: Soeren Sonnenburg <sonne@debian.org>17:27
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.]17:29
votjakovrHeikoS: yeap17:35
@HeikoSvotjakovr: nevermind, had a build error with gp stuff, but that was my faiult17:36
@HeikoScmake still tricks my sometimes17:36
votjakovrHeikoS: ok17:38
-!- foulwall [~zhengyang@114.255.40.7] has quit [Ping timeout: 246 seconds]17:45
-!- foulwall [~zhengyang@114.255.40.7] has joined #shogun17:45
-!- sonne|osx [~sonne@f053040230.adsl.alicedsl.de] has joined #shogun17:51
shogun-buildbotbuild #74 of osx1 - libshogun is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/osx1%20-%20libshogun/builds/74  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>17:53
votjakovrHeikoS: may i ask another question? Why do we need to have 2 classes of Gaussian distribution? I mean Gaussian and GaussianDistribution.17:54
-!- pickle27 [~kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun17:55
-!- travis-ci [~travis-ci@ec2-174-129-83-121.compute-1.amazonaws.com] has joined #shogun17:58
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/1089576117:58
-!- travis-ci [~travis-ci@ec2-174-129-83-121.compute-1.amazonaws.com] has left #shogun []17:58
@HeikoSvotjakovr: thats a good point18:00
@HeikoSvotjakovr: so historically, CGaussian was developed for Gaussian density estimation, ie EM18:00
@HeikoSvotjakovr: so the interface is developed for that18:00
@HeikoSbut the CGaussianDistribution is more a classical distribution interface: log_pdf and sampling18:01
@HeikoSvotjakovr: I could not really merge them since the scope is too different.18:01
@HeikoSvotjakovr: also CGaussianDistribution has no features attached18:01
@HeikoSCGaussian can probably be a subclass of CGaussianDistribution btw18:01
shogun-buildbotbuild #1668 of deb3 - modular_interfaces is complete: Failure [failed test python_modular]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1668  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>18:01
@HeikoSbut we have to base classes which are in conflict there18:02
-!- HeikoS [~heiko@nat-169-160.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.]18:02
shogun-buildbotbuild #1366 of cyg1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/cyg1%20-%20libshogun/builds/1366  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>, lambday <heavensdevil6909@gmail.com>18:03
-!- HeikoS [~heiko@nat-169-160.internal.eduroam.ucl.ac.uk] has joined #shogun18:04
-!- mode/#shogun [+o HeikoS] by ChanServ18:04
votjakovrHeikoS: yep, now i see, thank you :)18:07
@HeikoSvotjakovr: I di dnot really like the CGaussian also thats why I did a new one :)18:07
@iglesiasgsonne|work, can I get sicpy in the fatbot please? :)18:10
@iglesiasgsudo apt-get install python-scipy18:10
@iglesiasgsonne|osx, sonney2k ^18:11
votjakovrpickle27: hi! while doing some refactoring of evaluation classes, i've found evaluation/ica. I think that this stuff should be moved to SGMatrix class, since it is pretty general and not related to machine evaluation18:14
@iglesiasgvotjakovr, maybe in Math better?18:17
@iglesiasgI also support the idea that we shouldn't make out SGVector and SGMatrix classes fatter18:17
@iglesiasgout->our18:17
-!- van51 [~van51@ppp-94-66-92-175.home.otenet.gr] has joined #shogun18:18
votjakovriglesiasg: hmm... i think, that these 2 functions might be useful for other people and i think it's better to call something like mat.is_permutation_matrix() rather then something else18:20
@iglesiasgvotjakovr, it makes sense. But then at least have the main implementation in Math and just a wrapper in SGMatrix18:21
votjakovriglesiasg: probably, but i still don't understand, why implementation of these 2 functions in SGMatrix.cpp is bad18:24
-!- iglesiasg [~iglesias@n157-p43.kthopen.kth.se] has quit [Ping timeout: 245 seconds]18:25
votjakovriglesiasg: pickle27: but i'm pretty sure, that this stuff should be moved from evaluation/ica18:26
-!- iglesiasg [~iglesias@2001:6b0:1:1041:b8ef:b3e:75c0:30ef] has joined #shogun18:37
-!- mode/#shogun [+o iglesiasg] by ChanServ18:37
@sonney2kiglesiasg, installed18:49
@iglesiasgsonney2k, thanks!18:49
@iglesiasgembarrassed of asking this but18:53
@iglesiasghow do I install Shogun so I can use the Python modular interface in a computer where I cannot sudo?18:53
@iglesiasgmaybe defining the install dir in cmake?18:54
@iglesiasgalthough IIRC thoralf did something like install-local when we had the configure script18:54
-!- lambday [67157f36@gateway/web/freenode/ip.103.21.127.54] has joined #shogun19:05
lambdayHeikoS: hi19:05
@HeikoSlambday: hi!19:05
lambdayHeikoS: I will add some more examples19:05
@HeikoSI am currently editing rational approx to automagically compute the number of shifts if wanted19:05
@HeikoSlambday: btw the thing works better now19:05
@HeikoSvery slow though19:05
lambdayHeikoS: yeah :D19:05
@HeikoSbut the shifts will speed it up at least19:06
@HeikoSthen I will try it with the ozone19:06
lambdayHeikoS: number of shifts I will add to the class itself19:06
@sonney2kiglesiasg, well look at the output of cmake19:06
@HeikoSlambday: what?19:06
@sonney2kit says at the end19:06
lambdayHeikoS: I should test this with ozone19:06
@HeikoSwhat do you mean?19:06
lambdayHeikoS: number of shifts should be computed within LogDetEstimator itself given the accuracy the user wants19:06
lambdayright?19:06
lambdaythat's a simple computation19:06
@HeikoSlambday: yeah but in the rational approx class19:07
@iglesiasgsonney2k, thank you, my bad19:07
@HeikoSI will add it to precompute19:07
@HeikoSonce the eigenvalues are know, this can be done19:07
lambdayHeikoS: where we explicitly have to mention the number of shifts, right19:07
lambdayyes I will change that19:07
@HeikoSlambday: no let me do it19:07
lambdaybut things work better now19:07
@HeikoSI already started ;)19:07
lambdayHeikoS: awesome19:07
lambday:D19:07
lambdayHeikoS: I should also check this against the ozone matrix19:08
lambdaywait I am checking19:08
-!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has joined #shogun19:08
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/1089681819:08
-!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has left #shogun []19:08
lambday(just got back, kinda sloshed :( )19:08
lambdaywhat's the error? :)(19:08
lambday:(19:08
@HeikoS?19:09
pickle27iglesiasg: votjakovr yes I agree with re factoring those functions19:09
pickle27iglesiasg: votjakovr I don't have a preference where though, whatever you think is best19:09
lambdayHeikoS: checking the travis msgs19:09
pickle27also make sure you update all the ajd unit tests after you move it19:09
@HeikoSah ok19:09
@sonney2kHeikoS, pickle27 - can anyone reproduce https://github.com/shogun-toolbox/shogun/issues/1509 ?19:10
lambdayHeikoS: argh I put display matrix and etc in RationalApproximation unit test19:10
lambdaychanging19:11
@HeikoSlambday: oops I did not see that19:11
lambdayHeikoS: just saw19:11
@HeikoSlambday: next thing, we have to have a check that the minimum eigenvalue is positive. Happens quite often that it is not. We need an error message for the user in that case that tells him to increase accuracy of eigensolver or add a ridge19:13
pickle27sonney2k: just tried on my system and no I can't reproduce19:14
@HeikoSlambday: btw never do this:19:14
@HeikoSCMath::log(max_eig/min_eig)19:14
@HeikoSif max_eig/min_eig is a very large number you get an overflow and the log fails19:14
@HeikoSlog(a/b)=log(a)-log(b)19:14
@HeikoSI will chang ein the unit test19:15
lambdayHeikoS: okay19:16
lambday:-/19:16
lambdayumm... I did that inside RationalApproximation, right?19:16
@HeikoSlambday: no, in the unit test19:16
@HeikoSlambday: I copy pasted it :)19:16
@HeikoSbut just realised this might cause problems19:16
lambdayHeikoS: yeah you are right19:16
@HeikoSlog of product should always be done in log-domain19:16
@HeikoSits a neat trick, helps very often19:16
lambdayHeikoS: but I also used similar things while computing shifts/weights...19:17
@HeikoSlambday: if the numbers are small thats fine19:17
lambdayHeikoS: yeah I should be changing those19:17
@HeikoSbut maybe check later19:17
@HeikoSbut a condition number of a matrix might be huge19:17
lambdayHeikoS: I thought float64_t has a really higher range so it should not create problems19:17
lambdayHeikoS: yup19:17
lambdaytrue19:17
lambdayI need to add this over next week19:17
@sonney2kpickle27, iglesiasg so which swig and octave versions?19:19
@iglesiasgsonney2k,  SWIG Version 2.0.4, GNU Octave, version 3.6.219:20
shogun-buildbotbuild #1667 of deb3 - modular_interfaces is complete: Failure [failed compile csharp_modular]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1667  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>19:24
@HeikoSlambday:19:27
@HeikoSI have this weird eigen error again19:27
@HeikoSlambday: see pm19:28
@HeikoSits only if I do the unit tests19:28
@HeikoSso disabling and relying on travis for now19:29
lambdayHeikoS: I didn't get :-/419:30
lambdayHeikoS: wait let me see19:30
@HeikoSits the probing sampler who does it19:32
@HeikoSthats why travis doesnt detect it, no probing sampler in there since no colpaclk19:32
lambdayHeikoS: I don't get any such errors :( I have colpack19:34
@HeikoSlambday: whats your eigen version?19:35
@HeikoSits an eigen interface problem, they added or removed an assertion19:35
@HeikoSdo you let shogun bundle it or use your own version?19:35
-!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has joined #shogun19: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/1089814219:35
-!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has left #shogun []19:35
lambdayHeikoS: shogun cmake detects my own version19:36
@HeikoSlambday:  no its eigen19:37
@HeikoSlambday: did you update all unit tests after the last pr?19:37
@HeikoSunit tests break19:37
@HeikoS[ RUN      ] RationalApproximation.compare_direct_vs_cocg_accuracy/home/travis/build/shogun-toolbox/shogun/tests/unit/mathematics/logdet/RationalApproximation_unittest.cc:279: FailureThe difference between (map_xd-map_xs).norm() and 0.0 is 0.013105116035746187, which exceeds 0.01, where(map_xd-map_xs).norm() evaluates to 0.013105116035746187,0.0 evaluates to 0, and19:37
@HeikoSlambday: I guess you saw that ;)19:37
lambdayHeikoS: yeah I saw, but I changed it :-/19:38
lambdayanyway... I am not sure19:38
lambdaywait I am checking19:38
lambdaycocg sucks it means :-/19:39
lambdayI should test19:39
@HeikoSlambday: yes, everything has to be tested ;)19:44
@HeikoSI know its annoying19:44
@HeikoSlambday: whats your eigen3 version?19:45
lambdaychecking19:45
besser82is it intentional git-checkout FTBFS when .git-dir is removed?19:50
@sonney2kbesser82, no - we switched to cmake recently and it looks like we still have some rough edges...19:58
-!- van51 [~van51@ppp-94-66-92-175.home.otenet.gr] has quit [Read error: Connection reset by peer]19:59
besser82sonney2k: kk, cmake complains about missing value in version.cmake line 48...19:59
lambdayHeikoS: can't find the version20:01
lambdayHeikoS: errr.... issues with fedora?20:01
lambdayHeikoS: where can I find the version?20:01
lambdayall headers are in /usr/include/eigen3/20:02
besser82lambday: repoquery -a --installed | grep -i "eigen"20:02
besser82lambday: which version of F you use?20:03
lambdaybesser82: but I didn't download it from repo20:03
besser82lamnday: custom build?20:03
lambdaybesser82: I downloaded it manually and installed it20:03
lambdayyes20:03
lambdaybesser82: I am not in ubuntu/deb but in fedora20:03
besser82lambday: me, too ;)20:04
besser82lambday: F19 ships Eigen3 in repos ;)20:04
lambdaybesser82: I am an old man, I use F1620:04
lambday:(20:04
besser82lambday: then update to some supported version ;)20:04
lambdaybesser82: no other way from the installed dirs?20:04
lambdaybesser82: at this moment that is not being possible :(20:05
besser82lambday: there might be more problems than just version20:05
besser82lambday: used configure-flags and all ;)20:05
besser82lambday: u know how to use rpmbuild?20:05
lambdaybesser82: configure flags? for what?20:05
@sonney2kbesser82, the version thing should be trivial to fix for someone with cmake skillz20:05
besser82lambday: when building eigen3 ;)20:05
@sonney2kbesser82, our expert is away for a week so it will take me a while20:06
lambdaybesser82: I don't understand... eigen3 is just a bunch of headers :(20:06
besser82sonney2k: i can fix, but just wanted to make sure if it is intentional ;)20:06
lambdaybesser82: I always installed it by hand20:06
besser82sonney2k: me wrote cmake-buildsys around libyui ;)20:07
besser82lambday: let me check in pkgdb ;)20:07
lambdaysonney2k: wiking is getting married or he is attending some marriage :D20:07
@sonney2kbesser82, IIRC we do the following: if .git exists we extract the version from git - actually from develop branch or master - the current branch20:07
@sonney2klambday, he got married last GSoC so this time he is just attending :)20:08
lambdayhehe... ohkay :D20:08
@sonney2kbesser82, if .git is not available we extract the date from NEWS - because then it is supposed to be a release20:08
lambdaybesser82: no other way to know from the installed headers? they never tell it there, do they20:09
besser82lambday: not really ;)20:09
lambday:'(20:09
@HeikoSlambday: so did you find our the version?20:09
lambdayHeikoS: no :(20:09
@HeikoSlambday: maybe just tell cmake to bundle it20:09
@HeikoSthen you are using the same version as me20:10
lambdayHeikoS: I think it was some 3.1.something20:10
besser82lambday: if know how to handle rpmbuild, i can give you srpm from current fedora....20:10
lambdayHeikoS: how do I do that?20:10
@HeikoSlambday: could you try to compile with bundled eigen?20:10
@HeikoSBUNDLE_EIGEN=On20:10
lambdayHeikoS: alright20:10
@HeikoSI use ccmake for setting those20:10
lambdayHeikoS: ccmake? I only know how to use cmake for shogun20:11
lambday:(20:11
@HeikoSccmake is a "graphical" frontend20:11
@HeikoSncurses based I think20:11
lambdayokay20:11
lambdayHeikoS: so from cmdline, BUNDLE_EIGEN=ON should do right?>20:12
@iglesiasgcmake .. -DBUNDLE_EIGEN=ON20:12
lambdaybesser82: never used it :-/ ... can try20:12
besser82lambday: kk, will generate srpm for you ;)  Can I have your email for sending, please?20:13
lambdaybesser82: heavensdevil6909@gmail.com20:13
lambdayiglesiasg: thanks, trying20:13
besser82lambday: srpm should be there in a minute ;)20:15
besser82you need to `yum group install fedora-packager`20:16
lambdaybesser82: ah, thanks :D20:16
lambdaybesser82: so this will all go smooth from f16?20:16
besser82I think so ;)20:16
-!- iglesiasg [~iglesias@2001:6b0:1:1041:b8ef:b3e:75c0:30ef] has quit [Quit: Ex-Chat]20:16
besser82in F16 there's eigen 3.0.6 in repos ;)20:16
lambdaybesser82: I am definitely using a newer version20:17
lambdayprobably 3.1.something20:17
lambdayanyway I am trying20:17
besser82lambday: unpack srpm (with file-roller or such)20:17
besser82lambday: you need to `yum group install fedora-packager`20:18
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]20:18
besser82lambday: then `sudo yum-builddep $PATH_TO/eigen3.spec`20:19
besser82lambday: then mkdir -p ~/rpmbuild/SOURCES/20:19
lambdaybesser82: alright20:19
lambdaybesser82: :( "Warning: Group fedora-package does not exist."20:20
besser82lambday: copy eigen3-tarball to ~/rpmbuild/SOURCES20:20
lambdaybesser82: errr20:20
besser82you forgot the "r" --> fedora-packageR20:20
lambdaysorry20:20
lambdaybesser82: yes20:20
lambdaybesser82: thanks :D20:21
besser82lambday: np ;)20:21
besser82lambday: when done with all previous steps run: rpmbuild -ba $PATH_TO/eigen3.spec20:21
@HeikoSlambday: and?20:28
lambdaybesser82: HeikoS building20:29
@HeikoSok20:29
lambdayphew! I thought installing eigen3 was easy20:30
lambday:-/20:30
lambdayHeikoS: which version are you using?20:30
@HeikoSlambday: the bundled one20:30
@HeikoSlambday: and you now?20:31
lambdayHeikoS: that option didn't help me20:31
lambdayHeikoS: its 3.1.320:31
@HeikoSlambday: why? oh you should fill in an issue and assign it to wiking then20:31
lambdayHeikoS: not installed yet20:31
lambdayHeikoS: yeah I will push him...20:31
@HeikoSI use 3.1.2 I think20:32
@HeikoSso lets see whether you get the error20:32
lambdayHeikoS: any idea what causes this error?20:32
@HeikoSyes some eigen interface change20:32
lambdayHeikoS: because my earlier version was also 3.1.something and I didn't get any error20:32
@HeikoSmethod not allowed for integer number20:32
lambdayHeikoS: errrr20:32
@HeikoS/home/heiko/Desktop/shogun/shogun/tests/unit/mathematics/logdet/ProbingSampler_unittest.cc:78:210:   required from here20:32
@HeikoS/home/heiko/Desktop/shogun/shogun/third_party/include/eigen/Eigen/src/Core/MathFunctions.h:429:5: error: static assertion failed: THIS_FUNCTION_IS_NOT_FOR_INTEGER_NUMERIC_TYPES20:32
@HeikoSone of those eigen static assertions that allow to hunt down type errors20:33
lambdayHeikoS: checking20:33
lambdaybesser82: the part you said is complete20:33
lambdaybesser82: that's it, right?20:33
besser82lambday: so rpmbuild i finished?20:33
besser82lambday: then you need to install built rpms ;)20:34
lambdaybesser82: rpmbuild -ba $PATH_TO/eigen3.spec finished20:34
besser82lambday: rpmbuild told which rpm were built and where they were put ;)20:34
besser82lambday: you can usually find them in ~/rpmbuild/RPMS/$arch/20:35
besser82lambday: you can use yum install $path_to/eigen3-devel.rpm20:35
lambdaybesser82: I used rpm -ivh <the-rpm>20:36
lambdaybesser82: that would do, right?20:36
lambdayHeikoS: its 3.1.4 btw :D20:37
besser82lambday: will be another way to install properly ;)20:37
lambdayFound Eigen3: /usr/include/eigen3 (found suitable version "3.1.4", required is "3.1.2")20:38
lambdayHeikoS: argh, I would have found from this msg itself I think :-/20:39
lambdayanyway building20:39
lambdaybesser82: thanks a lot, man!20:39
lambdaybesser82: you are a lifesaver20:39
lambday:) :)20:39
besser82lambday: np ;)  make sure to kill eigen3 version in /usr/local ;)20:39
lambdaybesser82: already moved20:39
lambdayto eigen3_old20:40
lambday :D20:40
besser82lambday: kk, then all is fine ;)20:40
lambdayHeikoS: yep you are right20:41
lambdayI get this error20:41
lambdayHeikoS: wait I am checking20:41
@HeikoSlambday:  cool, if you found a fix, let me know ;)20:41
@HeikoSI need unit tests20:41
lambdaysure20:41
@HeikoSchanging things...20:41
besser82sonney2k: on make install built-examples get installed, too.  Thats nasty...  I wouldn't expect to get them installed ;)20:43
lambdayHeikoS: this is a stupid error :( the obvious way is to convert it to float64_t :(20:44
lambdayI can do that :(20:44
besser82lambday: :D20:44
lambdaybesser82: :D :(20:44
@HeikoSlambday: no let me do it20:44
@HeikoSsending a pr already20:44
@HeikoSwhich file and line?20:44
lambdayHeikoS: alright20:44
lambdayHeikoS: I already committed regarding the display_matrix/vector thing, so sending a PR with just that20:45
@HeikoSlambday: then put in the other thing too :)20:45
lambdayHeikoS: other things as in?20:45
-!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has joined #shogun20:46
lambdayHeikoS: in the sampler itself... nothing has to changed, just that eigen3 can't compute norms for ints it seems20:46
lambdayHeikoS: sorry I meant in the unit-test itself20:46
lambdayHeikoS: in the unit-test, I computed the coloring seperately, and used our Probing sampler to compute the coloring and then compare these two colorings20:47
lambdayHeikoS: these color things are in int32_t, for which eigen3 can't compute norm now :(20:47
@HeikoSlambday: weird20:48
@HeikoSlambday: put the fix for the eigen error in the pr20:48
lambdayHeikoS: really weird!20:48
@HeikoSlambday: it makes sense that eigen cannot do that20:48
lambdayHeikoS: why is that?20:48
@HeikoSprevents weird type errors20:48
@HeikoSif you want to stay in int domain20:48
@HeikoSand c is typed so thats the way it should be20:49
@HeikoSeigen vectors are typed too20:49
@HeikoSyou can probably convert it explicitly20:49
lambdaybut what's wrong with computing norm?20:49
lambdayimplicit typecast is available all across the lang :(20:49
@HeikoSits not even defined for vectors over N^n20:49
@HeikoSwell20:50
@HeikoSthats the way it is20:50
@HeikoScould you send the PR so that I can rebase against it?20:50
lambdayHeikoS: you mean, changing the unit-test as well?20:50
@HeikoSlambday: yes20:50
lambdayHeikoS: alright.. just a moment20:50
lambdayHeikoS: I need to change the default to DISTANCE_TWO coloring btw.. I will add some tests for checking against computing power first and then coloring 1-distance and computing 2-distance directly on the matrix20:53
@HeikoSlambday: ok thats good20:53
@HeikoSlambday: what do you think of the idea to add copies of all existing unit tests with the ozone matrix?20:54
lambdayHeikoS: that would be perfect!20:54
lambdayHeikoS: I have to put the big ozone_matrix in somewhere in the repo then, right?20:54
@HeikoSlambday: yes, how big is the sparse thing?20:55
lambday70+ MB20:55
lambdayin smvlight format20:55
lambdayHeikoS: sent the PR20:57
@HeikoSlambday: phew!20:57
@HeikoSsonney2k: can we add a 70mb data matrix to data?20:57
lambdaysonney2k:  :(20:57
@HeikoSlambday: tests are green?20:58
lambdayHeikoS: just added20:58
@HeikoSat your machine?20:58
lambdayHeikoS: yes at my machine yes20:58
@HeikoSah ok this doesnt change anything20:58
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun20:58
shogun-notifier-shogun: lambday :develop * 1f0da69 / tests/unit/ (2 files): https://github.com/shogun-toolbox/shogun/commit/1f0da6923ce1af363070d881286124ca56195d8120:58
shogun-notifier-shogun: removed display from unit-test (log-det)20:58
shogun-notifier-shogun: Heiko Strathmann :develop * d918d1a / tests/unit/ (2 files): https://github.com/shogun-toolbox/shogun/commit/d918d1a1e21826160dc0a2e1e92a7c2b1242aafd20:58
shogun-notifier-shogun: Merge pull request #1515 from lambday/feature/log_determinant20:58
shogun-notifier-shogun:20:58
shogun-notifier-shogun: removed display from unit-test (log-det)20:58
-!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has quit [Read error: Connection reset by peer]20:58
-!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has joined #shogun20:59
@HeikoSlambday: ok thanks for that20:59
@HeikoSlambday: I will add my changes soon20:59
lambdayfor ozone, the method still doesn't converge20:59
@HeikoSlambday: are there any sub-parts we should check?21:00
lambdayHeikoS: hmm21:00
@HeikoSlambday: since the eigenvalues might be estimated negatively21:00
lambdayHeikoS: oh today is report day21:00
@HeikoSand other things might go wrong21:00
lambdayHeikoS: you mean some of the eigenvalues are negative?21:00
lambdayHeikoS: I just noticed that the Lanczos eigensolver didn't converge21:01
@HeikoSlambday: they are not negative, but arbitrarily close to zero21:01
lambdayfor ozone21:01
@HeikoSlambday: so one needs to run things for longer21:01
@HeikoSlambday: where is the best place to assert that they are positive?21:01
lambdayHeikoS: none! we assume that the matrix is psd when someone is tries to use CG based solvers21:02
lambday:(21:02
lambdayI can add that check thogh21:02
@HeikoSlambday:21:02
@HeikoS/home/heiko/Desktop/shogun/shogun/tests/unit/mathematics/logdet/RationalApproximation_unittest.cc:273: Failure21:02
@HeikoSThe difference between (map_xd-map_xs).norm() and 0.0 is 0.017611379876991774, which exceeds 0.01, where21:02
@HeikoS(map_xd-map_xs).norm() evaluates to 0.017611379876991774,21:02
@HeikoS0.0 evaluates to 0, and21:02
@HeikoS0.01 evaluates to 0.01.21:02
lambdayargh what is wrong with my english :(21:02
@HeikoSthis one is also still there21:02
shogun-buildbotbuild #1958 of deb1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/195821:02
@HeikoSor did I introduce it? ;)21:02
lambdayHeikoS: this is related to the cocg solver, right?21:03
@HeikoSlambday: dont know, I had no unit tests before I started changing things :D21:03
@HeikoSlambday: I know we assume psd, but if the smallest eigenvalue is too small, the computer runs into troubles21:03
lambdaythis is weird :(21:03
@HeikoSlambday: and the way to resolve this is to run the eigensolver for longer21:03
shogun-buildbotbuild #1959 of deb1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1959  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>21:03
@HeikoSlambday: until the values get positive21:03
@HeikoSlambday: if not, throw an error21:04
lambdayHeikoS: what will be too small for our case :(21:04
lambdaythe smallest is like 0.something and the largest is 1000000.something21:04
@HeikoSlambday: dont know, but even for toy matrices which have eigenvalues around 0.0001, the smallest estimated one is negative21:05
shogun-buildbotbuild #75 of osx1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/osx1%20-%20libshogun/builds/7521:05
lambdayHeikoS: you're adding that #shifts related things?21:05
lambdayHeikoS: more tests :(21:06
-!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has quit [Ping timeout: 241 seconds]21:06
-!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has joined #shogun21:07
shogun-buildbotbuild #1585 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1585  blamelist: lambday <heavensdevil6909@gmail.com>21:07
lambday:(21:08
lambdayHeikoS: just one thing I changed in the COCG today which is disastrous21:08
lambdaywhat is more weird is that, for fixed examples, we get different results... I should check this21:08
shogun-buildbotbuild #1047 of rpm1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/rpm1%20-%20libshogun/builds/1047  blamelist: lambday <heavensdevil6909@gmail.com>21:14
@HeikoSlambday: could you elaborate a bit more?21:16
lambdayHeikoS: regarding determining the number of shifts?21:17
@HeikoSlambday: no the cocg thing you mentioned21:18
lambdayHeikoS: changed the computation of beta parameter which earlier I made a mistake'21:22
@HeikoSok?21:22
lambdayHeikoS: it should be ||r_{i+1)||_{2}/||r_{i}||_{2|21:23
lambdayHeikoS: the same thing that I changed for CG and CG-M based solvers21:23
@HeikoSok21:24
lambdayHeikoS: you will be needing cocg to work for individual jobs too, right? :(21:24
@HeikoSlambday: so the broken unit test is a consequence of this patch21:24
@HeikoShttps://travis-ci.org/shogun-toolbox/shogun/builds/1089657321:24
@HeikoSlambday: the family based solver is fine for now21:25
lambdayHeikoS: yes :)21:25
@HeikoSindividual jobs are getting interesting once we precondition things to increase/decrease the eigenvalues21:25
lambdayHeikoS: will fix COCG soon21:25
lambdayHeikoS: checking the errors21:25
lambdaynice21:27
lambdayso, things to be added are -21:27
lambday1) checks for too small eigenvalues21:27
lambday2) automaticallt computing shifts in RationalApproximation (which you are adding, right?)21:27
lambday3) fixing COCG21:27
lambday4) ... :-/21:28
@HeikoSlambday: I just fixed 221:30
@HeikoSlambday: btw if I compute 100 log-det estimates, everything that can be precomputed is precomputed right?21:30
lambdayHeikoS: yes... coloring and shifts are computed only once21:31
@HeikoSlambday: good :)21:31
lambdayI need to check the COCG solver21:31
@HeikoSlambday: so then, we should start adding tests for challenging matrices, once cocg is working21:31
lambday:( one mistake fixed, another one pops out :(21:31
@HeikoSlambday: again, I am sure these problems are bugs, so dont worry too much, just systematically test things21:32
lambdayHeikoS: we can add these for CG-M as well, no?21:32
lambdaybut for ozone, its tough to get things into convergence21:32
lambday':-/21:33
lambdayHeikoS: hopefully these are bugs21:33
@HeikoSlambday: yeah, before ozone, try to fix more obvious problems21:33
@HeikoSfor ozone, there are loads of things that can go wrong21:34
lambdayHeikoS: more obvious problems as in? too small eigenvalues, right?21:34
@HeikoSlambday: yes21:34
@HeikoSthere is something wrong with the probing sampler21:34
lambdayHeikoS: I am confused regarding how small should we consider as "too small"21:34
lambday:(21:34
@HeikoSlambday: ok so again on the eigenvalues21:35
lambdayHeikoS: what's wrong?21:35
@HeikoSlambday: matrices might have EV that are veeeery close to 021:35
@HeikoSnow we estimate those with lanczos and accuracy 1-521:35
@HeikoSwe get a negative value21:35
@HeikoSand everything breaks (so we have to throw an error and stop)21:36
lambdayalright..21:36
@HeikoSbut with 1e-15, it might work so that the number we get is positive21:36
lambdayokay noted21:36
@HeikoSlambday: and for the probe sampler21:36
@HeikoSit seems to return the same sample all the time21:36
@HeikoSvariance of the log-det estimate is zero21:36
lambdaysame sample??21:36
lambdaybut the thing is probabilistic :-o21:37
@HeikoSlambday: thats why something is strange21:37
lambdaywait cehcking21:37
@HeikoSvariance zero=?21:37
@HeikoSor might that be my diagonal matrix causing it?21:37
lambdayHeikoS: might be21:37
lambdayHeikoS: could you please try with a different one?21:37
@HeikoSlambday: should not21:37
@HeikoSlambday: the matrix is21:37
shogun-buildbotbuild #1669 of deb3 - modular_interfaces is complete: Failure [failed test python_modular]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1669  blamelist: lambday <heavensdevil6909@gmail.com>21:38
lambdayHeikoS: it surely produces different sample vectors21:38
@HeikoSdata=abs(randn(n)**2)21:38
@HeikoSis the diagonal21:38
lambdayHeikoS: the variance is absolutely zero??21:38
lambday:-o21:38
@HeikoSlambday: let me show you a notebook21:38
lambdayalright21:39
@HeikoSlambday: http://nbviewer.ipython.org/641658321:39
@HeikoSah shit21:39
@HeikoSdidnt save,wait21:39
@HeikoSlambday: ok reload21:40
lambdayhorizontal! :|21:41
lambdayHeikoS: how this thing can be same every thing?? :'( https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/mathematics/logdet/ProbingSampler.cpp#L19421:43
@HeikoSlambday: but converges to the same value21:43
lambdayHeikoS: that should not happen?21:43
lambdaymay be the matrix is trivial21:44
lambday:-/21:44
@HeikoSlambday: it always return 0 samples in this case21:44
shogun-buildbotbuild #1367 of cyg1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/cyg1%20-%20libshogun/builds/1367  blamelist: lambday <heavensdevil6909@gmail.com>21:44
lambdayHeikoS: that's not possible if it enters the else block21:45
@HeikoSlambday: reload again21:45
lambdayso, please check num_samples21:45
@HeikoSlambday: there is more weird stuff21:45
lambdayless than 021:46
lambday!21:46
lambdayindex21:46
lambdayerrr21:46
@HeikoSdid I do anything wrong there?21:46
lambdayHeikoS: just one thing is causing all these21:46
lambdayI am trying to figure out21:47
lambdayHeikoS: why m_num_samples is 0??21:47
lambdaym_num_samples is the number of colors it uses to color the graph21:47
lambdayHeikoS: please check this https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/mathematics/logdet/ProbingSampler.cpp#L18721:48
@HeikoSlambday: yep, so forgotten set of this somewhere?21:48
@HeikoSlambday: maybe its my python code21:48
lambdayHeikoS: no no.. since its a diag matrix, it uses only one color21:49
lambdayearlier I made a mistake, did you rebase?21:49
@HeikoSlambday: btw this warning is not so useful, should be something that users understand :)21:49
@HeikoSlambday: let me try21:49
lambdayHeikoS: number of colors should be 121:49
@HeikoSno my develop is up to date21:49
lambdayummm21:50
lambdayHeikoS: could you please try to print the probing vector? :(21:50
lambdayHeikoS: this *has to* give it at least one https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/mathematics/logdet/ProbingSampler.cpp#L17621:51
@HeikoSlambday: ok21:51
lambday:'(21:51
lambdayHeikoS: you are right regarding this warning... but I thought this should never happen21:52
lambdayHeikoS: please make sure that ColPack works properly :(21:53
@HeikoSlambday: ehm21:53
@HeikoShow? :D21:53
@HeikoSI installed it21:53
lambdayHeikoS: wait I am giving you a small program21:53
lambdaythat should run21:53
lambdayHeikoS: https://gist.github.com/lambday/641670921:56
lambdayHeikoS: refresh21:57
lambdayjust pasted output from my machine21:57
lambdayHeikoS: I will get dc now argh :'( :'(21:58
lambdayHeikoS: please let me know if you discover any bug regarding this :(21:58
@HeikoSlambday: maybe its time for some break :)21:58
@HeikoSlambday: let me put up some changes to the python code21:58
@HeikoSI will update it then and merge my PR21:59
@HeikoSthen you can test it, too21:59
lambdayHeikoS: hehe yes21:59
lambdayalright21:59
lambdayHeikoS: when is your presentation?22:00
@HeikoSlambday: next week22:00
@HeikoSlambday: so we really need to hurry, but if it doesnt work, I wont be killed22:00
@HeikoSwould just be cool22:00
lambdayI hope all things work properly by then :-s22:00
@HeikoStomorrow I am meeting a cluster guy to allocate 2000 nodes for me :)22:00
pickle27HeikoS: did you see my new PR for the notebook?22:00
@HeikoSpickle27: not yet, should I have a look?22:00
pickle27HeikoS: yeah, it should be a quick merge, slash I don't think you'll be able to see the diff22:01
pickle27I added some text but mainly I cleared the graphics22:01
@HeikoSlambday: http://nbviewer.ipython.org/641658322:03
@HeikoScheck this out just ran everything from scratch22:03
lisitsynpickle27: let me22:04
lisitsyn;)22:04
shogun-notifier-shogun: Kevin :develop * 9e23773 / doc/ipython-notebooks/ica/bss_jade.ipynb: https://github.com/shogun-toolbox/shogun/commit/9e23773613b50b3bbc5a4e16cefa84700b22ee9f22:04
shogun-notifier-shogun: updated jade notebook and cleared all the graphics22:04
lisitsynokay I can't see diff22:04
shogun-notifier-shogun: Heiko Strathmann :develop * caf6ea2 / doc/ipython-notebooks/ica/bss_jade.ipynb: https://github.com/shogun-toolbox/shogun/commit/caf6ea2b4ccb3285a7536e8f0038791277f88f5c22:04
shogun-notifier-shogun: Merge pull request #1514 from pickle27/develop22:04
shogun-notifier-shogun:22:04
shogun-notifier-shogun: updated jade notebook and cleared all the graphics22:04
lisitsynahhh22:04
pickle27lisitsyn: ah didn't notice you were here22:04
lisitsynheiko did the blind merge instead of me22:04
lisitsyn:D22:04
-!- lambday [67157f36@gateway/web/freenode/ip.103.21.127.54] has quit [Ping timeout: 250 seconds]22:04
lisitsynpickle27: how is it going?22:04
pickle27lisitsyn: HeikoS well now that the graphics are done we should be able to see diffs on it if I make more changes22:05
pickle27lisitsyn: good!22:05
@HeikoSpickle27: yeah hopefully!22:05
pickle27lisitsyn: Im almost done ICA and the ECG example22:05
lisitsynpickle27: cool22:05
pickle27I've been playing with the ruby_modular interface a bunch this week22:05
lisitsynpickle27: and how it was?22:05
pickle27looking at updating to NMatrix / SciRuby from NArray22:05
pickle27lisitsyn: its been kind of fun hacking around22:07
pickle27nothing is working 100% yet though22:07
lisitsynpickle27: what problems have you met?22:08
pickle27lisitsyn: namely just fighting with the NMatrix api22:08
shogun-buildbotbuild #1961 of deb1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1961  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>22:08
pickle27lisitsyn: I have an "in" typemap that works, then I added some stuff to nmatrix for my out but I get a segfault 25% of the time22:09
lisitsynpickle27: uh22:09
lisitsynI see22:09
pickle27now I am trying a new approach22:09
lisitsynanything I can help you with?22:09
pickle27lisitsyn: ummm I think I am good for the moment, but I will let you know!22:10
lisitsynalright22:10
lisitsynpickle27: where the segfault occurs? nmatrix?22:11
shogun-notifier-shogun: Heiko Strathmann :develop * 2495ea3 / src/shogun/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/2495ea3e15bbe2c7753b8c756accdb6573fb0de522:11
shogun-notifier-shogun: added method to compute number of shifts from accuracy and also added22:11
shogun-notifier-shogun: a constructor to set this accuracy. Some minor refactoring otherwise22:11
shogun-notifier-shogun: Heiko Strathmann :develop * 4d11dc6 / tests/unit/mathematics/logdet/RationalApproximation_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/4d11dc6b19ce20890201390d1eeee08dd419dda722:11
shogun-notifier-shogun: make unit test use newly added method to compute the number of shifts22:11
shogun-notifier-shogun: Heiko Strathmann :develop * cd23cb8 / src/shogun/mathematics/logdet/ (5 files): https://github.com/shogun-toolbox/shogun/commit/cd23cb822ae06e82aac8e6466fa8502f80e6e76c22:11
shogun-notifier-shogun: Added accuracy based constructors to implementations of rational approximation base class22:11
shogun-notifier-shogun: Heiko Strathmann :develop * 6cf0a9a / src/shogun/mathematics/logdet/RationalApproximation.cpp: https://github.com/shogun-toolbox/shogun/commit/6cf0a9aa8d74b8064abeb3160813d805f4299ff222:11
shogun-notifier-shogun: provide information in case of negative accuracy22:11
lisitsynpickle27: I mean I have seen quite a lot shogun segfaults :D22:11
shogun-notifier-shogun: Heiko Strathmann :develop * e324259 / tests/unit/mathematics/logdet/RationalApproximation_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/e324259cf25957903b4763701eb264d441df226122:11
shogun-notifier-shogun: using existing method to compute accuracy22:11
shogun-notifier-shogun: Heiko Strathmann :develop * eb533ce / src/shogun/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/eb533ce0e88cde59d4892c8305fb0a7fb8660df022:11
shogun-notifier-shogun: added my name to copyright22:11
shogun-notifier-shogun: Heiko Strathmann :develop * 5745b0b / / (7 files): https://github.com/shogun-toolbox/shogun/commit/5745b0b5887c306ceb0bac63c8eead9d9989603522:11
shogun-notifier-shogun: remove constructor with num shifts and offer a method to set that instead22:11
shogun-notifier-shogun: Heiko Strathmann :develop * 4b56820 / tests/unit/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/4b568200d1c05c6c09b533d81fce2357b3a4b6f522:11
shogun-notifier-shogun: replace constructor call with num_shifts with dummy value for accuracy and set num shifts by hand22:11
shogun-notifier-shogun: Heiko Strathmann :develop * 00ad5d9 / tests/unit/mathematics/logdet/RationalApproximation_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/00ad5d96d46a6c836fa08606603b4eb1e0f3138322:11
lisitsynheiko-tron22:11
@HeikoStravis should go green with this, hopefully22:11
lisitsynHeikoS: you basically heikonized the channel22:12
@HeikoSlisitsyn: haha :)22:12
@HeikoSok going home now22:12
@HeikoSsee you guys22:12
lisitsynciao!22:12
votjakovrHeikoS: see you ;)22:12
@HeikoSlisitsyn: votjakovr: see you!22:13
lisitsynpickle27: I wanted to ask you about one thing with the saliency filter22:13
pickle27lisitsyn: yeah?22:13
lisitsynwell I can simplify it22:13
lisitsynhow to make it work haha22:13
-!- HeikoS [~heiko@nat-169-160.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.]22:14
pickle27lisitsyn: my code or the idea in general?22:14
lisitsynpickle27: both - I tried your code but I don't get how does it work22:14
pickle27lisitsyn: okay let me pull it up22:14
lisitsynpickle27: the problem is that I get quite low quality fg masks22:15
pickle27lisitsyn: looking at my implementation I basically did this22:16
pickle27I found all the "blobs" of connected foreground pixels in the low threshold mask22:16
lisitsynpickle27: I admit I don't get what should I expect22:16
lisitsynpickle27: how would you handle disconnected parts?22:17
shogun-buildbotbuild #1960 of deb1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/196022:17
pickle27then I check each pixel in each blob and mark if it is also foreground in the high threshold mask I inc a counter22:18
pickle27a blob has to have a certain ratio or else it get filtered22:18
pickle27so you want to set your low threshold lower22:18
pickle27than you otherwise might22:18
shogun-buildbotbuild #1963 of deb1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1963  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>22:19
shogun-buildbotbuild #1964 of deb1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/196422:21
lisitsynpickle27: can you take a look at fg/bg masks I get? may be I miss something22:22
pickle27sure22:22
lisitsynpickle27: argh do you have any snippet to join a few images into one?22:23
pickle27like as a video?22:23
lisitsynvideo1 | video2 | video322:23
pickle27hmm nothing that would be quick I don't think22:24
pickle27I often would just writing something in opencv and python22:24
pickle27but never really save it22:24
lisitsynI see22:24
lisitsynokay in a minute22:25
shogun-buildbotbuild #1586 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1586  blamelist: Kevin <kevinhughes27@gmail.com>22:25
lisitsynpickle27: sent22:27
lisitsynpickle27: do you find it reasonable?22:28
pickle27yeah Im trying to play in slow motion22:28
lisitsynI mean I can definitely detect something going on22:28
lisitsynbut it is even hard to find proper ROI22:29
lisitsynpickle27: that's adaptive median22:29
shogun-buildbotbuild #1048 of rpm1 - libshogun is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/rpm1%20-%20libshogun/builds/104822:29
pickle27lisitsyn: and thats the lowest thresh you can go before it starts classifying too much?22:29
lisitsynpickle27: I haven't really tuned it22:30
pickle27lisitsyn: also I find it easier to look at the masks than the contours output22:30
pickle27try droping the thresh22:30
lisitsynpickle27: okay let me send you mask22:30
lisitsynpickle27: what would you say about adaptive median?22:31
shogun-buildbotbuild #76 of osx1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/osx1%20-%20libshogun/builds/76  blamelist: Kevin <kevinhughes27@gmail.com>22:31
pickle27lisitsyn: for a threshold? hmm22:31
lisitsynpickle27: no I mean the method22:31
lisitsynpickle27: is it ok at all?22:31
pickle27lisitsyn: I think it should be okay for indoors22:31
shogun-buildbotbuild #1587 of bsd1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/bsd1%20-%20libshogun/builds/1587  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>22:32
pickle27lisitsyn: I really think you are going to need something more than BGS though22:34
lisitsynpickle27: yes indeed22:34
pickle27like use BGS to get a guess then do some kind of detection22:34
lisitsynpickle27: just want to make it more reliable before I go next steps22:35
pickle27yeah probably a good call22:35
lisitsynhttps://dl.dropboxusercontent.com/u/10139213/share/processed.avi22:35
lisitsynpickle27: ^22:35
pickle27lisitsyn: is the backgound always going to be the same? do you have data of just the background?22:37
lisitsynpickle27: the main thing that bothers me is lightning changes on the floor22:37
lisitsynpickle27: yes it is mostly the same22:37
lisitsynjust speckles and some jittering22:37
pickle27lisitsyn: you could look into training BG model beforehand22:37
lisitsynpickle27: please elaborate ;)22:38
pickle27lisitsyn: this video won't play in browser, can you just link the folder22:38
lisitsynoh sorry22:38
lisitsynokay let me email it22:38
pickle27lisitsyn: you run a method like adaptive median or any of the others on all the data you have of the BG and save the model22:38
pickle27then don22:38
pickle27't bother with learning or update while detecting22:39
lisitsynpickle27: what would be the best method that pre-learns?22:39
pickle27lisitsyn: you can pre-learn any method22:39
pickle27lisitsyn: but Eigenbackground can only pre learn and is pretty good22:39
pickle27lisitsyn: also did my whole thesis on it lol22:40
lisitsynpickle27: eigenbackground is basically pca of the image right?22:40
shogun-buildbotbuild #77 of osx1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/osx1%20-%20libshogun/builds/77  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>22:40
pickle27lisitsyn: yeah22:40
lisitsynpickle27: have you ever seen any applications of a method that learns using some custom features (not just pixels)?22:41
pickle27lisitsyn: some people have done some stuff with local binary patterns22:42
pickle27I don't think this would work well for you though because there isn't a lot of texture22:42
lisitsynyeah lbp is good for real textures22:42
lisitsynwell it works for faces though22:42
pickle27at some point it transitions from being called BGS to being called segmentation, and I haven't done much work there22:43
pickle27it works good for BGS too in some cases22:43
lisitsynpickle27: real segmentation is not going to be real-time :(22:43
pickle27lisitsyn: yeah22:44
lisitsynpickle27: I wish I just graph cut it or whatever :D22:44
pickle27lisitsyn: well you could try and do obj detection using SIFT features22:44
pickle27sift is fast enough22:44
pickle27and it might work22:44
lisitsynpickle27: yes that's going to work I believe22:44
lisitsynSIFT SURF whatever22:44
lisitsynpickle27: well probably the workflow would be BGS to detect changes22:45
lisitsynthen start tracking keypoints22:45
pickle27lisitsyn: you might even be able to skip the bgs and just use SIFT to detect if the car is there or not22:45
lisitsynpickle27: haha true22:45
lisitsynthis would mean I spend a week for nothing22:46
lisitsyn:D22:46
pickle27lisitsyn: BGS is so frustrating because you can get so close to what you need but never quite enough22:46
lisitsynpickle27: oh I think I know why you find it frustrating22:46
lisitsynyou did a thesis on that22:46
pickle27haha yup22:47
lisitsynthat's the best practice to start feeling X boring and frustrating22:47
pickle27lisitsyn: but in other news, my ruby out typemap works now22:47
lisitsynyup22:47
lisitsynnice22:47
lisitsynpickle27: have you used FREAK btw?22:48
lisitsynI tried it once22:48
lisitsyninteresting thing actually22:48
shogun-buildbotbuild #1368 of cyg1 - libshogun is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/cyg1%20-%20libshogun/builds/1368  blamelist: Kevin <kevinhughes27@gmail.com>22:48
pickle27lisitsyn: yeah isn't that made by University of Ottawa?22:48
lisitsynhmm it seems not22:49
lisitsynhttp://www.ivpe.com/pub.php22:49
lisitsynthat's the author22:49
pickle27lisitsyn: hmm oh they were MoFREAK22:49
pickle27U of O made them 3D22:49
lisitsynpickle27: it was DAISY then it called FREAK22:49
lisitsynHOGs are dense SIFTS :D22:49
lisitsynSURFs are SIFTs but not patented22:50
pickle27lisitsyn: heres a question, is there a way to make a function that returns a type?22:50
lisitsynuhh22:50
lisitsynby type you mean what?22:50
lisitsynclass?22:50
pickle27lisitsyn: here is my problem22:50
lisitsynC++ have no first-class citizenship for classes you know ;022:50
lisitsyn;)22:50
pickle27NMatrix has a method for getting the data type in the API but it returns an int22:50
pickle27I need to turn that int into a type22:51
pickle27currently I am using a switch and it bothers me22:51
lisitsynjust switch it22:51
lisitsynyeah what else can you do22:51
pickle27lisitsyn: I dunno I was hoping to finding something cleaner22:51
pickle27or even some way to encapulate22:51
lisitsynpickle27: that's compile-runtime tradeoff :)22:52
lisitsynpickle27: I guess you need SGMatrix<whatever>22:52
lisitsynbut you can't put anything outside of <> inside <>22:52
lisitsynpickle27: I guess that's why cv::Mat is not templated :)22:53
pickle27isn't cv::Mat templated?22:53
pickle27I thought it was22:53
pickle27oh nvm22:53
lisitsynpickle27: ;)22:54
lisitsynpickle27: I haven't looked inside it though22:54
pickle27you can construct without a template arg22:54
lisitsyninside it is I believe22:54
pickle27yeah they do some weirdness under there22:54
pickle27because they use templates in the lib for sure but the user doesn't have to use them22:54
lisitsynpickle27: I find this solution not that bad22:55
pickle27lisitsyn: anyways here is the inner loop of my typemap, any ideas to make it cleaner or is this as good as it gets?22:55
pickle27http://pastebin.com/T3npGt5s22:55
-!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has joined #shogun22:56
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/1090574222:56
-!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has left #shogun []22:56
pickle27lisitsyn: I think I am going to at least move the switch into a function22:56
lisitsynpickle27: oh please don't move it22:56
lisitsynpickle27: you would interrupt some optimization here this way I think22:56
lisitsynsee what I mean?22:56
pickle27lisitsyn: no? but I have the same code for Vector and Matrix22:57
lisitsynpickle27: not a great deal22:57
pickle27lisitsyn: not sure I totally understand but I think I can sort of see your point22:57
lisitsynpickle27: but w/o function it can move switch out of loops22:57
lisitsynby it I mean compiler22:57
pickle27ahh interesting okay22:57
pickle27I shall leave it then22:58
lisitsynpickle27: I don't know any better way to do that though22:58
pickle27lisitsyn: fair enough22:58
lisitsynpickle27: it is just the place where compile stuff meets runtime stuff22:59
shogun-buildbotbuild #1962 of deb1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1962  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>23:06
shogun-buildbotbuild #1369 of cyg1 - libshogun is complete: Failure [failed compile]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/cyg1%20-%20libshogun/builds/1369  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>23:12
shogun-buildbotbuild #1671 of deb3 - modular_interfaces is complete: Failure [failed install test python_modular]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1671  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>23:13
shogun-buildbotbuild #1670 of deb3 - modular_interfaces is complete: Success [build successful]  Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/167023:24
lisitsynpickle27: alright keypoint based approach probably looks better :D23:45
lisitsynpickle27: thanks a lot for you suggestions23:45
-!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has quit [Quit: Leaving.]23:46
-!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun23:53
-!- mode/#shogun [+o iglesiasg] by ChanServ23:53
--- Log closed Tue Sep 03 00:00:42 2013