Open in new window / Try shogun cloud
--- Log opened Sat Jun 15 00:00:46 2013
-!- lisitsyn [~lisitsyn@109-226-90-135.clients.tlt.100megabit.ru] has quit [Remote host closed the connection]01:18
-!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has quit [Ping timeout: 240 seconds]02:21
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has joined #shogun02:34
-!- foulwall [~foulwall@2001:da8:215:503:d890:fd85:d362:9ad4] has joined #shogun03:12
-!- nube [~rho@49.244.57.163] has joined #shogun04:27
-!- foulwall [~foulwall@2001:da8:215:503:d890:fd85:d362:9ad4] has quit [Remote host closed the connection]04:30
-!- gsomix_ [~gsomix@95.67.173.36] has quit [Read error: Connection reset by peer]08:29
-!- gsomix_ [~gsomix@95.67.168.164] has joined #shogun08:43
-!- gsomix_ is now known as gsomix08:56
gsomixgood morning08:56
-!- iglesiasg [d58f3251@gateway/web/freenode/ip.213.143.50.81] has joined #shogun09:50
-!- mode/#shogun [+o iglesiasg] by ChanServ09:51
-!- lisitsyn [~lisitsyn@109-226-90-135.clients.tlt.100megabit.ru] has joined #shogun11:06
@sonney2klisitsyn, then please finish cmaking!12:46
lisitsynsonney2k: I am a bit stucked12:46
@sonney2kiglesiasg, please take care of sending around the doodle results!12:46
@wikingyo13:04
@wikinglisitsyn: ?13:04
lisitsynwiking: I am a bit lost but will continue later :)13:05
@iglesiasgsonney2k: mail with the hour decided, right?13:05
@iglesiasgI will send it around soon then13:08
-!- iglesiasg [d58f3251@gateway/web/freenode/ip.213.143.50.81] has quit [Quit: Page closed]13:08
@wikingany ideas how to assure (and support the most type of features) that the feature vectors are the same?13:28
-!- HeikoS [~heiko@176.248.212.166] has joined #shogun13:43
-!- mode/#shogun [+o HeikoS] by ChanServ13:43
-!- lambday [67157f4c@gateway/web/freenode/ip.103.21.127.76] has joined #shogun14:12
lambdayHeikoS:  there??14:12
@HeikoSlambday: yes14:12
@HeikoSso thinking about these tasks that we create14:12
@HeikoSthey have to be small in memory14:12
@HeikoSotherwise we cannot store many of them14:12
lambdayyes14:13
@HeikoSso the question is: can be sample the trace vectors on the fly?14:13
@HeikoSwhich means that the job has a member which is the sampler14:13
@HeikoSwhich is called on demand14:13
@HeikoSso that these samples are produced one-by-one14:13
lambdaybut we obntain using graph coloring14:14
lambdayI mean, for the probing case14:14
@HeikoSyes14:14
@HeikoSI mean we would have to change the interfaces slightly14:14
@HeikoSsampler only returns one sample14:14
lambdayalright14:14
lambdaythat's better14:14
@HeikoSbut does that make sense?14:14
@HeikoSnot sure14:14
@HeikoSso the probing vectors at least come in blocks14:15
@HeikoSalso, many jobs share the same sample14:15
@HeikoShow to ensure that?14:15
lambdayit's being really tricky :(14:16
@HeikoSwe might just stores them all14:16
@HeikoSI dont really see problems there14:16
lambdayhow about we just don't store samples twice? samples gotta be stored anyway..14:16
@HeikoSalthough it would be nicer not ot14:16
lambdaybut we just do it in the sgmatrix14:17
lambdayugly, but memory efficient14:17
@HeikoSif the double memory is only for a short time its not a problem14:17
@HeikoSbut the fact *that* we store them might be one14:17
lambdaydidn't get it :(14:18
lambdaystore them might be one?14:18
-!- iglesiasg [d58f3208@gateway/web/freenode/ip.213.143.50.8] has joined #shogun14:18
@HeikoSstoring all those vectors might be a problem14:18
@HeikoSsince memory intensive14:18
@HeikoSand for serial computation thats not even needed)14:18
lambdaybut doing things differently for serial and parallel isn't good, right?14:19
lambdayfor parallel, we do need the vectors with them14:19
@HeikoSlambday: we should be able to handle this within the framework14:19
@HeikoSso there is actually another problem14:19
@HeikoSimagine, you want to compute 100 log-det estimates with each 100 trace samples14:20
@HeikoSin dimension 10^614:20
@HeikoSthen our approach needs 100 times more memory14:20
@HeikoSsince we are storing all of those samples14:20
@HeikoSthat should definitely not be happening14:20
lambdaybut one thing... for probing vectors case, vectors are sparse.. we don't need SGMatrix for storing that!14:20
@HeikoStrue ...14:21
@HeikoSargh14:21
@HeikoSand SGVector and SGSparseVector have no common base14:21
@HeikoS*sigh*14:21
lambdaynope :(14:21
@HeikoSso another issue14:22
@HeikoSwe cannot make the vectors sparse14:22
@HeikoSbut that is no problem14:22
@HeikoSproblem is storing the samples, we have to change this I am afraid14:22
lambday:(14:23
@HeikoSso about these jobs14:23
@HeikoSwe need to set them up in such way that they do not store any data14:23
@HeikoSonly references to data that is shared among them all14:24
@HeikoSand then upon calling compute()14:24
lambdayso, in the compute thing, each job gets a vector, gets the job done, and returns14:24
@HeikoSthey instanciate their data/problem14:24
@HeikoSno rather the jobs have the information they need to create the vector14:25
@HeikoSand then its only created upon calling their compute method14:25
lambdaycreate the vector *within* the job?14:25
@HeikoSyes14:25
@HeikoSgive to it a reference to a sampler14:25
lambdaybut that doesn't make them independent :(14:25
@HeikoShow do you mean that?14:25
lambdayeach job should get one sample.. and the samples are generated in a bunch (using coloring)14:26
lambdaynot one by one14:26
lambdayright?14:26
@HeikoSsamplers?14:27
@HeikoSplural?14:27
lambdayummm..14:28
@HeikoSif each job has a reference to an instance of some sampler14:28
@HeikoSmight be the same one actually14:28
@HeikoSthen it might just generate a sample in its compute method14:28
@HeikoSwouldnt that work?14:29
@HeikoSsay Gaussian samples14:29
lambdayfor gaussian that's okay14:29
@HeikoSok14:29
lambdaybut for probing?14:29
@HeikoSand for probeing?14:30
@HeikoSproibing14:30
lambdaylol14:30
@HeikoSlets think14:30
lambday:P14:30
@HeikoSprobing :)14:30
lambdaygraph coloring info should be there in the sampler14:30
lambdaywhatever it is14:30
@HeikoSyes14:30
lambdayand then that uses the info and generates a bunch of samples14:30
@HeikoSbut the probing vectors are generated in groups aren't they?14:30
lambdayyep14:30
@HeikoShowever14:30
lambdayonce you color the graph and generate a bunch of samples based on that info14:31
@HeikoSthey are independent (otherwise, the monte carlo estimate of the trace wouldnt work)14:31
@HeikoSso one can also just create one probing vector14:31
@HeikoSI might be wrong here14:31
@HeikoSgotta check my matlab code14:31
lambdayI'm not sure :(14:31
@HeikoS"J. Tang and Y. Saad, A probing method for computing the diagonal of the matrix14:33
@HeikoS%   inverse" (2010).14:33
@HeikoSthis is the paper14:33
lambdayit must be doable... cause the bunch of samples are generated in a loop must be...14:33
lambdayso we can have some progress info14:33
lambdayokay checking14:33
@HeikoSlambday:  https://gist.github.com/karlnapf/578797514:34
@HeikoSthe way it works that one create one sample per colour14:34
@HeikoS(at least)14:35
lambdayyes14:35
@HeikoSbut thats easy to store within the job14:35
lambdayso, doable, right?14:35
@HeikoSyes I think so14:35
@HeikoSwe just need to think about some details14:36
@HeikoSthe probing sampler needs to know from which colour to sample from14:36
@HeikoScan just be set as a member variable14:36
lambdayyes14:37
@HeikoSso then a different sampler instance for every colour14:37
@HeikoSnono sorry14:37
@HeikoSjust set the colour before calling sample14:37
@HeikoSwith setter14:37
@HeikoSbut from where is this done?14:37
lambdayyes that's what I was thinking14:37
lambdayhow about..14:38
lambdayeach time we call this sample(), it gives a vector from the next color to sample from?14:38
lambdayand when all the colors are traversed, it gives zero vector or some warning14:39
@HeikoSor just starts from the beginning14:39
@HeikoSthis could work14:39
@HeikoShas one downside:14:39
lambdaydirect solvers14:39
lambdaysame sample for multiple jobs14:40
@HeikoSdoesnt work in parallel computation14:40
@HeikoSsince there we cannot guarantee any order or the jobs being computed14:40
@HeikoSso we need to store this information within the job somehow14:40
@HeikoSso the job needs information about the used sampler14:40
@HeikoSand if its the probing one14:41
@HeikoSit also stores the colour it uses14:41
@HeikoSah ugly14:41
lambdayorder is important?14:41
@HeikoSif the sampler iterates over the colours, yes14:42
lambdayif we compute the final s^T * (log(C)*s) within this compute, then may be not :-/14:43
lambdayoh but then aggregate comes!!14:43
@HeikoSno thats fine14:43
@HeikoSits just that we should use all colours14:43
@HeikoSor we just do it random14:43
@HeikoSah might not be independent anymore then14:44
@HeikoSI think I have to talk to Daniel about this14:44
lambdayall colors, but in random order14:44
@HeikoSyes14:44
lambdaythat should be fine14:44
@HeikoSi dont know if that breaks independence somehow14:44
@HeikoSso the other way would be to have a unique sampler instance per job14:45
@HeikoSrandom would be best :)14:45
lambdayhow does it get to know about the coloring?14:45
lambdayone sampler instance per color14:45
@HeikoSlambday: we could for example pass the index in the loop or something14:46
@HeikoSargh, random, I want random to work :D14:46
@HeikoSthat would be best14:46
@HeikoSthen we have one single sampler instance14:46
@HeikoSand the jobs just call it wiuthin compute14:46
@HeikoSand the thing just samples from a random colour14:46
lambdaybut that may make s1^T * (log(C)* s2)14:47
lambdays1=/=s214:47
@HeikoSah yes14:47
lambday:'(14:48
@HeikoSok then, lets move the vector-vector to the job14:48
@HeikoSmight be a good idea anyway14:48
@HeikoSthen the function returns a scalar14:48
lambdayno aggregate?14:48
lambdaywhat should we do then for direct solvers?14:49
@HeikoSwell yes14:50
@HeikoSagregate computes the average14:50
lambdayhow about two types of jobs14:50
lambdayhmm14:50
@HeikoSI would like to avoid having different interfaces for the samplers14:50
@HeikoSsince then different interfaces for the jobs14:50
@HeikoSand everythign gets more complicated14:50
@HeikoSdont you like s^T f(C) s ?14:51
@HeikoSits a standard form14:51
lambday:D14:51
@HeikoSthe other one is slightly more general but the above one is the one thats relevant for practice?14:51
@HeikoS!14:51
lambdayokay14:51
@HeikoSIll write daniel a mail, just a sec14:51
lambdayokay14:52
lambdayI'm then figuring out the classes that should be fine with the new design14:52
@HeikoSlambday: there might be another issue :(14:54
lambdaynoooooooooo :(14:55
@HeikoSs^T f(C) s14:55
lambdaywhat's that? :(14:55
@HeikoShas one sample14:55
@HeikoSs^T log(C) s14:55
@HeikoSbut14:55
@HeikoSthere might be multiple jobs14:55
@HeikoSif we do the family of shifted systems, thats fine - only one job14:56
@HeikoSbut if we solve all systems of the raional approx seperately14:56
@HeikoSwe have multiple jobs14:56
lambdayyes that's what I was talking about when I mentioned direct solvers :(14:56
@HeikoSah sorry14:56
lambdayno problem :( but what to do for that case?14:57
@HeikoSone possibility, parametrise the sampler14:58
@HeikoSlike a seed14:59
@HeikoSthat is set before that sample is drawn14:59
@HeikoSthis can be fixed and stored in the job14:59
@HeikoSbut thats quite ugly14:59
lambdayhmmm...15:00
lambdayugly but feasible15:00
@HeikoSoh or this:15:00
@HeikoSdirect solvers are completely unfeasible on one computer15:00
@HeikoSso things need to be sent to a cluster anyway15:00
lambdayclassic!15:00
lambday:D15:00
@HeikoSso what we could do in this case15:00
lambdayoh but then CG solvers are feasible15:01
lambdayone COCG solver per system... not COCG_M15:01
@HeikoSyeah sure, but thats the case15:01
@HeikoSwhat?15:01
@HeikoSI mean COCG_M can be done one one computer15:01
lambdayyes15:01
@HeikoSbut solving all systems with preconditioned CG takes ages15:01
@HeikoSso things would need to be sent to a network anyway15:02
@HeikoSand this means15:02
@HeikoSwe can just store the sample in the job in this case15:02
@HeikoSwe create a dummy sampler, which returns always the same value15:02
@HeikoSthis is done in the rational approximation class, if direct solvers are used15:03
@HeikoSand in the other case, we do this random colour trick15:03
@HeikoSthat should do it no?15:03
lambdayI didn't get the dummy sampler part15:04
iglesiasghi HeikoS!15:04
@HeikoSsince every job now contains a sampler rather than a sample15:04
lambdayoh15:04
@HeikoSwe need to put a fixed sample under that interface15:04
@HeikoSiglesiasg:  hi!15:04
lambdayso, a useless sampler that does nothing15:04
@HeikoSlambday: yes, just to have the interface15:04
lambdayokay15:05
@HeikoSah wait15:05
iglesiasgHeikoS: so it seems you cannot make it for the meeting on Thursday15:05
@HeikoSthere are different job classes for direct solvers and COCG_M right?15:05
@HeikoSiglesiasg: no not that time15:05
iglesiasgHeikoS: I think we should choose that day anyway since it is the most slected one15:05
@HeikoSiglesiasg: it might work, but not sure15:05
iglesiasgHeikoS: aham ok15:05
iglesiasgHeikoS: what time would suit better in any case?15:05
iglesiasg14 and 15 UTC are with the same number of votes15:06
@HeikoSiglesiasg: I am in a cycle holiday from that day, so I  might have a chance to get online in the evening15:06
iglesiasgthat is 16 adn 17 German time I think15:06
@HeikoSbut I cannot guarantee that unfortunately15:06
iglesiasgall right15:06
iglesiasgit will be probably fine anyway15:06
@HeikoSiglesiasg: yes, not a problem15:07
iglesiasg14 UTC then15:07
@HeikoSok I ll try to be there15:07
@HeikoSbut dont wait for me :)15:07
@HeikoSlambday: different classes for these jobs15:07
lambdayyep15:08
lambdayshould be fine I think then15:08
@HeikoScould you send me the current diagram?15:08
lambdayokay15:08
lambdayits the same15:08
lambdaydidn't change anything15:08
lambdaybut sending anyway15:09
lambdayshit man ! I hate this 1GB laptop :'( will buy one with the gsoc money :(15:10
@HeikoSlambday: haha :)15:11
@HeikoSdont worry then15:11
lambdayHeikoS: checking your mail... mailed you the diagram btw15:12
@HeikoSlambday:  thanks15:12
@HeikoSah  nice15:12
@HeikoSso different class15:12
@HeikoSthen just store the vector within there15:12
@HeikoSWe will do this one later anyways15:13
@HeikoSand the COCG_M one gets a sampler15:13
@HeikoSand the probing sampler then (later) will randomly select colour15:13
@HeikoSsee mail (I hope Daniel gives OK)15:13
@HeikoSphew!15:13
@HeikoSgood discussion that started only because of this m_vector.vector=NULL :D15:14
lambdayHeikoS: hahaha! :D good that I tried with this stupid thing :D15:14
@HeikoSCTraceSampler now returns a vector15:14
@HeikoSlambday: not stupid15:14
@HeikoSactually that was quite sensible15:14
lambdayworks though :P15:14
@HeikoSand otherwise we hadnt realised this problem15:14
@HeikoSlambday: ah one more thing15:15
@HeikoSso in order to run into the same problem again upon constructing the jobs15:15
@HeikoS(not being able to store all)15:15
@HeikoSplease submit the jobs to the computation class directly after you created them15:15
@HeikoSso rather than creating a list of jobs, just send them to the computation engine directly and then unreference locally15:16
@HeikoSthis way, they are not stored within the class that create the jobs15:16
-!- iglesiasg [d58f3208@gateway/web/freenode/ip.213.143.50.8] has quit [Quit: Page closed]15:16
lambdaywait let me think15:16
lambdaycurrently, calling generate jobs returns an array of jobs... its the CLogDetEstimator's task to register all of those in the engine15:17
@HeikoSlambday: ah yes, sorry15:17
lambdayand this is done repeatedly for each estimate of the log-det15:17
@HeikoSlet me think15:18
@HeikoSthe operator function class15:18
@HeikoShow many jobs does it create?15:18
lambdaydepends..15:19
@HeikoSon?15:19
lambdayits implementation15:19
@HeikoSit is one per trace sample right?15:19
@HeikoSah no15:19
@HeikoSI mean15:20
@HeikoSoh yes15:20
@HeikoSone per trace sample15:20
lambdayumm...15:20
@HeikoSso the maximum number in our context is the number of shifts?15:20
lambdaybut for preconditioned CG, one per shift too15:20
lambdayyes15:21
lambdayor direct15:21
@HeikoSok, so the point is, not many15:21
@HeikoSah gotta get my charger, just a sec15:22
lambdayokie tyt15:22
lambday(my laptop doesn't run on battery :D as good as a desktop :D, it electricity goes, BAM!)15:22
@HeikoSso about the jobs15:23
lambdayif*15:23
@HeikoSit would be nice not to store many of them locally15:24
lambdayhmm15:24
@HeikoSbut rather directly submit them to the engine, which then can store it somewhere15:24
@HeikoSdepending on its implementation15:24
@HeikoSsee what I mean?15:25
lambdayno.. confused! :(15:25
@HeikoSrather than building an array of jobs and then submit all of those15:25
lambdayyou mean, register directly from the generate jobs?15:25
@HeikoSyes15:26
lambdaythat's cool15:26
lambdayno return for it then15:26
@HeikoSactually, thats really nice15:26
lambdayCLogDetEstimator shouldn't even bother about the jobs at all15:26
@HeikoSwell yes15:26
@HeikoSgetting results15:26
@HeikoSbut thats fine15:27
@HeikoSso the generate_jobs method has another parameter which is the computation engine15:27
lambdayyes15:27
@HeikoSwhenever a job is created in the operator function, it is directly submitted15:27
@HeikoSand then the cool thing is15:27
@HeikoSthe computation engine can have different implementations of what to do15:27
@HeikoSso serial:15:28
@HeikoSthe computation engine does not store the jobs, but rather directly computes them and only stores the result15:28
lambdaymove the engine to the operator instead, but in the log-det.. aggregate result should return the float (vec-vec) product15:28
@HeikoSand parallel can store the jobs (more memory) and then on compute_all() do the computation15:29
@HeikoSpoint is the serial one does not have to store any jobs15:29
@HeikoSso no memory problems15:29
@HeikoScomputation engine would have a different method then, not compute_all, but get_results() which in serial case just returns the results, and in parallel case starts computation15:30
@HeikoSthis way, we can actually store the samples in the jobs15:30
lambdayand you mean, register_jobs should should compute already and store the result... for serial15:30
@HeikoSand the operator function generates the sample15:30
lambdaywe should change the name then15:31
@HeikoSjep15:31
@HeikoSits like thread stuff15:31
@HeikoSjoin etc15:31
@HeikoSwait to be completed15:31
@HeikoSin fact, all computation classes can start computing things once the first job is registered15:31
@HeikoSdepdning15:32
@HeikoSthe good thing is that we can then store the sample in the jobs15:33
@HeikoSsince jobs are not stored all at once15:33
@HeikoSsample is then created in the operator function class15:34
@HeikoSoh wow, actually this even simplifies things more15:35
@HeikoSCOperatorFunction gets a vecor as parameter15:36
lambdaydoes it? :(15:36
lambdayokay15:36
@HeikoSbut CLogDetEstimator samples the probing vectors15:36
@HeikoSand it *knows* the colours15:36
@HeikoStherefore, no random selection of colours15:36
lambdaywhy you wanna give the vector to the COperatorFunction?15:36
@HeikoSCLotDetEstimator samples the trace vectors one by on15:36
@HeikoSand for each of them has to compute s^T f(C) s15:37
@HeikoSso its calls some method on operator function15:37
@HeikoSand passes the sample15:37
@HeikoSCOperatorFunction then constructs some jobs and submits them to the engine15:37
@HeikoSthe engine however blocks until some jobs are completed (either one or many)15:38
@HeikoSits like a queue that gets filled15:38
@HeikoSonce full, it blocks until more space is available15:38
@HeikoSat some point, all jobs are submitted/computed15:39
@HeikoSCLotDetEstimator continues in its loop15:39
@HeikoSonce completed, it asks the computation engine for results15:40
@HeikoSthe computation engine blocks until all results are ready15:40
@HeikoSand then returns them15:40
@HeikoSCLogDet averages over them15:40
@HeikoSwe could even give each job a callback function that is called with results once a result is done15:41
@HeikoSthen we dont have to store the results15:41
@HeikoSbut later15:41
@HeikoSlambday: sorry for the confusion, but I think this way it might be way more efficient15:42
lambdaygenering job and computing job will go parallel then15:42
lambdayHeikoS: its okay.. it sounds better15:42
@HeikoSevery class that generates jobs will directly submit them15:42
@HeikoSone by one15:42
@HeikoSrather than storing /returning them15:42
lambdayyes15:42
@HeikoSthis way we can store stuff in the jobs (as trace vectors)15:43
@HeikoSand the computation engine has a method submit15:44
@HeikoSwhich takes a job, adds it to an internal queue, starts computing it, and blocks if the queue is full15:44
@HeikoS(serial just calls compute in same thread, so dont worry about other things for now=15:44
@HeikoS)15:44
lambdayhow we're gonna implement that thing? blocking/15:45
@HeikoSjust call compute method of job15:45
@HeikoStakes some time15:45
@HeikoSthen one more change:15:45
@HeikoSrather than producing an instance for a job result15:46
@HeikoSwe have a new class that is responsible for handling job results15:46
@HeikoSthis class has a method which takes a job result instance15:46
@HeikoSand does something with it (i.e. store if feasible, or update some internal result)15:46
@HeikoSlambday:  the idea here is again that we do not have to store things.15:47
lambdaycould you please update the class diagram with what you have in mind? :( I'm again forgetting things :(15:48
@HeikoSlambday: sure will do15:49
lambdayHeikoS: when do we compute the vec-vec product in this new design?15:50
@HeikoSlambday: we can choose15:50
lambdaywhere*15:50
@HeikoSeither in the OperatorFunction class15:50
@HeikoSor inthe LogDet15:50
@HeikoSah no15:50
@HeikoSit has to be OperatorFunction15:51
lambdayyep15:51
lambdaysince that gets the vector, right?15:51
@HeikoSyes15:51
@HeikoSalso otherwise, we could not aggregate results that easily15:51
@HeikoSand had to store the vectors once again15:51
@HeikoSthis way, each job returns a float15:52
lambdayyup15:52
@HeikoSof which we can do a running average15:52
@HeikoSor store them (floats are small :)15:52
lambdaybetter :)15:52
@HeikoScallbacks for the results might be useful later though15:53
@HeikoSimagine the result is a matrix15:53
@HeikoSand you later want to do the lement wise average of many matrices15:53
@HeikoSimpossible to store all them15:53
@HeikoSanyway15:53
lambdayhmm.. we should keep that in the design15:54
@HeikoScan do that15:54
@HeikoSnow that we dont store jobs anymore15:55
@HeikoSthe computation class needs to call a function on a single job's result directly after having computed it15:55
@HeikoSthen it can forget about job and result since anotoher class takes care of it15:55
lambdaywhat will that function do?15:56
lambdayfor our COCG_M for instance15:57
lambdaysingle job's result is a vec15:57
@HeikoScan the jobs compute s^T SYSTEM s ?16:00
@HeikoSI thnk they can16:01
@HeikoSsince the solution of every system A^(-1) x is a vector which has to be multiplied with x aferwards right?16:01
@HeikoSlambday: do you agree?16:02
lambdayya but what about the case when we solve each for each shift/16:02
lambdaythat's also a vector but need to be summed up16:02
lambdaybefore the dot product16:03
@HeikoSno difference16:03
@HeikoSa(b+c+d)a = aba + aca + ada16:03
lambdayargh!! yes you're right16:04
lambdaysorry16:04
@HeikoSlambday: no I didnt actually think of that before you mentioned it :D16:04
@HeikoSin both cases we can just sum up the scalars returned by the jobs16:05
@HeikoSfor COCG_M its only one scalar16:05
lambdaysuper cool!!!16:05
@HeikoSfor direct solvers, its a sum16:05
@HeikoSquite a few changes16:06
@HeikoSIll update the class diagram16:06
lambdayfor the whole thing its a sum over a number of scalars.. so no aggregation needed16:06
@HeikoSlambday: yes16:06
@HeikoSespecially no storage of vectors16:06
lambdayaaaah classic!!16:06
lambdayyou rock!!16:06
@HeikoShaha, lambday well you designed it with me, so you rock too! :)16:07
lambdaylol I only tried stupid things and questions - you came up with all the ideas :D16:07
lambdayI'm feeling a little sad for my code though :( but this wouldn't have come up if I wouldn't have tried it.. so its better I guess16:08
@HeikoSlambday: yes thats always annyoing to have code lost16:09
@HeikoSteaches us to even spend more time with planning16:09
lambdayHeikoS: please also write a few lines in the mail too.. why - that's clear but its the "what" that I'm fond of forgetting :(16:10
lambdayHeikoS: ya.. well official GSoC hasn't started yet, so not that bad.. its just 1 week I've been coding on this16:10
lambday:D16:10
@HeikoSlambday: some things will be re-used16:10
lambdayyes16:11
lambdayI'16:11
lambdayI'll think about it16:11
lambday(as much copy-paste as I can :D )16:11
@HeikoSyep16:11
@HeikoS :D16:11
lambdayI'm bookmarking that page btw.. will show it to my friends :D hehe16:12
@HeikoSlambday: wait until its on the UCL website :D16:15
lambdayHeikoS: hehe :D16:15
lambdayHeikoS: I'll be back after my brunchnner :-/17:10
@HeikoSlambday: currently writing you an email17:10
@HeikoSleaving afterwards17:10
lambdayHeikoS: okay then I'm here till then...17:10
@HeikoSlambday:  sent17:14
@HeikoSmaybe read and tell me if you have questions17:14
lambdayHeikoS: checking17:14
lambdayHeikoS: oh so CLogDetEstimator will use the aggregators... which will have the results stored in them once the engine returns the "wait_for_all()"17:31
lambdayand get that result from that aggregator (float in this case) and do the sum17:32
@HeikoSyes17:32
@HeikoSlambday: let me know if there are any problems, I have to go now, but will check mail later17:32
-!- HeikoS [~heiko@176.248.212.166] has quit [Quit: Leaving.]17:32
-!- lambday [67157f4c@gateway/web/freenode/ip.103.21.127.76] has quit []17:33
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun19:09
-!- nube [~rho@49.244.57.163] has quit [Ping timeout: 256 seconds]19:11
-!- nube [~rho@49.244.22.151] has joined #shogun19:25
@sonney2kwiking, what did you mean by that?19:43
@sonney2kand lisitsyn where are you stuck?19:46
lisitsynsonney2k: I am stuck with the structure of CMakeLists there19:46
@sonney2klisitsyn, then talk to wiking about it19:47
lisitsynyes good idea ;)19:47
lisitsynsonney2k: I actually need your help too19:47
lisitsynsonney2k: Makefile.template looks very entangled to me19:48
@sonney2klisitsyn, Makefile.template is used to generate the makefile for each interface19:49
lisitsynsonney2k: that's clear19:49
@sonney2kthen what is not?19:49
lisitsynsonney2k: I don't get what is say exact CXX line for cmdline_interface19:50
@sonney2k?19:50
@sonney2kno idea what you mean19:51
lisitsynsonney2k: nevermind I think I got it for cmdline19:51
lisitsynnot for octave/matlab though19:51
@sonney2kwhat did you not get?19:52
lisitsynsonney2k: I don't get what are the steps to compile it19:52
@sonney2kcompile libshogun19:52
@sonney2kthen the matlab part19:53
@sonney2kand then link to libshogun with the matlab object files19:53
lisitsynsonney2k: where can I find these last two steps?19:55
gsomixsonney2k, good evening. have a minute? PR is updated. https://github.com/shogun-toolbox/shogun/pull/113019:56
@sonney2klisitsyn, $(TEMPLATE_TARGET): .depend $(OBJFILES) $(SRCFILES) $(HEADERFILES) $(OTHERDEPS)19:57
@sonney2k    @echo 'Linking object files'19:57
@sonney2k    @$(LINK) $(PRELINKFLAGS) $(shell find $(SRCDIR) -name "*.$(EXT_OBJ_CPP)" -o \19:57
@sonney2k        -name "*.$(EXT_OBJ_C)" 2>/dev/null) $(LINKFLAGS) -o $@ $(POSTLINKFLAGS)19:57
lisitsynsonney2k: :D yeah here I am stucked19:57
@sonney2kthe POSTLINKCMD was just necessary for running shogun on gunnars iphone19:57
gsomixsonney2k, btw, I think that there is needed another class for splitting strings, instead CircularBuffer::find_char(char delimiter[256]).19:59
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Read error: Connection reset by peer]19:59
@sonney2klisitsyn, well compiling happens in the implicit rule %.$(EXT_OBJ_CPP):   %.$(EXT_SRC_CPP)19:59
@sonney2kso you have all .cpp -> cpp.o19:59
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has joined #shogun20:00
@sonney2kand then the find just finds all *.cpp.o and links them together into $(TEMPLATE_TARGET)20:00
@sonney2kwhich whould be sg.oct for octave20:00
lisitsynsonney2k: alright that explains something20:04
lisitsynthnaks20:04
lisitsynwiking: ping20:26
lisitsynwiking: we've got to give user ability to disable python modular20:33
lisitsyn;)20:33
-!- nube [~rho@49.244.22.151] has quit [Quit: Leaving.]20:33
-!- HeikoS [~heiko@176.248.212.166] has joined #shogun20:34
-!- mode/#shogun [+o HeikoS] by ChanServ20:34
votjakovrHeikoS: hi! I've sent a PR with some fixes. Please look at it20:46
@HeikoSvotjakovr: hi!20:46
@HeikoSjust started looking at it 5 mins ago :)20:46
@HeikoSvotjakovr: I see you saw the note on the error messages, sorry for pushing you in the other direction before20:47
@HeikoSbut this way its way easier20:47
@HeikoSvotjakovr: there is another *very* nice publication about GPs for classification20:49
votjakovrHeikoS: ah, all right. btw now posterior paramereter are evaluated "lazy"20:49
@HeikoSits not yet published so please dont spread it, but Ill send it to you anyways, might be interesting for some post GSoC work20:50
@HeikoSvotjakovr: thats totally fine20:50
@HeikoSvotjakovr: for these combined features cases, why is only the first element checked?20:51
lisitsynHeikoS: secret ops20:52
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun20:52
shogun-notifier-shogun: Roman Votyakov :develop * b8b2e6f / src/shogun/regression/gp/ (6 files): https://github.com/shogun-toolbox/shogun/commit/b8b2e6f9cf99a1055429945f5d0ef309dfcba9c120:52
shogun-notifier-shogun: Fixed recomputing of posterior parameters20:52
shogun-notifier-shogun: Heiko Strathmann :develop * a640e47 / src/shogun/regression/gp/ (6 files): https://github.com/shogun-toolbox/shogun/commit/a640e473fae1e5e608457e2d0a5cc242c8ca53a720:52
shogun-notifier-shogun: Merge pull request #1170 from votjakovr/develop20:52
shogun-notifier-shogun:20:52
shogun-notifier-shogun: Fixed recomputing of posterior parameters20:52
@HeikoSvotjakovr: nice, work!20:52
votjakovrHeikoS: thanks :)20:53
@HeikoSvotjakovr: say, could you make the laplace approximation in such way that we can sample from it?20:53
@HeikoSi.e. make the cholesky available from outside20:53
@HeikoSor is that already possible?20:53
@HeikoSI really want to integrate this pseudo-marginal stuff at some point and for that we need to be able to sample from the approximate posterior distributions (Laplace, also EP)20:54
votjakovrHeikoS: do you mean posterior cholesky?20:55
@HeikoSvotjakovr: yes the cholesky of the Gaussian approximation to the posterior20:55
@HeikoSvotjakovr: ah its already there20:56
votjakovrHeikoS: so get_cholesky() is the public method of Laplacian inference20:56
@HeikoSvotjakovr: yep, I see, nice20:57
@HeikoSvotjakovr: whats next?20:57
votjakovrHeikoS: are you working on mcmc stuff?20:57
@HeikoSvotjakovr: yes a bit20:57
@HeikoSI actually wanted to write this paper that I sent you20:58
@HeikoSbut out of time ;)20:58
votjakovrHeikoS: great :)20:58
@HeikoSso mark and this other guy did it20:58
@HeikoS votjakovr, are you interested in that stuff=?20:58
shogun-buildbotbuild #940 of cyg1 - libshogun is complete: Failure [failed configure]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/940  blamelist: Heiko Strathmann <heiko.strathmann@gmail.com>20:58
votjakovrHeikoS: mcmc?20:59
@HeikoSyes20:59
@HeikoSvotjakovr: about the cholesky21:00
@HeikoSI want to be able to sample from the Laplace approxiation21:01
@HeikoSso need a way to get its covariance factor and its mean21:01
@HeikoSget_cholesky does not do that21:01
@HeikoSvotjakovr: do you have the GP book?21:03
@HeikoScheck expression 3.2021:03
@HeikoSwe need the cholesky of that Gaussian to sample from it21:04
@HeikoSso need the cholesky of matrix 3.2721:05
@HeikoSvotjakovr: but maybe lets do that a bit later, just keep it in mind21:06
@HeikoSvotjakovr: we should really soon start with the classification stuff as GSoC begins on Monday21:06
@HeikoSso high priority is to seperate regression and GP so that the GP class can be used for classification21:07
@HeikoSI suggest we start with logit/Laplace21:07
@HeikoSvotjakovr: what do you think?21:07
shogun-buildbotbuild #941 of cyg1 - libshogun is complete: Failure [failed configure]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/941  blamelist: Roman Votyakov <votjakovr@gmail.com>21:07
-!- lisitsyn [~lisitsyn@109-226-90-135.clients.tlt.100megabit.ru] has quit [Quit: Leaving.]21:08
-!- lisitsyn [~lisitsyn@109-226-90-135.clients.tlt.100megabit.ru] has joined #shogun21:08
votjakovrHeikoS: Ah, yep.. I've already started drawing diagrams21:08
@HeikoSvotjakovr:  nice!21:08
@HeikoSany particular thoughts?21:09
votjakovrHeikoS: not yet, i've just drew an existing part21:12
@HeikoSvotjakovr: what kind of interfaces should the classifier have?21:14
@HeikoSI think it might be good to do all those in the shogun style21:15
@HeikoSreturning regression/binary/multiclass labels depending on the GP type21:15
votjakovrHeiko'S: maybe it could be derived from CMachine?21:17
votjakovrHeikoS: Btw why do we need a general GPs class?21:18
@HeikoSvotjakovr: so there are two ways to go:21:19
@HeikoSfirst: GP an own thing, all methods are derived from the GPRegression class21:19
@HeikoSHowever, we can also do classification problems - I am a little afraid here that users might be confused21:20
@HeikoSwhen we mix regression/classification21:20
@HeikoSthe basics are the same (prior, likelihood etc)21:20
@HeikoSwhing brings us to the second way:21:21
@HeikoShave a GP base class, and inherit from it for regression and classification21:21
@HeikoSwhere each of those has shogun-like interfaces21:21
@HeikoSI would rename the apply_regression method to21:22
@HeikoSCLabels* apply(...)21:22
@HeikoSand add some distinction for classification problems21:23
@HeikoSso we could have GPRegression which only accepts regression based inference method (and data)21:24
@HeikoSand a GPClassification which only accepts classification based methods21:24
@HeikoSthis one could have a subclass for multiclass21:24
@HeikoSvotjakovr: or dont you agree?21:24
-!- pickle27 [~Kevin@S0106002191dec7e8.cg.shawcable.net] has joined #shogun21:25
@HeikoSvotjakovr: another problem might be that some of the code in the current GP class is not suitable for classification21:26
votjakovrHeikoS: yep, i agree.21:27
@HeikoSbtw GP class is already derived from CMachine21:28
votjakovrHeikoS: current GP regression is derived from CMachine21:28
@HeikoSyep :)21:28
votjakovrHeikoS: So may be it's good to use CMachine interface for classification too?21:29
@HeikoSvotjakovr: yep I think I would have a GP base class which inherits from CMachine, and then two subclasses for regression/classification21:29
votjakovrHeikoS: I totally agree! :)21:29
@HeikoSand multiclass is an extension of binary21:29
@HeikoSbut that later21:30
@HeikoSso the whole feature storage and also mean and covariance functions can be done in the base class21:30
@HeikoSvotjakovr: chech Machine.h21:31
@HeikoSthere are all these apply functions21:31
@HeikoSwe just override those21:31
@HeikoSin the GP subclasses21:31
votjakovrHeikoS: yep, shure21:31
@HeikoSand use CMachine's apply21:31
@HeikoSas its done now only for regression21:32
@HeikoSso btw21:35
@HeikoSmean vectors and covariance vectors also only apply to gp regression21:35
@HeikoSbinary classification gets a value in [0,1]21:36
@HeikoSand multiclass gets a vector with [0,1] values for every class21:36
@HeikoSso that can also go in subclasses21:36
@HeikoSvotjakovr: do you  need help defining these new classes?21:37
@HeikoSor a class diagram to make clear what I mean?21:38
@HeikoSlisitsyn: the secret ops paper btw beats all other classification methods21:38
@HeikoSreally cool21:38
lisitsynHeikoS: the paper of who?21:38
shogun-buildbotbuild #468 of ubu1 - libshogun is complete: Success [build successful]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/46821:38
@HeikoSsome stats guys from glasgow/london21:39
@HeikoSon small datasets21:39
lisitsynHeikoS: and what is the data? ;)21:39
@HeikoSsome toy examples compared against other std approaches21:39
lisitsynI see21:39
@HeikoSlisitsyn: so they fully integrate out all model hyperparameters (i,e, kernel -parameters)21:39
@HeikoSso they take all possibilities into account21:40
@HeikoSgiven the data21:40
@HeikoSwill be good to have this stuff in shogun :)21:40
lisitsynwiking: i see our install puts CMakeFiles/ too21:42
@HeikoSvotjakovr: I gotta go now, let me know if you need any help. We should get this done until at latest tuesday21:42
@HeikoSso that we can start on the classification stuff21:42
votjakovrHeikoS: i think it's better to discuss it after i finish drawing of diagrams. But i think, i21:42
@HeikoSvotjakovr: ok, please share them once they are almost complete (no need to be perfect on them, its just for discussions)21:43
votjakovrHeikoS: i think, i understand your idea21:43
@HeikoSvotjakovr: cool then,21:43
@HeikoSwhat are you using to draw them?21:43
votjakovrHeikoS: emacs21:44
@HeikoSemacs?21:44
@HeikoSfor class diagrams?21:44
votjakovrHeikoS: yep :)21:44
votjakovrHeikoS: it sounds a bit crazy)21:44
@HeikoSvotjakovr: haha indeed :D21:44
@HeikoScan you show how they look like?21:45
@HeikoSah man21:45
@HeikoSis it this ditaa?21:45
@HeikoSvotjakovr: maybe have a look at dia, things are way easier/faster to do in there -- although I appreciate the hacker style diagrams ;)21:46
@HeikoSvotjakovr: ok gotta go now21:47
@HeikoSsee you!21:47
votjakovrHeikoS: see you :)21:48
-!- pickle27 [~Kevin@S0106002191dec7e8.cg.shawcable.net] has quit [Quit: Leaving]21:48
-!- iglesiasg [d58f323e@gateway/web/freenode/ip.213.143.50.62] has joined #shogun22:25
-!- mode/#shogun [+o iglesiasg] by ChanServ22:25
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has left #shogun ["ERC Version 5.3 (IRC client for Emacs)"]22:27
-!- pickle27 [~Kevin@S0106002191dec7e8.cg.shawcable.net] has joined #shogun22:40
lisitsynpickle27: oh I know your ISP!22:44
lisitsynpatched a few things for them :D22:44
pickle27lisitsyn, haha thats hilarious22:55
lisitsynpickle27: I used to work at netcracker and shaw uses their software22:56
pickle27lisitsyn, cool!22:58
pickle27lisitsyn, yeah shaw is actually a pretty good isp22:58
pickle27I wish I could have them back home in Kingston22:58
@iglesiasghaha funny thing in lmnn code22:59
@iglesiasgfprintf('The bizarre error happened!\n');22:59
lisitsyniglesiasg: ohh you look at lmnn code23:05
lisitsynI'll send you flowers!23:05
@iglesiasghaha why?23:06
lisitsyniglesiasg: I died twice reading the code!23:06
lisitsyngood I am a cat you know23:06
lisitsyn9 lives23:06
@iglesiasglisitsyn: ah! hehe23:06
@iglesiasgwere you interested in it?23:06
@iglesiasgthis is LMNN23, a relatively new version23:07
@iglesiasgI think the code is quite ok23:07
lisitsyniglesiasg: yes chris wanted me to port it23:10
@iglesiasgaham23:10
@iglesiasgwhere do you think it would make sense to have it in shogun?23:10
lisitsynmulticlass I guess?23:11
@iglesiasglisitsyn: then as a classifier23:11
lisitsynyes, what else?23:11
@iglesiasglisitsyn: I think it would actually be more flexible if just the linear transformation is returned23:11
lisitsynyou mean LMNN = project + NN?23:12
@iglesiasgone may want to do other thing different from applying NN23:12
lisitsynmakes sense for me if possible23:12
-!- FSCV [~FSCV@189.139.252.135] has joined #shogun23:38
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Ping timeout: 248 seconds]23:45
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]23:52
-!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has joined #shogun23:57
--- Log closed Sun Jun 16 00:00:47 2013