| --- 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 #shogun | 02:45 | |
| -!- sonne|osx_ [~sonne@f053040230.adsl.alicedsl.de] has joined #shogun | 03:38 | |
| -!- sonne|osx [~sonne@g225080229.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds] | 03:40 | |
| -!- sonne|osx_ is now known as sonne|osx | 03:40 | |
| -!- gsomix [~gsomix@85.26.232.136] has joined #shogun | 06:56 | |
| gsomix | sonney2k, sonne|osx hey. I will be available today at evening. | 06:57 |
|---|---|---|
| gsomix | I finally finished all works at home. | 06:59 |
| gsomix | gtg | 06: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 #shogun | 08:09 | |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 08:19 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * c00c71a / examples/undocumented/python_modular/ (167 files): https://github.com/shogun-toolbox/shogun/commit/c00c71a6cf13ed166dc52bb6395d4ec828741894 | 08:19 |
| shogun-notifier- | shogun: drop shogun.* structure and import from modshogun instead | 08: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 #shogun | 09: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/10882296 | 09:00 |
| -!- travis-ci [~travis-ci@ec2-54-211-15-52.compute-1.amazonaws.com] has left #shogun [] | 09:00 | |
| shogun-buildbot | build #1951 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1951 | 09:08 |
| shogun-buildbot | build #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-buildbot | build #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-buildbot | build #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 #shogun | 09:53 | |
| shogun-buildbot | build #1042 of rpm1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/rpm1%20-%20libshogun/builds/1042 | 09:59 |
| -!- van51 [~van51@ppp-94-66-92-175.home.otenet.gr] has joined #shogun | 10: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 #shogun | 11:22 | |
| -!- iglesiasg [~iglesias@n157-p43.kthopen.kth.se] has joined #shogun | 11:29 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 11:30 | |
| @iglesiasg | sonney2k, ping | 11:36 |
| -!- van51 [~van51@ppp-94-66-92-175.home.otenet.gr] has quit [Quit: Leaving.] | 11:37 | |
| @iglesiasg | someone around here who has used / is using the octave modular interface? | 11:37 |
| -!- van51 [~van51@94.66.92.175] has joined #shogun | 11:37 | |
| -!- thoralf [~thoralf@enki.zib.de] has joined #shogun | 12:11 | |
| thoralf | Hey. | 12:12 |
| @iglesiasg | Hello | 12:12 |
| -!- HeikoS [~heiko@nat-169-160.internal.eduroam.ucl.ac.uk] has joined #shogun | 12:13 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 12:13 | |
| thoralf | iglesiasg: You're the guy who did the SO-learning in shogun, right? Then you probably know something about the bundle method implementation? | 12:13 |
| thoralf | HeikoShi | 12:13 |
| @HeikoS | thoralf: hi! | 12:14 |
| @iglesiasg | thoralf, at the phone | 12:18 |
| lisitsyn | thoralf: I know a bit | 12:22 |
| @iglesiasg | thoralf, here I am | 12:25 |
| @HeikoS | lambday: hi! | 12:25 |
| @iglesiasg | thoralf, I have a very high level understanding of the method. Very little idea bout Michal's implementation | 12:26 |
| @iglesiasg | only that it is hardcore C code | 12:26 |
| thoralf | lisitsyn: 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 |
| @iglesiasg | I think there were even gotos :O | 12:26 |
| @iglesiasg | thoralf, Michal mentioned that the other methods were much faster | 12:27 |
| thoralf | lisitsyn: I have very high dimensional data (2^32) and it takes loooong time to converge, lots of memory (no wonder ;)) | 12:27 |
| @HeikoS | thoralf: it would be cool if you could make these things work and maybe even probide some examples and unit-tests ;) | 12:27 |
| thoralf | HeikoS: I'm not surprised that you're mentioning unit-tests. :) | 12:28 |
| @HeikoS | thoralf: haha :) | 12:28 |
| @HeikoS | thoralf: well, without them, this is what you get: memory issues and loads of problems | 12:28 |
| @HeikoS | especially if the original author is gone | 12:28 |
| thoralf | HeikoS is the unit-test man. While wiking is the RTFM man. :D | 12:28 |
| @HeikoS | and noone has an idea how things work | 12:28 |
| @HeikoS | thoralf: just trying to make our code sustainable ;) | 12:29 |
| @HeikoS | haha, yeah very true ,th | 12:29 |
| @HeikoS | , thoralf | 12:29 |
| lisitsyn | thoralf: so what's the question? ;) | 12:29 |
| thoralf | lisitsyn: Just some experience about the other methods. Accuracy, time, memory, convergence... ;) | 12:30 |
| thoralf | lisitsyn: But iglesiasg already answered that. :) | 12:30 |
| thoralf | lisitsyn: Of course, only empirically. | 12:30 |
| lisitsyn | thoralf: ah I see | 12:31 |
| thoralf | lisitsyn: Btw. did you check that the implementation is correct? Or can tell pathological cases to test that? | 12:32 |
| @iglesiasg | thoralf, but I suggest you to have a look at their paper | 12:32 |
| lisitsyn | thoralf: well it works as multiclass svm | 12:32 |
| @iglesiasg | thoralf, Vojtech and Michal have a paper about these methods IIRC | 12:32 |
| @iglesiasg | thoralf, I tested it in multiclass SVM and HM-SVM and worked well. Michal tested that in his GSoC too | 12:33 |
| @iglesiasg | but I found some problems later on with my grid graph model | 12:33 |
| thoralf | iglesiasg: 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 |
| thoralf | iglesiasg: But I'll have a look at their paper. | 12:33 |
| @iglesiasg | Tsochantaridis doesn't talk about bundle methods, does it? | 12:34 |
| thoralf | iglesiasg: He doesn't. | 12:34 |
| @iglesiasg | about Teo, I am not sure if it is just BMRM or the other ones as well | 12:34 |
| thoralf | iglesiasg: But he has been cited in DualLibQPBMSOSVM.h | 12:34 |
| @iglesiasg | I see | 12:34 |
| @iglesiasg | thoralf, 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 too | 12:36 |
| thoralf | iglesiasg: Yeah, but I should read the paper first. | 12:37 |
| thoralf | You helped a lot so far. | 12:37 |
| @iglesiasg | Bundle Methods for Structured Output Learning--Back to the Roots | 12:39 |
| @iglesiasg | thoralf, I think that one contains what in Shogun is called PPBMRM and P3BMRM | 12:40 |
| thoralf | iglesiasg: Btw. I've been pimping the SO-model/-machine implementation to parallelize across 32 cores. :) | 12:40 |
| @iglesiasg | thoralf, cool! | 12:40 |
| @iglesiasg | are you using some framework for parallelizing it? | 12:40 |
| thoralf | iglesiasg: No, yes. I tried both pthreads and openmp. | 12:41 |
| thoralf | iglesiasg: But the resulting code looks more beautiful with openmp. | 12:41 |
| @iglesiasg | nice | 12:41 |
| @HeikoS | thoralf: go for openmp, we will soon have some mechanism for this in shogun | 12:41 |
| @HeikoS | and openmp is less work ;) | 12:41 |
| thoralf | HeikoS: I know. :) | 12:41 |
| thoralf | (both) | 12:41 |
| @HeikoS | thoralf: currently playing with PBS backend for independent jobs | 12:42 |
| @HeikoS | works pretty nice | 12:42 |
| thoralf | PBS? | 12:42 |
| @HeikoS | and this gives a unified interface for any parallel thing | 12:42 |
| @HeikoS | thoralf: batch cluster system | 12:42 |
| @HeikoS | thoralf: where one can submit jobs to | 12:42 |
| thoralf | HeikoS: Cool. Which system? | 12:42 |
| thoralf | HeikoS: SUN? | 12:42 |
| @HeikoS | thoralf: the qsub based one, we call it PBS here | 12:43 |
| @HeikoS | but the sun interface is same I think | 12:43 |
| thoralf | HeikoS: qsub/sqsub... should be the same. | 12:44 |
| @HeikoS | thoralf: yep | 12:44 |
| @HeikoS | all the batch systems are similar, there is also this SLURM | 12:44 |
| @HeikoS | and its nice to (ab)use them for parallelization within algorithms | 12:45 |
| @HeikoS | doesnt make always sense, but sometimes its very useful | 12:45 |
| @HeikoS | thoralf: we also want to hapen openmp style parallelization | 12:46 |
| thoralf | HeikoS: Cross validation/parameter tuning makes sense. | 12:46 |
| @HeikoS | thoralf: yep exactly, this will be one bigger example | 12:46 |
| thoralf | HeikoS: I already have a experiment running using openmp/pthreads to parallelize locally. | 12:47 |
| @HeikoS | thoralf: cool, maybe we can share experience | 12:47 |
| @HeikoS | thoralf: I want to tackle this later in the year or early next one | 12:47 |
| @HeikoS | thoralf: maybe with lambday if he has time | 12:47 |
| thoralf | HeikoS: I already did some fixed with this cross-validation-pthread-issue if you remember. | 12:48 |
| thoralf | HeikoS: So shogun is ready for this. | 12:48 |
| @HeikoS | thoralf: nice! | 12:48 |
| @HeikoS | thoralf: if we had thread safe subsets then we can also parallelize x-bvalidation | 12:48 |
| thoralf | HeikoS: (If you don't remember: It's the issue where I refused to do unit tests. ;)) | 12:49 |
| @HeikoS | thoralf: currently, svm and x-validation doesnt work from mutliple threads | 12:49 |
| @HeikoS | thoralf: I remember :D | 12:49 |
| @iglesiasg | HeikoS, I remember now what I wanted to ask you the other day! haha | 12:50 |
| thoralf | HeikoS: 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 |
| @HeikoS | thoralf: I know this is why I am asking people all the time | 12:50 |
| @HeikoS | iglesiasg: ha! ok :) | 12:50 |
| @iglesiasg | HeikoS, about the ipython notebook. I have these i.pynb_checkpoints directory, no problem removing it I guess? | 12:50 |
| @HeikoS | iglesiasg: I think not | 12:51 |
| thoralf | HeikoS: I have many other local changes to prepare for sparse computations. (In my cases speeding up to factor 20) | 12:51 |
| @HeikoS | its all for storing the kernel | 12:51 |
| @HeikoS | thoralf: nice! | 12:51 |
| @HeikoS | very cool! | 12:51 |
| thoralf | HeikoS: It's no rocket sience - just lot of work and testing. ;) | 12:51 |
| thoralf | Gotta work, see you later and thanks for helping. | 12:52 |
| @HeikoS | ok, thanks also, bye! | 12:52 |
| -!- van51 [~van51@94.66.92.175] has quit [Quit: Leaving.] | 12:54 | |
| lambday | HeikoS: hey | 12:56 |
| @HeikoS | lambday: hi! | 12:56 |
| @HeikoS | lambday: how are things? | 12:56 |
| lambday | HeikoS: sorry I didn't notice | 12:56 |
| lambday | HeikoS: CG-M is bad :( | 12:56 |
| lambday | I am currently running each and every thing step by step | 12:56 |
| lambday | CG-M related | 12:56 |
| @HeikoS | lambday: what is bad? | 12:56 |
| lambday | something is really off | 12:56 |
| @HeikoS | what exactly happens? | 12:56 |
| @HeikoS | lambday: and what works? | 12:57 |
| lambday | the 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 diag | 12:57 |
| @HeikoS | ok? | 12:57 |
| lambday | HeikoS: ideally these two should be converging towards the same point | 12:58 |
| lambday | but CG-M moves somewhere else | 12:58 |
| lambday | trying to figure out what causes this.. and if there is a mistake in my implementation than that of paper | 12:58 |
| @HeikoS | lambday: CIterativeShiftedLinearFamilySolver right? | 12:58 |
| lambday | HeikoS: then I will try this approach - in the paper (the mail I sent you) they plotted the residual | 12:58 |
| lambday | HeikoS: that's where it computes the shifted stuffs | 12:59 |
| lambday | zeta/beta/alpha_sh things | 12:59 |
| lambday | HeikoS: well, one idea is thsi | 12:59 |
| @HeikoS | lambday: with these kind of problems, you should try to test all parts, starting from the very smallest | 12:59 |
| lambday | the plot of residual in the paper - it seems to have a weird zigzag nature | 13:00 |
| lambday | HeikoS: yes that's what I am trying to do | 13:00 |
| @iglesiasg | KTH completely closed one day due to Obama coming! | 13:00 |
| @HeikoS | lambday: then thats good, there are probably also some bugs in the code, there always are | 13:00 |
| @iglesiasg | no office for me on Wednesday :( | 13:00 |
| @HeikoS | lambday: so this will be good anyway | 13:00 |
| @HeikoS | iglesiasg: haha ;) | 13:00 |
| lisitsyn | iglesiasg: instead of russia ;) | 13:00 |
| @HeikoS | lambday: keep in mind, usually errors are caused by simple thing | 13:01 |
| @HeikoS | s | 13:01 |
| @HeikoS | so dont get too involved in alternatives, testing is the best way to understand whats the problem | 13:01 |
| lambday | HeikoS: I need to make it work :( .. I will plot the residual and then will see... | 13:01 |
| lambday | yes | 13:01 |
| @HeikoS | so if you can find the exact point where things fail, this will be useful | 13:01 |
| @HeikoS | lambday: dont get stressed out, I am sure you will find the problem soon | 13:02 |
| lambday | HeikoS: yes.. but its impossible to know prior to the iterations whether something will converge or not for shifted family solver | 13:02 |
| lambday | that' | 13:02 |
| @HeikoS | lambday: try to focus on simpler things first, not too many other methods and plots | 13:02 |
| lambday | s what the paper says | 13:02 |
| lambday | alright | 13:02 |
| @HeikoS | lambday: you have to explain that ^ | 13:02 |
| lambday | HeikoS: we cannot know whether a shifted family with cg-m solver will converge or not | 13:03 |
| thoralf | lambday: You're sure that the solution/the first step is canonical? | 13:03 |
| lambday | there is another convergence test (after running the algorithm) | 13:03 |
| lambday | HeikoS: I didn't get... first step?? | 13:04 |
| @HeikoS | lambday: how do you terminate currently? | 13:04 |
| lambday | HeikoS: based on the tolerence on residual | 13:04 |
| lambday | which is 1E-5 | 13:04 |
| @HeikoS | lambday: 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 accuracy | 13:04 |
| lambday | by default | 13:04 |
| lambday | umm.. yes... | 13:05 |
| @HeikoS | lambday: its just important to be aware of that | 13:05 |
| @HeikoS | lambday: but I believe there is a bug or something | 13:05 |
| @HeikoS | lambday: the matrices you were using were all easy | 13:05 |
| lambday | currently I have that "did not converge"... | 13:05 |
| @HeikoS | and the ones I tested were too | 13:05 |
| @HeikoS | lambday: what if you increase accuracy or number of its qiute a bit, what happens? | 13:06 |
| lambday | HeikoS: yeah that's what I think... just like the probing sampler thing, it took me quite a long time where the mistake was coming from | 13:06 |
| @HeikoS | lambday: yeah | 13:06 |
| @HeikoS | lambday: so just keep on testing different things, this we you also know what you can rely on | 13:06 |
| @HeikoS | lambday: but make sure you use some non-trivial problems in the tests at some point to simulate difficulty | 13:07 |
| lambday | what I have noticed, sometimes it doesn't converge at all... I tried with tolerence 0.01 even still doesn | 13:07 |
| lambday | 't work | 13:07 |
| hushell | wiking: hey, how do we set up Mosek in CMake? | 13:07 |
| lambday | HeikoS: yes.. but first things have to work for small things at least.. | 13:07 |
| @HeikoS | lambday: yep true | 13:07 |
| @HeikoS | lambday: ok, keep on pushing it :) I will today finish the cluster stuff | 13:08 |
| lambday | HeikoS: did you notice anything regarding CG-M convergence in your implementation | 13:08 |
| @HeikoS | lambday: I solved individually since I was in a rush | 13:08 |
| @HeikoS | lambday: but you can of course ask daniel/erlend | 13:08 |
| @HeikoS | though again, I would search for bugs first and try to understand why things break | 13:09 |
| @HeikoS | when does it diverge etc? | 13:09 |
| lambday | yes that's what I was going to say | 13:09 |
| lambday | :) | 13:09 |
| @HeikoS | does it depend on the smallest eigenvalues? | 13:09 |
| @HeikoS | or on something else | 13:09 |
| @HeikoS | usually those bastards cause trouble ;) | 13:09 |
| lambday | nah.. not eigenvalues :( | 13:09 |
| lambday | :D | 13:09 |
| lambday | the ozone matrix has really horrible cond number | 13:10 |
| lambday | :-o | 13:10 |
| @HeikoS | lambday: yes | 13:10 |
| @HeikoS | in fact its almost inf | 13:10 |
| @HeikoS | I added a ridge on the diagonal ;) | 13:10 |
| @HeikoS | be back soon | 13:10 |
| lambday | okie | 13:10 |
| lambday | I too am getting back to work :) | 13:10 |
| lambday | ciao :) | 13:10 |
| -!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 13:25 | |
| @iglesiasg | is there a reason why we are changing in python to import everything from modshogun instead of shogun.*? | 13:48 |
| lisitsyn | iglesiasg: I can say yes | 13:48 |
| lisitsyn | but can't say why | 13:48 |
| lisitsyn | I don't remember | 13:48 |
| @iglesiasg | haha ok | 13:48 |
| @iglesiasg | so should I expect that any time soon shogun.* imports won't be supported any more? | 13:48 |
| lisitsyn | anything shogun.Whatever is just an alias to modshogun | 13:49 |
| lisitsyn | you can from shogun.Features import SVM | 13:49 |
| @iglesiasg | hahaha | 13:49 |
| @iglesiasg | ok | 13:49 |
| @iglesiasg | that is a good reason to stop doing that then | 13:49 |
| lisitsyn | that's just backcompatibility | 13:49 |
| @iglesiasg | it just adds a layer of confusion IMHO | 13:49 |
| lisitsyn | yes the seventh layer of hell | 13:50 |
| lisitsyn | or whatever level :) | 13:50 |
| @iglesiasg | hehe yeah | 13:51 |
| @iglesiasg | I am changing my local examples to modshogun then | 13:53 |
| -!- sonne|work [~sonnenbu@91-64-72-127-dynip.superkabel.de] has joined #shogun | 13:57 | |
| @iglesiasg | sonne|work, hello hello | 14:04 |
| @iglesiasg | got a question about octave modular | 14:04 |
| @iglesiasg | sonne|work, if I open an octave session and do modshogun and then exit | 14:04 |
| @iglesiasg | it segfaults ?rettu badly | 14:05 |
| @iglesiasg | oh shit, ?rettu, was supposed to be pretty (bad hand position) | 14:05 |
| @iglesiasg | is that expected behaviour? | 14:05 |
| sonne|work | iglesiasg: no | 14:07 |
| @iglesiasg | then we've got a problem | 14:07 |
| @iglesiasg | thoralf, very nice unit tests in that PR ;) | 14:09 |
| @HeikoS | iglesiasg: no need to do that I always do from shogun.Bla import Bla | 14:09 |
| @HeikoS | votjakovr: hi! | 14:10 |
| @iglesiasg | HeikoS, in Octave? | 14:10 |
| @HeikoS | iglesiasg: o that I dont know, just read the first bits of your dialog with sergey | 14:10 |
| @iglesiasg | I didn't know that from .. import works in Octave as well | 14:10 |
| @HeikoS | votjakovr: could you give me a quick status update on what parts you are currently working? | 14:10 |
| @iglesiasg | HeikoS, 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 works | 14:11 |
| @HeikoS | iglesiasg: why? because its not really doing that but just faking it? | 14:12 |
| @iglesiasg | HeikoS, well what's the point on having to remember all shogun.Features, shogun.Classifier, etc if they just import from modshogun? | 14:13 |
| @iglesiasg | I rather just remember modshogun | 14:13 |
| @HeikoS | iglesiasg: yeah agreed | 14:13 |
| @iglesiasg | and even better do stuff like | 14:13 |
| @iglesiasg | import modshogun | 14:13 |
| @iglesiasg | modshogun.RealFeatures() ... | 14:13 |
| @iglesiasg | although I have not tried if that works yet | 14:13 |
| @iglesiasg | I guess it does | 14:13 |
| votjakovr | HeikoS: hi! I'm currently working on gradient model selection, i've found some problems and thinking on it. | 14:20 |
| @HeikoS | votjakovr: what problems? which part exactly, being curious here ;) | 14:21 |
| votjakovr | HeikoS: problem #1: As you said, we need to perform gradient descent on some subset of the all possible parameters | 14:23 |
| @HeikoS | votjakovr: 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 |
| votjakovr | HeikoS: for doing this we need to pass current parameter combination to GradientMachineEvaluation class | 14:25 |
| @HeikoS | votjakovr: yes, thats the way to go | 14:25 |
| votjakovr | HeikoS: and then pass it to inference classes to find the derivatives | 14:25 |
| @HeikoS | votjakovr: that seems very sensible | 14:26 |
| @HeikoS | votjakovr: should be hidden to the outside world though, getting derivatives via parameter combinations | 14:27 |
| @HeikoS | votjakovr: since its a bit weird, a parameter combination is a fixed set of parameters with values | 14:27 |
| @HeikoS | votjakovr: and here you rather want a set of parameters as strings | 14:27 |
| votjakovr | HeikoS: hmm.. don't understand a little bit, what you mean | 14:29 |
| @HeikoS | votjakovr: a parameter combination should not be passed to the GP objects | 14:30 |
| @HeikoS | votjakovr: parameter combinations are there to apply a fixed set of parameters to a machine | 14:30 |
| @HeikoS | votjakovr: 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 so | 14:30 |
| @HeikoS | votjakovr: but pls dont pass the parameter combination around | 14:31 |
| @HeikoS | votjakovr: see what I mean? | 14:31 |
| sonne|work | iglesiasg: the reason for all that is that we really had different modules under shogun - really shogun.Features etc | 14:32 |
| @iglesiasg | sonne|work, aham, then it made sense before | 14:32 |
| sonne|work | iglesiasg: however these created issues like the one you just said - octave crashed when two modules got loaded | 14:33 |
| sonne|work | serialization was a problem | 14:33 |
| sonne|work | it was a problem to keep objects accross modules | 14:33 |
| votjakovr | HeikoS: yeah, but now we have, that derivatives are computed wrt all of the possible parameters (kernel, likelihood, etc) of the machine | 14:33 |
| @iglesiasg | sonne|work, any idea what can be wrong with this octave issue? | 14:33 |
| sonne|work | iglesiasg: so that is why we removed this | 14:33 |
| @iglesiasg | sonne|work, it works fine when I do octave some_example.m | 14:34 |
| @iglesiasg | no segfault then | 14:34 |
| @HeikoS | votjakovr: I agree this is not good, one should provide a set of strings to select | 14:34 |
| sonne|work | iglesiasg: well we don't have withe the stuff on the buildbot right? | 14:34 |
| @HeikoS | votjakovr: do you think that would work? | 14:34 |
| sonne|work | iglesiasg: well give us a valgrind / gdb backtrace | 14:34 |
| @HeikoS | votjakovr: and then model selection applies the current parameter combinatzion first, then asks for derivatives via this set of strings? | 14:34 |
| @iglesiasg | sonne|work, all right. I will open an issue in a few minutes | 14:34 |
| votjakovr | HeikoS: we could use current param_dict but as a parameter, not build it there | 14:35 |
| @HeikoS | votjakovr: and this string set is created from parameter tree that user gave | 14:35 |
| votjakovr | HeikoS: yeah, that what i mean | 14:35 |
| @HeikoS | votjakovr: param dict should be ok | 14:36 |
| @HeikoS | votjakovr: ah no | 14:36 |
| @HeikoS | votjakovr: please dont pass those around | 14:37 |
| @HeikoS | contains too much | 14:37 |
| @HeikoS | pointers to data etc | 14:37 |
| @HeikoS | rather the gradients should be selected by name, this is sufficient information and everything else just makes things complicated | 14:37 |
| @HeikoS | names can be extracted easily internally | 14:37 |
| @HeikoS | get_derivatives(set of strings) | 14:37 |
| votjakovr | HeikoS: Map<char*, SGObject*>? | 14:38 |
| @HeikoS | votjakovr: why an sg object when you call a method on the object? | 14:38 |
| @HeikoS | gp->get_derivatives(strings ) should do it shouldnt it? | 14:38 |
| votjakovr | HeikoS: what if you have kernel and likelihood with the same parameter name? | 14:39 |
| @HeikoS | votjakovr: good point, what is currently done with that? | 14:39 |
| @HeikoS | are the TParameter instances matched? | 14:39 |
| @HeikoS | actually, you might be right, the param_dict might be the best way to do it | 14:40 |
| @HeikoS | match the unique TParameter instance rather than just name | 14:40 |
| @HeikoS | although its still a bit dirty, but ok, should do it | 14:40 |
| votjakovr | HeikoS: now it isn't done | 14:41 |
| @iglesiasg | uhm something wrong with features_string_file_char_modular.py and features_string_file_modular.py_ | 14:42 |
| @HeikoS | votjakovr: yeah I remember, that why we started the discussion ;) | 14:42 |
| @iglesiasg | https://travis-ci.org/shogun-toolbox/shogun/jobs/10890168 | 14:42 |
| @iglesiasg | I will restart the job just in case it was something random, maybe worth to look at in any case | 14:42 |
| votjakovr | HeikoS: 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 |
| @HeikoS | votjakovr: what exactly dont you like? | 14:46 |
| votjakovr | HeikoS: i'm just asking:) when should i use m_parameters instead of m_model_selection_parameters? | 14:47 |
| @HeikoS | votjakovr: about m_parameters, you have to ask sonne|work, sonney2k, I added the model-selection parameters a few years ago during gsoc | 14:47 |
| @HeikoS | votjakovr: ah I see | 14:47 |
| @HeikoS | votjakovr: so shogun classes have parameters | 14:47 |
| @HeikoS | for serialization/clone/equals | 14:47 |
| @HeikoS | everything is registered | 14:47 |
| @HeikoS | votjakovr: and then the model-selection parameters are a subset of those, for which model-selection is possible | 14:48 |
| @HeikoS | votjakovr: but these things are pointing to the very same memory | 14:48 |
| @HeikoS | votjakovr: so all model-selection parameters are also in m_parameters | 14:48 |
| votjakovr | HeikoS: yep, i see, thanks :) So is model selection working only with m_model_selection_parameters? | 14:50 |
| @HeikoS | votjakovr, yes | 14:51 |
| @HeikoS | votjakovr: everything else should be blocked ;) | 14:51 |
| votjakovr | HeikoS: 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 gradients | 14:51 |
| @HeikoS | votjakovr: yep, thats weird, feel free to improve this | 14:52 |
| votjakovr | HeikoS: ok :) problem #2: don't get random values from the parameter tree | 14:53 |
| @HeikoS | votjakovr: you want to remove that? | 14:54 |
| @HeikoS | votjakovr: I totally agree, rather, use the currently set parameters to start. This way users can define starting values the same way as in GPML | 14:55 |
| votjakovr | HeikoS: i think we should use current machine parameters instead of picking random form the tree | 14:55 |
| @HeikoS | votjakovr: I am with you there | 14:55 |
| @HeikoS | votjakovr: random search model selection should stay though, as its kind of nice to get initial good values | 14:55 |
| @HeikoS | votjakovr: another nice things would be not having to previously specify the range of the parameters to search for | 14:57 |
| @HeikoS | votjakovr: so the parameter tree would just consist of names and sgobjects, but no values | 14:57 |
| votjakovr | HeikoS: yeah! i'd like to ask you about that, but you've done this first :) | 14:58 |
| @HeikoS | votjakovr: good! ok I got another point, things should be unit-tested and made work for regression. | 14:59 |
| @HeikoS | votjakovr: once this is done, classification should be easy to add right? | 14:59 |
| votjakovr | HeikoS: yeah | 14:59 |
| @HeikoS | votjakovr: ok then, on which things of the discussed are you currently working? | 15:00 |
| @HeikoS | votjakovr: how long do you think this will take? | 15:00 |
| votjakovr | HeikoS: 1-2 day without testing | 15:00 |
| votjakovr | HeikoS: 3 days | 15:00 |
| votjakovr | HeikoS: with testing | 15:00 |
| votjakovr | :) | 15:00 |
| votjakovr | HeikoS: i'd like to ask: can we now use the tree without specifying particular range of values for parameters? | 15:02 |
| @HeikoS | votjakovr: I am not sure about that. But if not, this should be easy to change | 15:02 |
| @HeikoS | votjakovr: there is a field in the tree elements which contains the data | 15:02 |
| @HeikoS | votjakovr: and it can be NULL or so | 15:02 |
| @HeikoS | checking | 15:02 |
| @HeikoS | votjakovr: | 15:03 |
| @HeikoS | void* m_values; | 15:03 |
| votjakovr | HeikoS: ok, great :) | 15:03 |
| @HeikoS | votjakovr: the way I suggest to do this is to create trees with just names and no data | 15:03 |
| @HeikoS | and if assertions are in the way (I might have put them there), remove them :) | 15:04 |
| votjakovr | HeikoS: yeah | 15:04 |
| @HeikoS | votjakovr: 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 |
| votjakovr | HeikoS: ok, no problem :) | 15:05 |
| votjakovr | HeikoS: btw when thing will be done for regression we can use it for classification too without any changes, i think | 15:06 |
| votjakovr | HeikoS: we'll minimize negative marginal likelihood in both cases | 15:09 |
| votjakovr | HeikoS: btw, have a look at: http://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/machine/gp/InferenceMethod.cpp#L53 | 15:13 |
| thoralf | iglesiasg: Thanks for your comment. Didn't realize that point - but you're right. | 15:13 |
| votjakovr | HeikoS: why is model selection not available for mean there? | 15:14 |
| @iglesiasg | thoralf, it is fun to check the runtime of algorithms :) | 15:21 |
| thoralf | iglesiasg: Normally this is my part - I must have been distracted. ;) | 15:25 |
| @iglesiasg | hehe | 15:25 |
| @iglesiasg | thoralf, let me know if you think the change I suggest makes sense | 15:26 |
| thoralf | iglesiasg: 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 |
| thoralf | iglesiasg: BUT: Having a is_sorted() check at the beginning does something like you said. ;) | 15:31 |
| @iglesiasg | thoralf, the swap count wouldn't be zero for the initial array | 15:32 |
| @iglesiasg | thoralf, 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 part | 15:32 |
| @iglesiasg | let me double-check in any case | 15:33 |
| thoralf | iglesiasg: 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 |
| @iglesiasg | thoralf, mmm no | 15:33 |
| @iglesiasg | thoralf, I mean | 15:33 |
| thoralf | [1;0;4;3] <-- Try this | 15:33 |
| thoralf | split:=2 | 15:34 |
| thoralf | No swap takes place. | 15:34 |
| @iglesiasg | split is the value of the element I think | 15:34 |
| thoralf | count would be zero | 15:34 |
| @iglesiasg | then split = 4 | 15:34 |
| thoralf | T split=output[size/2] <--4 | 15:34 |
| @iglesiasg | yep | 15:35 |
| thoralf | Okay, you're right. Need another example. | 15:35 |
| @iglesiasg | :) | 15:35 |
| thoralf | [1;0;3;4] <-- Try this | 15:35 |
| thoralf | pivot:=list[4/2]=3 | 15:36 |
| thoralf | iglesiasg: 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 |
| thoralf | I clever person is overruled by many dump persons. Like Galileo. :D | 15:37 |
| thoralf | s/I/A/ | 15:38 |
| @iglesiasg | thoralf, does it break in your example? | 15:38 |
| @iglesiasg | I think there is actually a swapin there | 15:38 |
| thoralf | iglesiasg: Shall I write an example program? ;) | 15:38 |
| @iglesiasg | thoralf, well now we are talking about your example first :) | 15:39 |
| @HeikoS | thoralf, iglesiasg so you are taking care of the PR? :) I was just about to merge | 15:39 |
| @iglesiasg | HeikoS, merge merge | 15:39 |
| @HeikoS | since it doesnt really hurt | 15:40 |
| @HeikoS | but doing | 15:40 |
| @iglesiasg | just discussing | 15:40 |
| @HeikoS | if (!sorted) | 15:40 |
| @HeikoS | sort | 15:40 |
| @HeikoS | is not so nice | 15:40 |
| @HeikoS | that was my point | 15:40 |
| @HeikoS | anyway | 15:40 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 15:40 | |
| shogun-notifier- | shogun: Thoralf Klein :develop * 8a2fe8a / / (3 files): https://github.com/shogun-toolbox/shogun/commit/8a2fe8a57c7c9acf82d14fee655cf71823a7933f | 15:40 |
| shogun-notifier- | shogun: Added method "is_sorted()" to SGVector | 15: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/dbe34baedc02fad0f67674b2a133f07c70c5b866 | 15:40 |
| shogun-notifier- | shogun: Merge pull request #1507 from tklein23/sgvector_is_sorted | 15:40 |
| shogun-notifier- | shogun: | 15:40 |
| shogun-notifier- | shogun: Added method "is_sorted()" to SGVector | 15:40 |
| lisitsyn | oh guys you keep overloading sgvector with stuff ;) | 15:41 |
| @iglesiasg | that is a good point | 15:42 |
| @iglesiasg | thoralf, but I think you must be right due to the best-case complexity argument | 15:43 |
| votjakovr | HeikoS: should model selection be available for mean function? http://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/machine/gp/InferenceMethod.cpp#L60 | 15:43 |
| @iglesiasg | thoralf, but I am not 100% :P | 15:44 |
| @HeikoS | votjakovr: no, since the only way to do this is via grid-search | 15:44 |
| @iglesiasg | 100% sure | 15:44 |
| @HeikoS | votjakovr: I would just register the ML2 things, i.e. real parameters | 15:44 |
| votjakovr | HeikoS: Great! Thanks :) | 15:45 |
| thoralf | iglesiasg: Again, you're right. But different than you might think: | 15:45 |
| thoralf | iglesiasg: it swaps output[2] against output[2] | 15:45 |
| @iglesiasg | yeah | 15:45 |
| @iglesiasg | I noticed that | 15:45 |
| @iglesiasg | hehe | 15:45 |
| thoralf | iglesiasg: But I think this is a bug. ;) | 15:45 |
| votjakovr | HeikoS: no sgobjects like kernel, likelihood function? | 15:45 |
| @HeikoS | votjakovr: ah sorry, I think you need to register them since they have sub-parameters | 15:46 |
| @HeikoS | votjakovr: so the mean function also should be registered | 15:46 |
| @HeikoS | votjakovr: but since it has no sub-parameters for ZeroMean, no need to register anything in there | 15:46 |
| thoralf | HeikoS: Thanks for merging. | 15:47 |
| @iglesiasg | thoralf, yes, it might be that the if should only be executed for left<right | 15:47 |
| votjakovr | HeikoS: but we may use not only ZeroMean | 15:47 |
| @iglesiasg | thoralf, not <= | 15:47 |
| @HeikoS | votjakovr: yeah so register it | 15:47 |
| votjakovr | HeikoS: ok :) | 15:47 |
| @HeikoS | votjakovr: if we have a mean with a sub-parameter its useful | 15:48 |
| @iglesiasg | thoralf, anyhow I am cool with the is_sorted method and the current qsort | 15:48 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 15:48 | |
| thoralf | iglesiasg: There are two left<=right :) | 15:48 |
| @HeikoS | votjakovr: 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 defauilt | 15:48 |
| @HeikoS | votjakovr: since this is the usual case people want, and no need for parameter trees there | 15:49 |
| @iglesiasg | thoralf, the if, I said | 15:49 |
| besser82 | Just want to say hello and tell you I am going to package shogun for Fedora && RHEL ;) | 15:49 |
| votjakovr | HeikoS: yeah, that would be nice | 15:49 |
| @iglesiasg | besser82, cool, thanks! | 15:49 |
| @HeikoS | votjakovr: but its easy to add once other things work | 15:50 |
| besser82 | igleasiasg, ^^ | 15:50 |
| @HeikoS | besser82: thats great! maybe we could add a buildbot for that? | 15:50 |
| @HeikoS | or even add it to our nightly generated packages? | 15:50 |
| @HeikoS | besser82: you should talk to sonney2k and/or wiking about that once you have made some progress, that would be very useful for us | 15:50 |
| besser82 | HeikoS, sure you can do, but I'm going to bring this into official repos ;) | 15:50 |
| lambday | HeikoS: FIXED IT :D :D :D | 15:51 |
| @HeikoS | besser82: sweet! :) | 15:51 |
| @HeikoS | lambday: whoooo! | 15:51 |
| lambday | more more more tests | 15:51 |
| @HeikoS | what was it? | 15:51 |
| @HeikoS | :D | 15:51 |
| lambday | ARGH!! | 15:51 |
| lambday | lot of them | 15:51 |
| @HeikoS | wrong {} ? _D | 15:51 |
| lambday | I am the biggest idiot on the face of the earth :D | 15:51 |
| lambday | no no | 15:51 |
| lambday | many mistakes combination | 15:51 |
| lambday | phew! | 15:51 |
| lambday | wait wait! | 15:51 |
| lambday | :D | 15:51 |
| @HeikoS | hehe :) so send the PR. and make sure all those bugs are added to tests ;) | 15:52 |
| @iglesiasg | besser82, 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 |
| lambday | HeikoS: I added way too many debug msgs | 15:52 |
| lambday | ah crunched each and every number | 15:52 |
| besser82 | HeikoS, 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 |
| @HeikoS | besser82: sure! | 15:52 |
| lambday | HeikoS: brb :D | 15:53 |
| @HeikoS | lambday: ok! looking forward to the PR :) | 15:53 |
| besser82 | iglesiasg, 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 |
| lambday | HeikoS: will send real soon | 15:53 |
| @iglesiasg | besser82, got it, thanks! | 15:54 |
| shogun-buildbot | build #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 |
| thoralf | HeikoS: if (!sorted) sort <-- Won't help out, because it's called recursively and will check sorting over-and-over on every iteration. :D | 16:05 |
| @iglesiasg | sonne|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 so | 16:06 |
| @iglesiasg | or maybe we can put the picture with all of us that Cheng sent to the mailing list | 16:06 |
| @HeikoS | iglesiasg: can you access the buildbot site? | 16:08 |
| votjakovr | HeikoS: 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 |
| @iglesiasg | HeikoS, http://buildbot.shogun-toolbox.org/? Access meaning change stuff of it? | 16:08 |
| @HeikoS | iglesiasg: didnt we have fedora in there a while ago? | 16:09 |
| @iglesiasg | HeikoS, there is this rmp1 libshogun | 16:10 |
| @iglesiasg | rpm1 sorry | 16:10 |
| @HeikoS | what os is that? | 16:10 |
| @HeikoS | redhat | 16:10 |
| @iglesiasg | aham, besser82 mentioned about rpms in Fedora Repo, that's why I thought | 16:11 |
| shogun-notifier- | shogun: Roman Votyakov :develop * b871fbb / src/shogun/machine/gp/ (11 files): https://github.com/shogun-toolbox/shogun/commit/b871fbb81e36b7d660f81325dc9f2cf490e62393 | 16:18 |
| shogun-notifier- | shogun: minor fixes in GP framework | 16:18 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 88efc31 / src/shogun/machine/gp/ (11 files): https://github.com/shogun-toolbox/shogun/commit/88efc31c40e5d25d28c6a43a1782f473d47c9eac | 16:18 |
| shogun-notifier- | shogun: Merge pull request #1511 from votjakovr/feature/gp_refactoring | 16:18 |
| shogun-notifier- | shogun: | 16:18 |
| shogun-notifier- | shogun: Minor fixes in GP framework | 16:18 |
| @HeikoS | votjakovr: ^ | 16:18 |
| votjakovr | HeikoS: thanks :) | 16:19 |
| votjakovr | HeikoS: btw i think we need a review for kernel's classes, probably write missing unit-tests, etc. But after GSoC | 16:21 |
| @HeikoS | votjakovr: absolutely! put it on your list :) | 16:22 |
| besser82 | sonne|work: are you free for a minute? Or shall I ping you later? | 16:33 |
| shogun-buildbot | build #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 |
| lambday | HeikoS: sending the PR | 16:36 |
| lambday | HeikoS: added a new test for log-det also, using CG-M | 16:37 |
| lambday | :D | 16:37 |
| lambday | gives equal accuracy as direct solver | 16:37 |
| lambday | HeikoS: will add ozone data examples now in this week | 16:37 |
| sonne|work | besser82: just quick please - gtg in 5 mins | 16:38 |
| shogun-buildbot | build #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 |
| besser82 | sonne|work: i want to know more about the elwms-interface... | 16:39 |
| sonne|work | iglesiasg: yes no pictures no talk uploads... | 16:40 |
| sonne|work | iglesiasg: we suck publicity wise | 16:40 |
| @iglesiasg | we shall continue being annoying with wiking for the talk uploads | 16:41 |
| @iglesiasg | I guess he will probably do them soon | 16:41 |
| lambday | HeikoS: please have a look at the PR.. I'll come back later.. starving :) | 16:41 |
| @iglesiasg | sonne|work, but you do have the pictures, right? Just mail them to me if so | 16:41 |
| shogun-buildbot | build #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-buildbot | build #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/675b19d9e98134be132e598eaad9c3787a13e0fc | 16: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/b2b8af95e9b811bf0a659a1f6ad3a8e48a3ddd7e | 16:47 |
| shogun-notifier- | shogun: Merge pull request #1512 from lambday/feature/log_determinant | 16: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 #shogun | 16: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/10894214 | 16:50 |
| -!- travis-ci [~travis-ci@ec2-174-129-83-121.compute-1.amazonaws.com] has left #shogun [] | 16:50 | |
| @HeikoS | thoralf: MulticlassOCASTest.train fails | 16:52 |
| @HeikoS | is that your fault? | 16:52 |
| @HeikoS | I merged before travis was green :( | 16:52 |
| thoralf | HeikoS: I ran the tests locally and they were all green. | 16:52 |
| @HeikoS | thoralf: ok dont know what that is than | 16:53 |
| @HeikoS | then | 16:53 |
| thoralf | HeikoS: I'll double check in a second. | 16:53 |
| @HeikoS | thoralf: thanks! | 16:54 |
| votjakovr | HeikoS: have a look at the issue: http://github.com/shogun-toolbox/shogun/issues/1411 | 16:54 |
| @HeikoS | votjakovr thanks! | 16:54 |
| @HeikoS | thoralf: ^ | 16:54 |
| thoralf | HeikoS: Ah, okay. | 16:55 |
| shogun-buildbot | build #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 #shogun | 16:58 | |
| sonne|osx | besser82: I have another 15 mins :) | 16:59 |
| besser82 | sonne|osx: What is the elwms-interface about? Is it worth to pacakage this for fedora/rhel? | 16:59 |
| sonne|osx | besser82: 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 |
| besser82 | sonne|osx: kk, will do ;) thx! and how about to run the integration tests in recent git-checkout? | 17:01 |
| sonne|osx | besser82: so rather leave out all static interfaces like elwms_* and python_* | 17:01 |
| besser82 | sonne|osx: I think you meant *_static??? | 17:02 |
| sonne|osx | besser82: unit or integration tests? | 17:02 |
| sonne|osx | besser82: yes | 17:02 |
| besser82 | sonne|osx: preferably both of them ;) | 17:02 |
| @iglesiasg | sonne|osx, BTW, there is not current way to build static, right? I realized yesterday that the configure script is gone. | 17:02 |
| sonne|osx | besser82: our current build system runs unit tests already upon build | 17:02 |
| sonne|osx | besser82: well there is now | 17:03 |
| besser82 | sonne|osx: will need them in %check-target of spec. Other Fedora maintainer will complain on review otherwise ;) | 17:03 |
| sonne|osx | besser82: agh ok then run ctest manually | 17:03 |
| sonne|osx | besser82: you can look up how to separate the steps by reproducing what we do on the buildbot | 17:04 |
| besser82 | sonne|osx: kk, any source where to find the whole cli-switches needed? | 17:04 |
| sonne|osx | besser82: look here http://buildbot.shogun-toolbox.org/waterfall | 17:04 |
| sonne|osx | and then deb3 - modular interfaces | 17:04 |
| besser82 | sonne|osx: thx! Will do. | 17:04 |
| sonne|osx | the stdio in the very beginning lists you exactly what we call cmake with | 17:04 |
| besser82 | sonne|osx: thx, ctest I'll find there as well, I guess? | 17:05 |
| sonne|osx | besser82: yes that is part of cmake | 17:05 |
| * besser82 takes a look inside sonne|osx's provided link ;) | 17:06 | |
| sonne|osx | besser82: btw once you have sth - we could run it during our nightly builds... | 17:06 |
| besser82 | sonne|osx: sth? | 17:06 |
| sonne|osx | besser82: might be easier this way to not break stuff. when I do deb's I intend to do the same | 17:06 |
| sonne|osx | besser82: something | 17:06 |
| besser82 | sonne|osx: kk, long line today ;P | 17:07 |
| besser82 | sonne|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|osx | besser82: btw your work is highly anticipated by some ... | 17:08 |
| sonne|osx | we got a couple of complaints lets say :) | 17:08 |
| besser82 | sonne|osx: why? what? ??? | 17:08 |
| besser82 | what did I do wrong ??? | 17:09 |
| sonne|osx | well users that don't like compiling shogun from source :) | 17:09 |
| sonne|osx | besser82: nothing | 17:09 |
| sonne|osx | they want .rpm's | 17:09 |
| besser82 | :D | 17:10 |
| besser82 | sonne|osx: nice joke ;) | 17:10 |
| sonne|osx | besser82: go please them :) | 17:11 |
| besser82 | sonne|osx: I'll do ! | 17:11 |
| besser82 | sonne|osx: think I can push-out whole thing for review during this week... | 17:12 |
| besser82 | If someone want's to join-in: I can bring new contributors to Fedora ;) | 17:13 |
| * besser82 is Packager-Sponsor for Fedora ;) | 17:13 | |
| besser82 | and knows half folks from Fedora's sci-tech SIG | 17:14 |
| sonne|osx | besser82: I am a debian developer... but nice try :) | 17:14 |
| shogun-buildbot | build #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|osx | besser82: but seriously I can have a look at the spec | 17:15 |
| besser82 | sonne|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|osx | besser82: 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 time | 17:17 |
| shogun-buildbot | build #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|osx | now I am mostly overwhelmed and doing shogun only at least ATM | 17:17 |
| besser82 | sonne|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/6723325cd5bdb82ce23209054899d26230661aca | 17:18 |
| shogun-notifier- | shogun: replace shogun.* modules with modshogun | 17:18 |
| shogun-buildbot | build #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 |
| besser82 | sonne|osx: thanks for the nice talk, I'll get back back to get my shogun.spec ready and in shape ;) | 17:20 |
| sonne|osx | besser82: thanks and I gtg anyway now | 17:20 |
| besser82 | sonne|osx: Which will be the upcoming version in Oct? | 17:20 |
| sonne|osx | besser82: thanks for your work and keep us updated | 17:20 |
| besser82 | sonne|osx: 2.2.0? | 17:20 |
| sonne|osx | 3.0.0 | 17:20 |
| * sonne|osx off | 17:20 | |
| -!- sonne|osx [~sonne@89.204.139.210] has quit [Quit: sonne|osx] | 17:20 | |
| besser82 | So I guess I'll package 3.0.0 pre-release-snap from git ;) | 17:21 |
| @HeikoS | votjakovr: are you there? | 17:21 |
| shogun-buildbot | build #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-buildbot | build #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-buildbot | build #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 | |
| votjakovr | HeikoS: yeap | 17:35 |
| @HeikoS | votjakovr: nevermind, had a build error with gp stuff, but that was my faiult | 17:36 |
| @HeikoS | cmake still tricks my sometimes | 17:36 |
| votjakovr | HeikoS: ok | 17:38 |
| -!- foulwall [~zhengyang@114.255.40.7] has quit [Ping timeout: 246 seconds] | 17:45 | |
| -!- foulwall [~zhengyang@114.255.40.7] has joined #shogun | 17:45 | |
| -!- sonne|osx [~sonne@f053040230.adsl.alicedsl.de] has joined #shogun | 17:51 | |
| shogun-buildbot | build #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 |
| votjakovr | HeikoS: 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 #shogun | 17:55 | |
| -!- travis-ci [~travis-ci@ec2-174-129-83-121.compute-1.amazonaws.com] has joined #shogun | 17: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/10895761 | 17:58 |
| -!- travis-ci [~travis-ci@ec2-174-129-83-121.compute-1.amazonaws.com] has left #shogun [] | 17:58 | |
| @HeikoS | votjakovr: thats a good point | 18:00 |
| @HeikoS | votjakovr: so historically, CGaussian was developed for Gaussian density estimation, ie EM | 18:00 |
| @HeikoS | votjakovr: so the interface is developed for that | 18:00 |
| @HeikoS | but the CGaussianDistribution is more a classical distribution interface: log_pdf and sampling | 18:01 |
| @HeikoS | votjakovr: I could not really merge them since the scope is too different. | 18:01 |
| @HeikoS | votjakovr: also CGaussianDistribution has no features attached | 18:01 |
| @HeikoS | CGaussian can probably be a subclass of CGaussianDistribution btw | 18:01 |
| shogun-buildbot | build #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 |
| @HeikoS | but we have to base classes which are in conflict there | 18:02 |
| -!- HeikoS [~heiko@nat-169-160.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 18:02 | |
| shogun-buildbot | build #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 #shogun | 18:04 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 18:04 | |
| votjakovr | HeikoS: yep, now i see, thank you :) | 18:07 |
| @HeikoS | votjakovr: I di dnot really like the CGaussian also thats why I did a new one :) | 18:07 |
| @iglesiasg | sonne|work, can I get sicpy in the fatbot please? :) | 18:10 |
| @iglesiasg | sudo apt-get install python-scipy | 18:10 |
| @iglesiasg | sonne|osx, sonney2k ^ | 18:11 |
| votjakovr | pickle27: 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 evaluation | 18:14 |
| @iglesiasg | votjakovr, maybe in Math better? | 18:17 |
| @iglesiasg | I also support the idea that we shouldn't make out SGVector and SGMatrix classes fatter | 18:17 |
| @iglesiasg | out->our | 18:17 |
| -!- van51 [~van51@ppp-94-66-92-175.home.otenet.gr] has joined #shogun | 18:18 | |
| votjakovr | iglesiasg: 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 else | 18:20 |
| @iglesiasg | votjakovr, it makes sense. But then at least have the main implementation in Math and just a wrapper in SGMatrix | 18:21 |
| votjakovr | iglesiasg: probably, but i still don't understand, why implementation of these 2 functions in SGMatrix.cpp is bad | 18:24 |
| -!- iglesiasg [~iglesias@n157-p43.kthopen.kth.se] has quit [Ping timeout: 245 seconds] | 18:25 | |
| votjakovr | iglesiasg: pickle27: but i'm pretty sure, that this stuff should be moved from evaluation/ica | 18:26 |
| -!- iglesiasg [~iglesias@2001:6b0:1:1041:b8ef:b3e:75c0:30ef] has joined #shogun | 18:37 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 18:37 | |
| @sonney2k | iglesiasg, installed | 18:49 |
| @iglesiasg | sonney2k, thanks! | 18:49 |
| @iglesiasg | embarrassed of asking this but | 18:53 |
| @iglesiasg | how do I install Shogun so I can use the Python modular interface in a computer where I cannot sudo? | 18:53 |
| @iglesiasg | maybe defining the install dir in cmake? | 18:54 |
| @iglesiasg | although IIRC thoralf did something like install-local when we had the configure script | 18:54 |
| -!- lambday [67157f36@gateway/web/freenode/ip.103.21.127.54] has joined #shogun | 19:05 | |
| lambday | HeikoS: hi | 19:05 |
| @HeikoS | lambday: hi! | 19:05 |
| lambday | HeikoS: I will add some more examples | 19:05 |
| @HeikoS | I am currently editing rational approx to automagically compute the number of shifts if wanted | 19:05 |
| @HeikoS | lambday: btw the thing works better now | 19:05 |
| @HeikoS | very slow though | 19:05 |
| lambday | HeikoS: yeah :D | 19:05 |
| @HeikoS | but the shifts will speed it up at least | 19:06 |
| @HeikoS | then I will try it with the ozone | 19:06 |
| lambday | HeikoS: number of shifts I will add to the class itself | 19:06 |
| @sonney2k | iglesiasg, well look at the output of cmake | 19:06 |
| @HeikoS | lambday: what? | 19:06 |
| @sonney2k | it says at the end | 19:06 |
| lambday | HeikoS: I should test this with ozone | 19:06 |
| @HeikoS | what do you mean? | 19:06 |
| lambday | HeikoS: number of shifts should be computed within LogDetEstimator itself given the accuracy the user wants | 19:06 |
| lambday | right? | 19:06 |
| lambday | that's a simple computation | 19:06 |
| @HeikoS | lambday: yeah but in the rational approx class | 19:07 |
| @iglesiasg | sonney2k, thank you, my bad | 19:07 |
| @HeikoS | I will add it to precompute | 19:07 |
| @HeikoS | once the eigenvalues are know, this can be done | 19:07 |
| lambday | HeikoS: where we explicitly have to mention the number of shifts, right | 19:07 |
| lambday | yes I will change that | 19:07 |
| @HeikoS | lambday: no let me do it | 19:07 |
| lambday | but things work better now | 19:07 |
| @HeikoS | I already started ;) | 19:07 |
| lambday | HeikoS: awesome | 19:07 |
| lambday | :D | 19:07 |
| lambday | HeikoS: I should also check this against the ozone matrix | 19:08 |
| lambday | wait I am checking | 19:08 |
| -!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has joined #shogun | 19: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/10896818 | 19: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 |
| lambday | what's the error? :)( | 19:08 |
| lambday | :( | 19:08 |
| @HeikoS | ? | 19:09 |
| pickle27 | iglesiasg: votjakovr yes I agree with re factoring those functions | 19:09 |
| pickle27 | iglesiasg: votjakovr I don't have a preference where though, whatever you think is best | 19:09 |
| lambday | HeikoS: checking the travis msgs | 19:09 |
| pickle27 | also make sure you update all the ajd unit tests after you move it | 19:09 |
| @HeikoS | ah ok | 19:09 |
| @sonney2k | HeikoS, pickle27 - can anyone reproduce https://github.com/shogun-toolbox/shogun/issues/1509 ? | 19:10 |
| lambday | HeikoS: argh I put display matrix and etc in RationalApproximation unit test | 19:10 |
| lambday | changing | 19:11 |
| @HeikoS | lambday: oops I did not see that | 19:11 |
| lambday | HeikoS: just saw | 19:11 |
| @HeikoS | lambday: 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 ridge | 19:13 |
| pickle27 | sonney2k: just tried on my system and no I can't reproduce | 19:14 |
| @HeikoS | lambday: btw never do this: | 19:14 |
| @HeikoS | CMath::log(max_eig/min_eig) | 19:14 |
| @HeikoS | if max_eig/min_eig is a very large number you get an overflow and the log fails | 19:14 |
| @HeikoS | log(a/b)=log(a)-log(b) | 19:14 |
| @HeikoS | I will chang ein the unit test | 19:15 |
| lambday | HeikoS: okay | 19:16 |
| lambday | :-/ | 19:16 |
| lambday | umm... I did that inside RationalApproximation, right? | 19:16 |
| @HeikoS | lambday: no, in the unit test | 19:16 |
| @HeikoS | lambday: I copy pasted it :) | 19:16 |
| @HeikoS | but just realised this might cause problems | 19:16 |
| lambday | HeikoS: yeah you are right | 19:16 |
| @HeikoS | log of product should always be done in log-domain | 19:16 |
| @HeikoS | its a neat trick, helps very often | 19:16 |
| lambday | HeikoS: but I also used similar things while computing shifts/weights... | 19:17 |
| @HeikoS | lambday: if the numbers are small thats fine | 19:17 |
| lambday | HeikoS: yeah I should be changing those | 19:17 |
| @HeikoS | but maybe check later | 19:17 |
| @HeikoS | but a condition number of a matrix might be huge | 19:17 |
| lambday | HeikoS: I thought float64_t has a really higher range so it should not create problems | 19:17 |
| lambday | HeikoS: yup | 19:17 |
| lambday | true | 19:17 |
| lambday | I need to add this over next week | 19:17 |
| @sonney2k | pickle27, iglesiasg so which swig and octave versions? | 19:19 |
| @iglesiasg | sonney2k, SWIG Version 2.0.4, GNU Octave, version 3.6.2 | 19:20 |
| shogun-buildbot | build #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 |
| @HeikoS | lambday: | 19:27 |
| @HeikoS | I have this weird eigen error again | 19:27 |
| @HeikoS | lambday: see pm | 19:28 |
| @HeikoS | its only if I do the unit tests | 19:28 |
| @HeikoS | so disabling and relying on travis for now | 19:29 |
| lambday | HeikoS: I didn't get :-/4 | 19:30 |
| lambday | HeikoS: wait let me see | 19:30 |
| @HeikoS | its the probing sampler who does it | 19:32 |
| @HeikoS | thats why travis doesnt detect it, no probing sampler in there since no colpaclk | 19:32 |
| lambday | HeikoS: I don't get any such errors :( I have colpack | 19:34 |
| @HeikoS | lambday: whats your eigen version? | 19:35 |
| @HeikoS | its an eigen interface problem, they added or removed an assertion | 19:35 |
| @HeikoS | do 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 #shogun | 19: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/10898142 | 19:35 |
| -!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has left #shogun [] | 19:35 | |
| lambday | HeikoS: shogun cmake detects my own version | 19:36 |
| @HeikoS | lambday: no its eigen | 19:37 |
| @HeikoS | lambday: did you update all unit tests after the last pr? | 19:37 |
| @HeikoS | unit tests break | 19: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, and | 19:37 |
| @HeikoS | lambday: I guess you saw that ;) | 19:37 |
| lambday | HeikoS: yeah I saw, but I changed it :-/ | 19:38 |
| lambday | anyway... I am not sure | 19:38 |
| lambday | wait I am checking | 19:38 |
| lambday | cocg sucks it means :-/ | 19:39 |
| lambday | I should test | 19:39 |
| @HeikoS | lambday: yes, everything has to be tested ;) | 19:44 |
| @HeikoS | I know its annoying | 19:44 |
| @HeikoS | lambday: whats your eigen3 version? | 19:45 |
| lambday | checking | 19:45 |
| besser82 | is it intentional git-checkout FTBFS when .git-dir is removed? | 19:50 |
| @sonney2k | besser82, 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 | |
| besser82 | sonney2k: kk, cmake complains about missing value in version.cmake line 48... | 19:59 |
| lambday | HeikoS: can't find the version | 20:01 |
| lambday | HeikoS: errr.... issues with fedora? | 20:01 |
| lambday | HeikoS: where can I find the version? | 20:01 |
| lambday | all headers are in /usr/include/eigen3/ | 20:02 |
| besser82 | lambday: repoquery -a --installed | grep -i "eigen" | 20:02 |
| besser82 | lambday: which version of F you use? | 20:03 |
| lambday | besser82: but I didn't download it from repo | 20:03 |
| besser82 | lamnday: custom build? | 20:03 |
| lambday | besser82: I downloaded it manually and installed it | 20:03 |
| lambday | yes | 20:03 |
| lambday | besser82: I am not in ubuntu/deb but in fedora | 20:03 |
| besser82 | lambday: me, too ;) | 20:04 |
| besser82 | lambday: F19 ships Eigen3 in repos ;) | 20:04 |
| lambday | besser82: I am an old man, I use F16 | 20:04 |
| lambday | :( | 20:04 |
| besser82 | lambday: then update to some supported version ;) | 20:04 |
| lambday | besser82: no other way from the installed dirs? | 20:04 |
| lambday | besser82: at this moment that is not being possible :( | 20:05 |
| besser82 | lambday: there might be more problems than just version | 20:05 |
| besser82 | lambday: used configure-flags and all ;) | 20:05 |
| besser82 | lambday: u know how to use rpmbuild? | 20:05 |
| lambday | besser82: configure flags? for what? | 20:05 |
| @sonney2k | besser82, the version thing should be trivial to fix for someone with cmake skillz | 20:05 |
| besser82 | lambday: when building eigen3 ;) | 20:05 |
| @sonney2k | besser82, our expert is away for a week so it will take me a while | 20:06 |
| lambday | besser82: I don't understand... eigen3 is just a bunch of headers :( | 20:06 |
| besser82 | sonney2k: i can fix, but just wanted to make sure if it is intentional ;) | 20:06 |
| lambday | besser82: I always installed it by hand | 20:06 |
| besser82 | sonney2k: me wrote cmake-buildsys around libyui ;) | 20:07 |
| besser82 | lambday: let me check in pkgdb ;) | 20:07 |
| lambday | sonney2k: wiking is getting married or he is attending some marriage :D | 20:07 |
| @sonney2k | besser82, IIRC we do the following: if .git exists we extract the version from git - actually from develop branch or master - the current branch | 20:07 |
| @sonney2k | lambday, he got married last GSoC so this time he is just attending :) | 20:08 |
| lambday | hehe... ohkay :D | 20:08 |
| @sonney2k | besser82, if .git is not available we extract the date from NEWS - because then it is supposed to be a release | 20:08 |
| lambday | besser82: no other way to know from the installed headers? they never tell it there, do they | 20:09 |
| besser82 | lambday: not really ;) | 20:09 |
| lambday | :'( | 20:09 |
| @HeikoS | lambday: so did you find our the version? | 20:09 |
| lambday | HeikoS: no :( | 20:09 |
| @HeikoS | lambday: maybe just tell cmake to bundle it | 20:09 |
| @HeikoS | then you are using the same version as me | 20:10 |
| lambday | HeikoS: I think it was some 3.1.something | 20:10 |
| besser82 | lambday: if know how to handle rpmbuild, i can give you srpm from current fedora.... | 20:10 |
| lambday | HeikoS: how do I do that? | 20:10 |
| @HeikoS | lambday: could you try to compile with bundled eigen? | 20:10 |
| @HeikoS | BUNDLE_EIGEN=On | 20:10 |
| lambday | HeikoS: alright | 20:10 |
| @HeikoS | I use ccmake for setting those | 20:10 |
| lambday | HeikoS: ccmake? I only know how to use cmake for shogun | 20:11 |
| lambday | :( | 20:11 |
| @HeikoS | ccmake is a "graphical" frontend | 20:11 |
| @HeikoS | ncurses based I think | 20:11 |
| lambday | okay | 20:11 |
| lambday | HeikoS: so from cmdline, BUNDLE_EIGEN=ON should do right?> | 20:12 |
| @iglesiasg | cmake .. -DBUNDLE_EIGEN=ON | 20:12 |
| lambday | besser82: never used it :-/ ... can try | 20:12 |
| besser82 | lambday: kk, will generate srpm for you ;) Can I have your email for sending, please? | 20:13 |
| lambday | besser82: heavensdevil6909@gmail.com | 20:13 |
| lambday | iglesiasg: thanks, trying | 20:13 |
| besser82 | lambday: srpm should be there in a minute ;) | 20:15 |
| besser82 | you need to `yum group install fedora-packager` | 20:16 |
| lambday | besser82: ah, thanks :D | 20:16 |
| lambday | besser82: so this will all go smooth from f16? | 20:16 |
| besser82 | I think so ;) | 20:16 |
| -!- iglesiasg [~iglesias@2001:6b0:1:1041:b8ef:b3e:75c0:30ef] has quit [Quit: Ex-Chat] | 20:16 | |
| besser82 | in F16 there's eigen 3.0.6 in repos ;) | 20:16 |
| lambday | besser82: I am definitely using a newer version | 20:17 |
| lambday | probably 3.1.something | 20:17 |
| lambday | anyway I am trying | 20:17 |
| besser82 | lambday: unpack srpm (with file-roller or such) | 20:17 |
| besser82 | lambday: you need to `yum group install fedora-packager` | 20:18 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 20:18 | |
| besser82 | lambday: then `sudo yum-builddep $PATH_TO/eigen3.spec` | 20:19 |
| besser82 | lambday: then mkdir -p ~/rpmbuild/SOURCES/ | 20:19 |
| lambday | besser82: alright | 20:19 |
| lambday | besser82: :( "Warning: Group fedora-package does not exist." | 20:20 |
| besser82 | lambday: copy eigen3-tarball to ~/rpmbuild/SOURCES | 20:20 |
| lambday | besser82: errr | 20:20 |
| besser82 | you forgot the "r" --> fedora-packageR | 20:20 |
| lambday | sorry | 20:20 |
| lambday | besser82: yes | 20:20 |
| lambday | besser82: thanks :D | 20:21 |
| besser82 | lambday: np ;) | 20:21 |
| besser82 | lambday: when done with all previous steps run: rpmbuild -ba $PATH_TO/eigen3.spec | 20:21 |
| @HeikoS | lambday: and? | 20:28 |
| lambday | besser82: HeikoS building | 20:29 |
| @HeikoS | ok | 20:29 |
| lambday | phew! I thought installing eigen3 was easy | 20:30 |
| lambday | :-/ | 20:30 |
| lambday | HeikoS: which version are you using? | 20:30 |
| @HeikoS | lambday: the bundled one | 20:30 |
| @HeikoS | lambday: and you now? | 20:31 |
| lambday | HeikoS: that option didn't help me | 20:31 |
| lambday | HeikoS: its 3.1.3 | 20:31 |
| @HeikoS | lambday: why? oh you should fill in an issue and assign it to wiking then | 20:31 |
| lambday | HeikoS: not installed yet | 20:31 |
| lambday | HeikoS: yeah I will push him... | 20:31 |
| @HeikoS | I use 3.1.2 I think | 20:32 |
| @HeikoS | so lets see whether you get the error | 20:32 |
| lambday | HeikoS: any idea what causes this error? | 20:32 |
| @HeikoS | yes some eigen interface change | 20:32 |
| lambday | HeikoS: because my earlier version was also 3.1.something and I didn't get any error | 20:32 |
| @HeikoS | method not allowed for integer number | 20:32 |
| lambday | HeikoS: errrr | 20:32 |
| @HeikoS | /home/heiko/Desktop/shogun/shogun/tests/unit/mathematics/logdet/ProbingSampler_unittest.cc:78:210: required from here | 20: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_TYPES | 20:32 |
| @HeikoS | one of those eigen static assertions that allow to hunt down type errors | 20:33 |
| lambday | HeikoS: checking | 20:33 |
| lambday | besser82: the part you said is complete | 20:33 |
| lambday | besser82: that's it, right? | 20:33 |
| besser82 | lambday: so rpmbuild i finished? | 20:33 |
| besser82 | lambday: then you need to install built rpms ;) | 20:34 |
| lambday | besser82: rpmbuild -ba $PATH_TO/eigen3.spec finished | 20:34 |
| besser82 | lambday: rpmbuild told which rpm were built and where they were put ;) | 20:34 |
| besser82 | lambday: you can usually find them in ~/rpmbuild/RPMS/$arch/ | 20:35 |
| besser82 | lambday: you can use yum install $path_to/eigen3-devel.rpm | 20:35 |
| lambday | besser82: I used rpm -ivh <the-rpm> | 20:36 |
| lambday | besser82: that would do, right? | 20:36 |
| lambday | HeikoS: its 3.1.4 btw :D | 20:37 |
| besser82 | lambday: will be another way to install properly ;) | 20:37 |
| lambday | Found Eigen3: /usr/include/eigen3 (found suitable version "3.1.4", required is "3.1.2") | 20:38 |
| lambday | HeikoS: argh, I would have found from this msg itself I think :-/ | 20:39 |
| lambday | anyway building | 20:39 |
| lambday | besser82: thanks a lot, man! | 20:39 |
| lambday | besser82: you are a lifesaver | 20:39 |
| lambday | :) :) | 20:39 |
| besser82 | lambday: np ;) make sure to kill eigen3 version in /usr/local ;) | 20:39 |
| lambday | besser82: already moved | 20:39 |
| lambday | to eigen3_old | 20:40 |
| lambday | :D | 20:40 |
| besser82 | lambday: kk, then all is fine ;) | 20:40 |
| lambday | HeikoS: yep you are right | 20:41 |
| lambday | I get this error | 20:41 |
| lambday | HeikoS: wait I am checking | 20:41 |
| @HeikoS | lambday: cool, if you found a fix, let me know ;) | 20:41 |
| @HeikoS | I need unit tests | 20:41 |
| lambday | sure | 20:41 |
| @HeikoS | changing things... | 20:41 |
| besser82 | sonney2k: on make install built-examples get installed, too. Thats nasty... I wouldn't expect to get them installed ;) | 20:43 |
| lambday | HeikoS: this is a stupid error :( the obvious way is to convert it to float64_t :( | 20:44 |
| lambday | I can do that :( | 20:44 |
| besser82 | lambday: :D | 20:44 |
| lambday | besser82: :D :( | 20:44 |
| @HeikoS | lambday: no let me do it | 20:44 |
| @HeikoS | sending a pr already | 20:44 |
| @HeikoS | which file and line? | 20:44 |
| lambday | HeikoS: alright | 20:44 |
| lambday | HeikoS: I already committed regarding the display_matrix/vector thing, so sending a PR with just that | 20:45 |
| @HeikoS | lambday: then put in the other thing too :) | 20:45 |
| lambday | HeikoS: other things as in? | 20:45 |
| -!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has joined #shogun | 20:46 | |
| lambday | HeikoS: in the sampler itself... nothing has to changed, just that eigen3 can't compute norms for ints it seems | 20:46 |
| lambday | HeikoS: sorry I meant in the unit-test itself | 20:46 |
| lambday | HeikoS: in the unit-test, I computed the coloring seperately, and used our Probing sampler to compute the coloring and then compare these two colorings | 20:47 |
| lambday | HeikoS: these color things are in int32_t, for which eigen3 can't compute norm now :( | 20:47 |
| @HeikoS | lambday: weird | 20:48 |
| @HeikoS | lambday: put the fix for the eigen error in the pr | 20:48 |
| lambday | HeikoS: really weird! | 20:48 |
| @HeikoS | lambday: it makes sense that eigen cannot do that | 20:48 |
| lambday | HeikoS: why is that? | 20:48 |
| @HeikoS | prevents weird type errors | 20:48 |
| @HeikoS | if you want to stay in int domain | 20:48 |
| @HeikoS | and c is typed so thats the way it should be | 20:49 |
| @HeikoS | eigen vectors are typed too | 20:49 |
| @HeikoS | you can probably convert it explicitly | 20:49 |
| lambday | but what's wrong with computing norm? | 20:49 |
| lambday | implicit typecast is available all across the lang :( | 20:49 |
| @HeikoS | its not even defined for vectors over N^n | 20:49 |
| @HeikoS | well | 20:50 |
| @HeikoS | thats the way it is | 20:50 |
| @HeikoS | could you send the PR so that I can rebase against it? | 20:50 |
| lambday | HeikoS: you mean, changing the unit-test as well? | 20:50 |
| @HeikoS | lambday: yes | 20:50 |
| lambday | HeikoS: alright.. just a moment | 20:50 |
| lambday | HeikoS: 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 matrix | 20:53 |
| @HeikoS | lambday: ok thats good | 20:53 |
| @HeikoS | lambday: what do you think of the idea to add copies of all existing unit tests with the ozone matrix? | 20:54 |
| lambday | HeikoS: that would be perfect! | 20:54 |
| lambday | HeikoS: I have to put the big ozone_matrix in somewhere in the repo then, right? | 20:54 |
| @HeikoS | lambday: yes, how big is the sparse thing? | 20:55 |
| lambday | 70+ MB | 20:55 |
| lambday | in smvlight format | 20:55 |
| lambday | HeikoS: sent the PR | 20:57 |
| @HeikoS | lambday: phew! | 20:57 |
| @HeikoS | sonney2k: can we add a 70mb data matrix to data? | 20:57 |
| lambday | sonney2k: :( | 20:57 |
| @HeikoS | lambday: tests are green? | 20:58 |
| lambday | HeikoS: just added | 20:58 |
| @HeikoS | at your machine? | 20:58 |
| lambday | HeikoS: yes at my machine yes | 20:58 |
| @HeikoS | ah ok this doesnt change anything | 20:58 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 20:58 | |
| shogun-notifier- | shogun: lambday :develop * 1f0da69 / tests/unit/ (2 files): https://github.com/shogun-toolbox/shogun/commit/1f0da6923ce1af363070d881286124ca56195d81 | 20: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/d918d1a1e21826160dc0a2e1e92a7c2b1242aafd | 20:58 |
| shogun-notifier- | shogun: Merge pull request #1515 from lambday/feature/log_determinant | 20: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 #shogun | 20:59 | |
| @HeikoS | lambday: ok thanks for that | 20:59 |
| @HeikoS | lambday: I will add my changes soon | 20:59 |
| lambday | for ozone, the method still doesn't converge | 20:59 |
| @HeikoS | lambday: are there any sub-parts we should check? | 21:00 |
| lambday | HeikoS: hmm | 21:00 |
| @HeikoS | lambday: since the eigenvalues might be estimated negatively | 21:00 |
| lambday | HeikoS: oh today is report day | 21:00 |
| @HeikoS | and other things might go wrong | 21:00 |
| lambday | HeikoS: you mean some of the eigenvalues are negative? | 21:00 |
| lambday | HeikoS: I just noticed that the Lanczos eigensolver didn't converge | 21:01 |
| @HeikoS | lambday: they are not negative, but arbitrarily close to zero | 21:01 |
| lambday | for ozone | 21:01 |
| @HeikoS | lambday: so one needs to run things for longer | 21:01 |
| @HeikoS | lambday: where is the best place to assert that they are positive? | 21:01 |
| lambday | HeikoS: none! we assume that the matrix is psd when someone is tries to use CG based solvers | 21:02 |
| lambday | :( | 21:02 |
| lambday | I can add that check thogh | 21:02 |
| @HeikoS | lambday: | 21:02 |
| @HeikoS | /home/heiko/Desktop/shogun/shogun/tests/unit/mathematics/logdet/RationalApproximation_unittest.cc:273: Failure | 21:02 |
| @HeikoS | The difference between (map_xd-map_xs).norm() and 0.0 is 0.017611379876991774, which exceeds 0.01, where | 21:02 |
| @HeikoS | (map_xd-map_xs).norm() evaluates to 0.017611379876991774, | 21:02 |
| @HeikoS | 0.0 evaluates to 0, and | 21:02 |
| @HeikoS | 0.01 evaluates to 0.01. | 21:02 |
| lambday | argh what is wrong with my english :( | 21:02 |
| @HeikoS | this one is also still there | 21:02 |
| shogun-buildbot | build #1958 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1958 | 21:02 |
| @HeikoS | or did I introduce it? ;) | 21:02 |
| lambday | HeikoS: this is related to the cocg solver, right? | 21:03 |
| @HeikoS | lambday: dont know, I had no unit tests before I started changing things :D | 21:03 |
| @HeikoS | lambday: I know we assume psd, but if the smallest eigenvalue is too small, the computer runs into troubles | 21:03 |
| lambday | this is weird :( | 21:03 |
| @HeikoS | lambday: and the way to resolve this is to run the eigensolver for longer | 21:03 |
| shogun-buildbot | build #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 |
| @HeikoS | lambday: until the values get positive | 21:03 |
| @HeikoS | lambday: if not, throw an error | 21:04 |
| lambday | HeikoS: what will be too small for our case :( | 21:04 |
| lambday | the smallest is like 0.something and the largest is 1000000.something | 21:04 |
| @HeikoS | lambday: dont know, but even for toy matrices which have eigenvalues around 0.0001, the smallest estimated one is negative | 21:05 |
| shogun-buildbot | build #75 of osx1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/osx1%20-%20libshogun/builds/75 | 21:05 |
| lambday | HeikoS: you're adding that #shifts related things? | 21:05 |
| lambday | HeikoS: 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 #shogun | 21:07 | |
| shogun-buildbot | build #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 |
| lambday | HeikoS: just one thing I changed in the COCG today which is disastrous | 21:08 |
| lambday | what is more weird is that, for fixed examples, we get different results... I should check this | 21:08 |
| shogun-buildbot | build #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 |
| @HeikoS | lambday: could you elaborate a bit more? | 21:16 |
| lambday | HeikoS: regarding determining the number of shifts? | 21:17 |
| @HeikoS | lambday: no the cocg thing you mentioned | 21:18 |
| lambday | HeikoS: changed the computation of beta parameter which earlier I made a mistake' | 21:22 |
| @HeikoS | ok? | 21:22 |
| lambday | HeikoS: it should be ||r_{i+1)||_{2}/||r_{i}||_{2| | 21:23 |
| lambday | HeikoS: the same thing that I changed for CG and CG-M based solvers | 21:23 |
| @HeikoS | ok | 21:24 |
| lambday | HeikoS: you will be needing cocg to work for individual jobs too, right? :( | 21:24 |
| @HeikoS | lambday: so the broken unit test is a consequence of this patch | 21:24 |
| @HeikoS | https://travis-ci.org/shogun-toolbox/shogun/builds/10896573 | 21:24 |
| @HeikoS | lambday: the family based solver is fine for now | 21:25 |
| lambday | HeikoS: yes :) | 21:25 |
| @HeikoS | individual jobs are getting interesting once we precondition things to increase/decrease the eigenvalues | 21:25 |
| lambday | HeikoS: will fix COCG soon | 21:25 |
| lambday | HeikoS: checking the errors | 21:25 |
| lambday | nice | 21:27 |
| lambday | so, things to be added are - | 21:27 |
| lambday | 1) checks for too small eigenvalues | 21:27 |
| lambday | 2) automaticallt computing shifts in RationalApproximation (which you are adding, right?) | 21:27 |
| lambday | 3) fixing COCG | 21:27 |
| lambday | 4) ... :-/ | 21:28 |
| @HeikoS | lambday: I just fixed 2 | 21:30 |
| @HeikoS | lambday: btw if I compute 100 log-det estimates, everything that can be precomputed is precomputed right? | 21:30 |
| lambday | HeikoS: yes... coloring and shifts are computed only once | 21:31 |
| @HeikoS | lambday: good :) | 21:31 |
| lambday | I need to check the COCG solver | 21:31 |
| @HeikoS | lambday: so then, we should start adding tests for challenging matrices, once cocg is working | 21:31 |
| lambday | :( one mistake fixed, another one pops out :( | 21:31 |
| @HeikoS | lambday: again, I am sure these problems are bugs, so dont worry too much, just systematically test things | 21:32 |
| lambday | HeikoS: we can add these for CG-M as well, no? | 21:32 |
| lambday | but for ozone, its tough to get things into convergence | 21:32 |
| lambday | ':-/ | 21:33 |
| lambday | HeikoS: hopefully these are bugs | 21:33 |
| @HeikoS | lambday: yeah, before ozone, try to fix more obvious problems | 21:33 |
| @HeikoS | for ozone, there are loads of things that can go wrong | 21:34 |
| lambday | HeikoS: more obvious problems as in? too small eigenvalues, right? | 21:34 |
| @HeikoS | lambday: yes | 21:34 |
| @HeikoS | there is something wrong with the probing sampler | 21:34 |
| lambday | HeikoS: I am confused regarding how small should we consider as "too small" | 21:34 |
| lambday | :( | 21:34 |
| @HeikoS | lambday: ok so again on the eigenvalues | 21:35 |
| lambday | HeikoS: what's wrong? | 21:35 |
| @HeikoS | lambday: matrices might have EV that are veeeery close to 0 | 21:35 |
| @HeikoS | now we estimate those with lanczos and accuracy 1-5 | 21:35 |
| @HeikoS | we get a negative value | 21:35 |
| @HeikoS | and everything breaks (so we have to throw an error and stop) | 21:36 |
| lambday | alright.. | 21:36 |
| @HeikoS | but with 1e-15, it might work so that the number we get is positive | 21:36 |
| lambday | okay noted | 21:36 |
| @HeikoS | lambday: and for the probe sampler | 21:36 |
| @HeikoS | it seems to return the same sample all the time | 21:36 |
| @HeikoS | variance of the log-det estimate is zero | 21:36 |
| lambday | same sample?? | 21:36 |
| lambday | but the thing is probabilistic :-o | 21:37 |
| @HeikoS | lambday: thats why something is strange | 21:37 |
| lambday | wait cehcking | 21:37 |
| @HeikoS | variance zero=? | 21:37 |
| @HeikoS | or might that be my diagonal matrix causing it? | 21:37 |
| lambday | HeikoS: might be | 21:37 |
| lambday | HeikoS: could you please try with a different one? | 21:37 |
| @HeikoS | lambday: should not | 21:37 |
| @HeikoS | lambday: the matrix is | 21:37 |
| shogun-buildbot | build #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 |
| lambday | HeikoS: it surely produces different sample vectors | 21:38 |
| @HeikoS | data=abs(randn(n)**2) | 21:38 |
| @HeikoS | is the diagonal | 21:38 |
| lambday | HeikoS: the variance is absolutely zero?? | 21:38 |
| lambday | :-o | 21:38 |
| @HeikoS | lambday: let me show you a notebook | 21:38 |
| lambday | alright | 21:39 |
| @HeikoS | lambday: http://nbviewer.ipython.org/6416583 | 21:39 |
| @HeikoS | ah shit | 21:39 |
| @HeikoS | didnt save,wait | 21:39 |
| @HeikoS | lambday: ok reload | 21:40 |
| lambday | horizontal! :| | 21:41 |
| lambday | HeikoS: how this thing can be same every thing?? :'( https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/mathematics/logdet/ProbingSampler.cpp#L194 | 21:43 |
| @HeikoS | lambday: but converges to the same value | 21:43 |
| lambday | HeikoS: that should not happen? | 21:43 |
| lambday | may be the matrix is trivial | 21:44 |
| lambday | :-/ | 21:44 |
| @HeikoS | lambday: it always return 0 samples in this case | 21:44 |
| shogun-buildbot | build #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 |
| lambday | HeikoS: that's not possible if it enters the else block | 21:45 |
| @HeikoS | lambday: reload again | 21:45 |
| lambday | so, please check num_samples | 21:45 |
| @HeikoS | lambday: there is more weird stuff | 21:45 |
| lambday | less than 0 | 21:46 |
| lambday | ! | 21:46 |
| lambday | index | 21:46 |
| lambday | errr | 21:46 |
| @HeikoS | did I do anything wrong there? | 21:46 |
| lambday | HeikoS: just one thing is causing all these | 21:46 |
| lambday | I am trying to figure out | 21:47 |
| lambday | HeikoS: why m_num_samples is 0?? | 21:47 |
| lambday | m_num_samples is the number of colors it uses to color the graph | 21:47 |
| lambday | HeikoS: please check this https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/mathematics/logdet/ProbingSampler.cpp#L187 | 21:48 |
| @HeikoS | lambday: yep, so forgotten set of this somewhere? | 21:48 |
| @HeikoS | lambday: maybe its my python code | 21:48 |
| lambday | HeikoS: no no.. since its a diag matrix, it uses only one color | 21:49 |
| lambday | earlier I made a mistake, did you rebase? | 21:49 |
| @HeikoS | lambday: btw this warning is not so useful, should be something that users understand :) | 21:49 |
| @HeikoS | lambday: let me try | 21:49 |
| lambday | HeikoS: number of colors should be 1 | 21:49 |
| @HeikoS | no my develop is up to date | 21:49 |
| lambday | ummm | 21:50 |
| lambday | HeikoS: could you please try to print the probing vector? :( | 21:50 |
| lambday | HeikoS: this *has to* give it at least one https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/mathematics/logdet/ProbingSampler.cpp#L176 | 21:51 |
| @HeikoS | lambday: ok | 21:51 |
| lambday | :'( | 21:51 |
| lambday | HeikoS: you are right regarding this warning... but I thought this should never happen | 21:52 |
| lambday | HeikoS: please make sure that ColPack works properly :( | 21:53 |
| @HeikoS | lambday: ehm | 21:53 |
| @HeikoS | how? :D | 21:53 |
| @HeikoS | I installed it | 21:53 |
| lambday | HeikoS: wait I am giving you a small program | 21:53 |
| lambday | that should run | 21:53 |
| lambday | HeikoS: https://gist.github.com/lambday/6416709 | 21:56 |
| lambday | HeikoS: refresh | 21:57 |
| lambday | just pasted output from my machine | 21:57 |
| lambday | HeikoS: I will get dc now argh :'( :'( | 21:58 |
| lambday | HeikoS: please let me know if you discover any bug regarding this :( | 21:58 |
| @HeikoS | lambday: maybe its time for some break :) | 21:58 |
| @HeikoS | lambday: let me put up some changes to the python code | 21:58 |
| @HeikoS | I will update it then and merge my PR | 21:59 |
| @HeikoS | then you can test it, too | 21:59 |
| lambday | HeikoS: hehe yes | 21:59 |
| lambday | alright | 21:59 |
| lambday | HeikoS: when is your presentation? | 22:00 |
| @HeikoS | lambday: next week | 22:00 |
| @HeikoS | lambday: so we really need to hurry, but if it doesnt work, I wont be killed | 22:00 |
| @HeikoS | would just be cool | 22:00 |
| lambday | I hope all things work properly by then :-s | 22:00 |
| @HeikoS | tomorrow I am meeting a cluster guy to allocate 2000 nodes for me :) | 22:00 |
| pickle27 | HeikoS: did you see my new PR for the notebook? | 22:00 |
| @HeikoS | pickle27: not yet, should I have a look? | 22:00 |
| pickle27 | HeikoS: yeah, it should be a quick merge, slash I don't think you'll be able to see the diff | 22:01 |
| pickle27 | I added some text but mainly I cleared the graphics | 22:01 |
| @HeikoS | lambday: http://nbviewer.ipython.org/6416583 | 22:03 |
| @HeikoS | check this out just ran everything from scratch | 22:03 |
| lisitsyn | pickle27: let me | 22:04 |
| lisitsyn | ;) | 22:04 |
| shogun-notifier- | shogun: Kevin :develop * 9e23773 / doc/ipython-notebooks/ica/bss_jade.ipynb: https://github.com/shogun-toolbox/shogun/commit/9e23773613b50b3bbc5a4e16cefa84700b22ee9f | 22:04 |
| shogun-notifier- | shogun: updated jade notebook and cleared all the graphics | 22:04 |
| lisitsyn | okay I can't see diff | 22:04 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * caf6ea2 / doc/ipython-notebooks/ica/bss_jade.ipynb: https://github.com/shogun-toolbox/shogun/commit/caf6ea2b4ccb3285a7536e8f0038791277f88f5c | 22:04 |
| shogun-notifier- | shogun: Merge pull request #1514 from pickle27/develop | 22:04 |
| shogun-notifier- | shogun: | 22:04 |
| shogun-notifier- | shogun: updated jade notebook and cleared all the graphics | 22:04 |
| lisitsyn | ahhh | 22:04 |
| pickle27 | lisitsyn: ah didn't notice you were here | 22:04 |
| lisitsyn | heiko did the blind merge instead of me | 22:04 |
| lisitsyn | :D | 22:04 |
| -!- lambday [67157f36@gateway/web/freenode/ip.103.21.127.54] has quit [Ping timeout: 250 seconds] | 22:04 | |
| lisitsyn | pickle27: how is it going? | 22:04 |
| pickle27 | lisitsyn: HeikoS well now that the graphics are done we should be able to see diffs on it if I make more changes | 22:05 |
| pickle27 | lisitsyn: good! | 22:05 |
| @HeikoS | pickle27: yeah hopefully! | 22:05 |
| pickle27 | lisitsyn: Im almost done ICA and the ECG example | 22:05 |
| lisitsyn | pickle27: cool | 22:05 |
| pickle27 | I've been playing with the ruby_modular interface a bunch this week | 22:05 |
| lisitsyn | pickle27: and how it was? | 22:05 |
| pickle27 | looking at updating to NMatrix / SciRuby from NArray | 22:05 |
| pickle27 | lisitsyn: its been kind of fun hacking around | 22:07 |
| pickle27 | nothing is working 100% yet though | 22:07 |
| lisitsyn | pickle27: what problems have you met? | 22:08 |
| pickle27 | lisitsyn: namely just fighting with the NMatrix api | 22:08 |
| shogun-buildbot | build #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 |
| pickle27 | lisitsyn: 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 time | 22:09 |
| lisitsyn | pickle27: uh | 22:09 |
| lisitsyn | I see | 22:09 |
| pickle27 | now I am trying a new approach | 22:09 |
| lisitsyn | anything I can help you with? | 22:09 |
| pickle27 | lisitsyn: ummm I think I am good for the moment, but I will let you know! | 22:10 |
| lisitsyn | alright | 22:10 |
| lisitsyn | pickle27: 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/2495ea3e15bbe2c7753b8c756accdb6573fb0de5 | 22:11 |
| shogun-notifier- | shogun: added method to compute number of shifts from accuracy and also added | 22:11 |
| shogun-notifier- | shogun: a constructor to set this accuracy. Some minor refactoring otherwise | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 4d11dc6 / tests/unit/mathematics/logdet/RationalApproximation_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/4d11dc6b19ce20890201390d1eeee08dd419dda7 | 22:11 |
| shogun-notifier- | shogun: make unit test use newly added method to compute the number of shifts | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * cd23cb8 / src/shogun/mathematics/logdet/ (5 files): https://github.com/shogun-toolbox/shogun/commit/cd23cb822ae06e82aac8e6466fa8502f80e6e76c | 22:11 |
| shogun-notifier- | shogun: Added accuracy based constructors to implementations of rational approximation base class | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 6cf0a9a / src/shogun/mathematics/logdet/RationalApproximation.cpp: https://github.com/shogun-toolbox/shogun/commit/6cf0a9aa8d74b8064abeb3160813d805f4299ff2 | 22:11 |
| shogun-notifier- | shogun: provide information in case of negative accuracy | 22:11 |
| lisitsyn | pickle27: I mean I have seen quite a lot shogun segfaults :D | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * e324259 / tests/unit/mathematics/logdet/RationalApproximation_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/e324259cf25957903b4763701eb264d441df2261 | 22:11 |
| shogun-notifier- | shogun: using existing method to compute accuracy | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * eb533ce / src/shogun/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/eb533ce0e88cde59d4892c8305fb0a7fb8660df0 | 22:11 |
| shogun-notifier- | shogun: added my name to copyright | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 5745b0b / / (7 files): https://github.com/shogun-toolbox/shogun/commit/5745b0b5887c306ceb0bac63c8eead9d99896035 | 22:11 |
| shogun-notifier- | shogun: remove constructor with num shifts and offer a method to set that instead | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 4b56820 / tests/unit/mathematics/logdet/ (2 files): https://github.com/shogun-toolbox/shogun/commit/4b568200d1c05c6c09b533d81fce2357b3a4b6f5 | 22:11 |
| shogun-notifier- | shogun: replace constructor call with num_shifts with dummy value for accuracy and set num shifts by hand | 22:11 |
| shogun-notifier- | shogun: Heiko Strathmann :develop * 00ad5d9 / tests/unit/mathematics/logdet/RationalApproximation_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/00ad5d96d46a6c836fa08606603b4eb1e0f31383 | 22:11 |
| lisitsyn | heiko-tron | 22:11 |
| @HeikoS | travis should go green with this, hopefully | 22:11 |
| lisitsyn | HeikoS: you basically heikonized the channel | 22:12 |
| @HeikoS | lisitsyn: haha :) | 22:12 |
| @HeikoS | ok going home now | 22:12 |
| @HeikoS | see you guys | 22:12 |
| lisitsyn | ciao! | 22:12 |
| votjakovr | HeikoS: see you ;) | 22:12 |
| @HeikoS | lisitsyn: votjakovr: see you! | 22:13 |
| lisitsyn | pickle27: I wanted to ask you about one thing with the saliency filter | 22:13 |
| pickle27 | lisitsyn: yeah? | 22:13 |
| lisitsyn | well I can simplify it | 22:13 |
| lisitsyn | how to make it work haha | 22:13 |
| -!- HeikoS [~heiko@nat-169-160.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 22:14 | |
| pickle27 | lisitsyn: my code or the idea in general? | 22:14 |
| lisitsyn | pickle27: both - I tried your code but I don't get how does it work | 22:14 |
| pickle27 | lisitsyn: okay let me pull it up | 22:14 |
| lisitsyn | pickle27: the problem is that I get quite low quality fg masks | 22:15 |
| pickle27 | lisitsyn: looking at my implementation I basically did this | 22:16 |
| pickle27 | I found all the "blobs" of connected foreground pixels in the low threshold mask | 22:16 |
| lisitsyn | pickle27: I admit I don't get what should I expect | 22:16 |
| lisitsyn | pickle27: how would you handle disconnected parts? | 22:17 |
| shogun-buildbot | build #1960 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1960 | 22:17 |
| pickle27 | then I check each pixel in each blob and mark if it is also foreground in the high threshold mask I inc a counter | 22:18 |
| pickle27 | a blob has to have a certain ratio or else it get filtered | 22:18 |
| pickle27 | so you want to set your low threshold lower | 22:18 |
| pickle27 | than you otherwise might | 22:18 |
| shogun-buildbot | build #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-buildbot | build #1964 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb1%20-%20libshogun/builds/1964 | 22:21 |
| lisitsyn | pickle27: can you take a look at fg/bg masks I get? may be I miss something | 22:22 |
| pickle27 | sure | 22:22 |
| lisitsyn | pickle27: argh do you have any snippet to join a few images into one? | 22:23 |
| pickle27 | like as a video? | 22:23 |
| lisitsyn | video1 | video2 | video3 | 22:23 |
| pickle27 | hmm nothing that would be quick I don't think | 22:24 |
| pickle27 | I often would just writing something in opencv and python | 22:24 |
| pickle27 | but never really save it | 22:24 |
| lisitsyn | I see | 22:24 |
| lisitsyn | okay in a minute | 22:25 |
| shogun-buildbot | build #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 |
| lisitsyn | pickle27: sent | 22:27 |
| lisitsyn | pickle27: do you find it reasonable? | 22:28 |
| pickle27 | yeah Im trying to play in slow motion | 22:28 |
| lisitsyn | I mean I can definitely detect something going on | 22:28 |
| lisitsyn | but it is even hard to find proper ROI | 22:29 |
| lisitsyn | pickle27: that's adaptive median | 22:29 |
| shogun-buildbot | build #1048 of rpm1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/rpm1%20-%20libshogun/builds/1048 | 22:29 |
| pickle27 | lisitsyn: and thats the lowest thresh you can go before it starts classifying too much? | 22:29 |
| lisitsyn | pickle27: I haven't really tuned it | 22:30 |
| pickle27 | lisitsyn: also I find it easier to look at the masks than the contours output | 22:30 |
| pickle27 | try droping the thresh | 22:30 |
| lisitsyn | pickle27: okay let me send you mask | 22:30 |
| lisitsyn | pickle27: what would you say about adaptive median? | 22:31 |
| shogun-buildbot | build #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 |
| pickle27 | lisitsyn: for a threshold? hmm | 22:31 |
| lisitsyn | pickle27: no I mean the method | 22:31 |
| lisitsyn | pickle27: is it ok at all? | 22:31 |
| pickle27 | lisitsyn: I think it should be okay for indoors | 22:31 |
| shogun-buildbot | build #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 |
| pickle27 | lisitsyn: I really think you are going to need something more than BGS though | 22:34 |
| lisitsyn | pickle27: yes indeed | 22:34 |
| pickle27 | like use BGS to get a guess then do some kind of detection | 22:34 |
| lisitsyn | pickle27: just want to make it more reliable before I go next steps | 22:35 |
| pickle27 | yeah probably a good call | 22:35 |
| lisitsyn | https://dl.dropboxusercontent.com/u/10139213/share/processed.avi | 22:35 |
| lisitsyn | pickle27: ^ | 22:35 |
| pickle27 | lisitsyn: is the backgound always going to be the same? do you have data of just the background? | 22:37 |
| lisitsyn | pickle27: the main thing that bothers me is lightning changes on the floor | 22:37 |
| lisitsyn | pickle27: yes it is mostly the same | 22:37 |
| lisitsyn | just speckles and some jittering | 22:37 |
| pickle27 | lisitsyn: you could look into training BG model beforehand | 22:37 |
| lisitsyn | pickle27: please elaborate ;) | 22:38 |
| pickle27 | lisitsyn: this video won't play in browser, can you just link the folder | 22:38 |
| lisitsyn | oh sorry | 22:38 |
| lisitsyn | okay let me email it | 22:38 |
| pickle27 | lisitsyn: you run a method like adaptive median or any of the others on all the data you have of the BG and save the model | 22:38 |
| pickle27 | then don | 22:38 |
| pickle27 | 't bother with learning or update while detecting | 22:39 |
| lisitsyn | pickle27: what would be the best method that pre-learns? | 22:39 |
| pickle27 | lisitsyn: you can pre-learn any method | 22:39 |
| pickle27 | lisitsyn: but Eigenbackground can only pre learn and is pretty good | 22:39 |
| pickle27 | lisitsyn: also did my whole thesis on it lol | 22:40 |
| lisitsyn | pickle27: eigenbackground is basically pca of the image right? | 22:40 |
| shogun-buildbot | build #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 |
| pickle27 | lisitsyn: yeah | 22:40 |
| lisitsyn | pickle27: have you ever seen any applications of a method that learns using some custom features (not just pixels)? | 22:41 |
| pickle27 | lisitsyn: some people have done some stuff with local binary patterns | 22:42 |
| pickle27 | I don't think this would work well for you though because there isn't a lot of texture | 22:42 |
| lisitsyn | yeah lbp is good for real textures | 22:42 |
| lisitsyn | well it works for faces though | 22:42 |
| pickle27 | at some point it transitions from being called BGS to being called segmentation, and I haven't done much work there | 22:43 |
| pickle27 | it works good for BGS too in some cases | 22:43 |
| lisitsyn | pickle27: real segmentation is not going to be real-time :( | 22:43 |
| pickle27 | lisitsyn: yeah | 22:44 |
| lisitsyn | pickle27: I wish I just graph cut it or whatever :D | 22:44 |
| pickle27 | lisitsyn: well you could try and do obj detection using SIFT features | 22:44 |
| pickle27 | sift is fast enough | 22:44 |
| pickle27 | and it might work | 22:44 |
| lisitsyn | pickle27: yes that's going to work I believe | 22:44 |
| lisitsyn | SIFT SURF whatever | 22:44 |
| lisitsyn | pickle27: well probably the workflow would be BGS to detect changes | 22:45 |
| lisitsyn | then start tracking keypoints | 22:45 |
| pickle27 | lisitsyn: you might even be able to skip the bgs and just use SIFT to detect if the car is there or not | 22:45 |
| lisitsyn | pickle27: haha true | 22:45 |
| lisitsyn | this would mean I spend a week for nothing | 22:46 |
| lisitsyn | :D | 22:46 |
| pickle27 | lisitsyn: BGS is so frustrating because you can get so close to what you need but never quite enough | 22:46 |
| lisitsyn | pickle27: oh I think I know why you find it frustrating | 22:46 |
| lisitsyn | you did a thesis on that | 22:46 |
| pickle27 | haha yup | 22:47 |
| lisitsyn | that's the best practice to start feeling X boring and frustrating | 22:47 |
| pickle27 | lisitsyn: but in other news, my ruby out typemap works now | 22:47 |
| lisitsyn | yup | 22:47 |
| lisitsyn | nice | 22:47 |
| lisitsyn | pickle27: have you used FREAK btw? | 22:48 |
| lisitsyn | I tried it once | 22:48 |
| lisitsyn | interesting thing actually | 22:48 |
| shogun-buildbot | build #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 |
| pickle27 | lisitsyn: yeah isn't that made by University of Ottawa? | 22:48 |
| lisitsyn | hmm it seems not | 22:49 |
| lisitsyn | http://www.ivpe.com/pub.php | 22:49 |
| lisitsyn | that's the author | 22:49 |
| pickle27 | lisitsyn: hmm oh they were MoFREAK | 22:49 |
| pickle27 | U of O made them 3D | 22:49 |
| lisitsyn | pickle27: it was DAISY then it called FREAK | 22:49 |
| lisitsyn | HOGs are dense SIFTS :D | 22:49 |
| lisitsyn | SURFs are SIFTs but not patented | 22:50 |
| pickle27 | lisitsyn: heres a question, is there a way to make a function that returns a type? | 22:50 |
| lisitsyn | uhh | 22:50 |
| lisitsyn | by type you mean what? | 22:50 |
| lisitsyn | class? | 22:50 |
| pickle27 | lisitsyn: here is my problem | 22:50 |
| lisitsyn | C++ have no first-class citizenship for classes you know ;0 | 22:50 |
| lisitsyn | ;) | 22:50 |
| pickle27 | NMatrix has a method for getting the data type in the API but it returns an int | 22:50 |
| pickle27 | I need to turn that int into a type | 22:51 |
| pickle27 | currently I am using a switch and it bothers me | 22:51 |
| lisitsyn | just switch it | 22:51 |
| lisitsyn | yeah what else can you do | 22:51 |
| pickle27 | lisitsyn: I dunno I was hoping to finding something cleaner | 22:51 |
| pickle27 | or even some way to encapulate | 22:51 |
| lisitsyn | pickle27: that's compile-runtime tradeoff :) | 22:52 |
| lisitsyn | pickle27: I guess you need SGMatrix<whatever> | 22:52 |
| lisitsyn | but you can't put anything outside of <> inside <> | 22:52 |
| lisitsyn | pickle27: I guess that's why cv::Mat is not templated :) | 22:53 |
| pickle27 | isn't cv::Mat templated? | 22:53 |
| pickle27 | I thought it was | 22:53 |
| pickle27 | oh nvm | 22:53 |
| lisitsyn | pickle27: ;) | 22:54 |
| lisitsyn | pickle27: I haven't looked inside it though | 22:54 |
| pickle27 | you can construct without a template arg | 22:54 |
| lisitsyn | inside it is I believe | 22:54 |
| pickle27 | yeah they do some weirdness under there | 22:54 |
| pickle27 | because they use templates in the lib for sure but the user doesn't have to use them | 22:54 |
| lisitsyn | pickle27: I find this solution not that bad | 22:55 |
| pickle27 | lisitsyn: 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 |
| pickle27 | http://pastebin.com/T3npGt5s | 22:55 |
| -!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has joined #shogun | 22: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/10905742 | 22:56 |
| -!- travis-ci [~travis-ci@ec2-107-20-114-62.compute-1.amazonaws.com] has left #shogun [] | 22:56 | |
| pickle27 | lisitsyn: I think I am going to at least move the switch into a function | 22:56 |
| lisitsyn | pickle27: oh please don't move it | 22:56 |
| lisitsyn | pickle27: you would interrupt some optimization here this way I think | 22:56 |
| lisitsyn | see what I mean? | 22:56 |
| pickle27 | lisitsyn: no? but I have the same code for Vector and Matrix | 22:57 |
| lisitsyn | pickle27: not a great deal | 22:57 |
| pickle27 | lisitsyn: not sure I totally understand but I think I can sort of see your point | 22:57 |
| lisitsyn | pickle27: but w/o function it can move switch out of loops | 22:57 |
| lisitsyn | by it I mean compiler | 22:57 |
| pickle27 | ahh interesting okay | 22:57 |
| pickle27 | I shall leave it then | 22:58 |
| lisitsyn | pickle27: I don't know any better way to do that though | 22:58 |
| pickle27 | lisitsyn: fair enough | 22:58 |
| lisitsyn | pickle27: it is just the place where compile stuff meets runtime stuff | 22:59 |
| shogun-buildbot | build #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-buildbot | build #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-buildbot | build #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-buildbot | build #1670 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.orgbuilders/deb3%20-%20modular_interfaces/builds/1670 | 23:24 |
| lisitsyn | pickle27: alright keypoint based approach probably looks better :D | 23:45 |
| lisitsyn | pickle27: thanks a lot for you suggestions | 23:45 |
| -!- lisitsyn [~lisitsyn@fb2-lo1.global63.net] has quit [Quit: Leaving.] | 23:46 | |
| -!- iglesiasg [~iglesias@s83-179-44-135.cust.tele2.se] has joined #shogun | 23:53 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 23:53 | |
| --- Log closed Tue Sep 03 00:00:42 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!