shogun-buildbot n4nd0 n4nd0 --- Log opened Thu Mar 07 00:00:04 2013 -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] 00:02 -!- FSCV_ [~FSCV@173.254.212.46] has quit [Quit: Leaving] 01:03 -!- eduvfsilva [~eduvfsilv@189-25-47-127.user.veloxzone.com.br] has joined #shogun 02:27 build #314 of nightly_default is complete: Failure [failed test]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/314 03:41 -!- eduvfsilva [~eduvfsilv@189-25-47-127.user.veloxzone.com.br] has quit [] 05:45 -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has joined #shogun 06:58 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun 07:53 -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun 08:04 -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has joined #shogun 08:09 -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has quit [Ping timeout: 245 seconds] 09:05 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Ping timeout: 248 seconds] 10:05 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun 10:31 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Quit: leaving] 11:27 -!- blackburn [~blackburn@85.114.170.181] has quit [Quit: Leaving.] 11:29 -!- blackburn [~blackburn@85.114.170.181] has joined #shogun 11:37 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun 11:54 blackburn: indeed, from 0.98 to 0.958 seems a quite large 12:20 I hope float precission is better than that :) 12:20 n4nd0: heiko fixed something about custom kernel - I hope that 12:20 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Quit: leaving] 13:01 -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has quit [Read error: Operation timed out] 13:39 booojaaaah 13:50 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has joined #shogun 13:55 wiking: welcome back 13:57 shitfucky ;) 14:09 and even my ssh is lagging 14:24 wiking: so working on a thesis? 14:25 yeps 14:25 somethinglikethat 14:25 or at least tyring 14:25 *trying 14:25 I see 14:26 wiking: what's the name of your thesis? 14:27 something latent :) ? 14:27 hah I know a few latent gays (I suspect so) 14:27 sorry couldn't resist :D 14:27 :) 14:28 hehe 14:28 nice one 14:28 :) 14:28 wiking: I remember you were curious about t-SNE 14:35 wiking: I arranged with laurens to GPL his Barnes-Hut-SNE and will push it very soon 14:36 \o/ 14:55 woah cool 14:55 -!- FSCV [~FSCV@173.254.212.46] has joined #shogun 15:09 -!- heiko [~heiko@nat-164-89.internal.eduroam.ucl.ac.uk] has joined #shogun 15:25 -!- ashar799 [4e61ecae@gateway/web/freenode/ip.78.97.236.174] has joined #shogun 15:34 -!- n4nd0 [~nando@n145-p185.kthopen.kth.se] has quit [Quit: leaving] 15:38 -!- hoijui [~hoijui@141.23.80.177] has joined #shogun 15:43 Hi I was wondering if there are any plans to incorporate Gaussian Process Latent Variable Model (by Neil Lawrence) and Gaussian Process Dynamical Variable Model (Wang) for Dimensionality reduction 16:49 I am doing my MS thesis on implementing these two models for different data sets 16:50 and have seen that having more Dimensionality reduction techniques is one of the proposals for GSoc 2013 16:52 ashar799: we've got no concrete plans yet but we will consider that too! 17:16 -!- hoijui [~hoijui@141.23.80.177] has quit [Ping timeout: 252 seconds] 17:23 blackburn, wiking, heiko - can any of you reproduce the custom kernel issue? 17:45 (because I dont'...) 17:45 sonney2k: I can't 17:45 sonney2k:  nope 17:45 must be some very old version of shogun 17:45 or even numpy.... 17:45 sonney2k: I suspect she just downloaded and compiled shogun but has an old version installed from the repository or so 17:46 heiko, blackburn because it seems to me that the matrix' values are somehow shuffled in memory 17:46 some kind of fortran/c order issue 17:46 yeah, lets wait for her version :) 17:47 so the 0.958 (that appears in the orginal numpy matrix) is at the wrong position 17:47 popular issue :) 17:47 we had such bug but years ago... 17:47 not even sure blackburn was still around :D 17:47 haha 17:48 hehe :) 17:48 sonney2k: I have two years anniversary soon 17:48 so before the dawn of the ages 17:48 I can hardly remember the time before you were part of the team 17:48 actually same holds for heiko... 17:48 yeah, it has been a while :) 17:49 sonney2k: 2011-03-29 is the day I joined #shogun on a sleepless night to show my broken english 17:49 :D 17:49 sonney2k: blackburn btw I am currently writing my gsoc project description 17:52 nice, I should do the same 17:53 and proposal 17:53 proposal? 17:53 heiko: yes we should make a gsoc proposal 17:55 blackburn: I see :) 17:55 let me know where I can help 17:55 heiko: I'll create google doc for that I think 17:55 good idea 17:55 blackburn:  for the project, I think I will create a pdf since I need some math, and then post the abstract on the page along with the pdf 17:56 heiko: maybe mathjax? 17:56 http://lisitsyn.github.com/tapkee/methods/lle.html like that 17:56 blackburn: agreed! 17:56 sonney2k: heiko: I received 'yes' from laurens - this means we can add t-SNE 17:58 the question is - should I put it to latest shogun before release? 17:58 blackburn: what? :) 17:58 heiko: I was convincing him to GPL his code 17:58 blackburn: I would not add anything right now, better fix bugs :) 17:58 blackburn: Ah nice work! 17:58 heiko: yeah I would do the same 17:58 sonney2k: heiko: question two 18:00 I got jedi macros skills 18:00 ? 18:00 blackburn:  thats good :) I hate macros 18:00 I think I can replace fields of our classes 18:00 and its getters/setters/sgadds 18:00 with just one macro may be 18:00 not for that version of course 18:00 blackburn: example? 18:02 heiko: field(float64_t,width) 18:03 blackburn:  the they got registered automatically? 18:04 yes and getters/setters are generated 18:04 sounds nice 18:04 heiko: or even 18:04 but, also a lot of work 18:04 field(float64_t,width,positive) 18:04 positive? 18:04 yeah, means it will be checked 18:05 to be positive 18:05 heiko: take a look - I did somewhat simplified version of that in tapkee: https://github.com/lisitsyn/tapkee/blob/master/tapkee/tapkee_methods.hpp#L491 18:05 that is cool stuff 18:07 heiko: I have >20 methods with 2-7 parameters each so macroses appeared as the only way to handle this without megaLoC 18:07 blackburn:  but do you think its a good idea to do this for shogun? 18:07 heiko: I don't know - that's why I am asking 18:07 blackburn: I would be afraid that everything will be broken for quite some time 18:08 heiko: yes that's '-' 18:08 and that it is infinite work to apply this to all existing classes 18:09 and that many bugs slip through our fingers 18:09 since these things are usually a bit unpredictable 18:09 also, doesnt it make debugging a bit complicated since you are not reading the code anymore? 18:09 especially when mixed in 18:09 blackburn: you will like this: 18:12 http://googleblog.blogspot.co.uk/2012/06/using-large-scale-brain-simulations-for.html 18:13 heiko: getters/setters is a pure evil 18:16 -!- ashar799 [4e61ecae@gateway/web/freenode/ip.78.97.236.174] has quit [Quit: Page closed] 18:24 heiko: they ~never have bugs 18:26 heiko: and if they have - automagic resolve that 18:26 blackburn: I like the part about reference counting for SGOs :) 18:28 but I am a bit afraid of  this, the code you see will not be the code that the compiler sees anymore 18:29 heiko: that's good I can't see what compiler sees 18:29 I'd really like to not see new/delete and indexes 18:30 it is a great misconception such level means performance 18:31 I hope you don't think so :) 18:31 blackburn: agreed, I hope you know what I meant 18:37 blackburn:  I like the idea 18:37 blackburn: so you think we should move on to a modern language for shogun? :D 18:37 heiko: it is kind of exceptional for me as I never debugged getters and setters 18:38 but they take so much space 18:38 blackburn: true, but sometimes you dont want to have them 18:38 eclipse can do them for you btw 18:38 heiko: no, it is different 18:38 generating and code folding is a halfway 18:39 heiko: well modern language is C++ 18:40 I see no other alternative :) 18:41 even if I had resources to translate all the code - no idea which language could it be 18:41 same 18:41 probably google-go :D 18:41 or my favourite: brainfuck 18:42 heiko: shakespeare 18:42 haha :) 18:43 heiko: last year we were thinking about chef interface 18:44 chef? 18:44 heiko: yeah there is a language 18:44 i see 18:44 btw interfaces: 18:44 blackburn: matlab is the most important one and it is static only 18:45 that is a shame 18:45 http://www.dangermouse.net/esoteric/chef.html heiko 18:45 so much potential lost 18:45 We should have a gsoc project to implement matlab for swig 18:45 heiko: I have nothing to say about that :) we should push it in swig 18:45 (and shogun afterwards) 18:45 same with R 18:45 but I guess matlab is quite shitty in that sense 18:45 Matlab and R are the main languages used by the people who could use shogun 18:46 blackburn:  really? 18:46 I think it should be ok, the new matlab has object orientation and everything 18:46 heiko: I guess SWIG people just can't get some required info 18:46 proprietary stuff 18:46 blackburn: reading a bit through the mailing lists, I understood that just nobody is doing it 18:46 really? I see 18:47 there even was a student who did his project on this 18:47 but sonney2k should know more about this 18:47 heiko: there is a SwigJS, huh! 18:49 heiko: I understand matlab is important but I do not know how to proceed 18:56 blackburn: same, I hoped maybe sonney2k has an idea 18:56 there also was this MSC project 18:56 let me find the link 18:56 initial code 18:57 https://github.com/twiho/Matlab-in-SWIG 18:57 thesis 1 18:57 http://is.muni.cz/th/256412/fi_b/thesis.pdf 18:57 thesis 2 18:57 http://is.muni.cz/th/256594/fi_m/thesis.pdf 18:57 blackburn: that is a lot of stuff to start with :) 18:57 heiko: it doesn't sound like a something easy 18:58 we should discuss it with swig guys 18:58 blackburn:  indeed 19:05 -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has joined #shogun 19:05 blackburn:  would be so good to have 19:05 blackburn: you once mentioned something about openmp? 19:06 heiko: well, yes 19:06 or was that openmpi? 19:07 heiko: no, openmpi is not really interesting for me 19:07 it is just implementation :) 19:07 of mpi standard 19:07 my question is: 19:07 if I have some parts of my algorithm that should be parallelised 19:07 and the number of parallel parts is large 19:07 is there anything I can do in shogun=? 19:08 heiko: pthreads is our traditional way 19:08 but pthreads is restricted to one computer 19:08 blackburn: do you have any idea how hard it would be to add the possibility that these "threads" are distributed within a cluster of computers? 19:09 heiko: MPI is the only way to do that 19:10 blackburn:  have you used that? 19:10 yes 19:10 blackburn: tell me your feelings about it 19:10 heiko: w/o some additional routines to send/recv messages I think the code would look like a mess 19:11 ok 19:11 heiko: the thing I am mostly worried is that I am totally unsure it is possible to use SWIG+MPI 19:12 so thats not a good idea 19:12 blackburn: its just: parallelisation is fine. But if one wants to do somethign really large scale, one needs more than one computer 19:12 heiko: actually we should transform to client/server 19:12 blackburn: maybe shogun is not the right boat for this 19:13 I think it would be awesome 19:13 also most methods inside shogun dont really scale 19:13 heiko: bindings could stay but creating SVM would be to send a packet over a network 19:13 blackburn:  I see 19:14 and then master shogun could create workers on cluster machines 19:14 so you want to create kind of stub objects 19:14 yes 19:14 I feel 'eureka' in my head now 19:14 I didn't think about that in that mean before 19:14 which methods could use this? 19:14 svm certainly not :) 19:14 heiko: well it doesn't mean we should always work on cluster 19:15 if method supports that thing - run it on cluster 19:15 yeah that would be sexy 19:15 heiko: even shogun name makes a lot of sense now for me :D 19:15 so in the code, you just allocate workers 19:15 as if shogun takes the rule of workers 19:15 and they are either distributed automatically, or executed locally 19:16 yes 19:16 shogun server + shogun bindings 19:16 blackburn: that should not be too hard to implement in fact 19:16 they are loose coupled over a network 19:16 uh 19:17 heiko: isn't that a great idea? I get driven by it 19:17 blackburn: yeah, I just wonder whether there is no framework for this, since it has certainly been done before 19:17 heiko: framework for what exactly? 19:17 this structure 19:18 of allocating workers 19:18 for your tasks 19:18 heiko: MPI/MapReduce :) 19:18 a lot of 19:18 I believe it should be generalized 19:18 yes, this is what I mean, why not use MPI? 19:19 heiko: I didn't say we shouldn't use MPI 19:19 shogun client (bindings) <-> shogun server <-> MPI backend 19:19 OR 19:20 shogun client (bindings) <-> shogun server <-> map reduce backend 19:20 anything you like :D 19:20 hmm should I left my job and do that ? :D 19:20 blackburn: haha :) 19:20 blackburn: so say we had that working. Which methods would be able to properly use it? 19:20 heiko: I do not know about machine learning 19:21 blackburn: my linear time MMD would, it is X times faster for X additional workers 19:21 but apart from that? 19:21 but I realize it could be a great framework 19:21 if I implemented statistics stuff then this would also be great 19:21 heiko: even having everything in one worker *with capabilities* of doing that cluster later is just great 19:22 heiko: algorithms will come I think 19:22 blackburn: thats true, but also very easy to achieve without the need to mess around with client/server/mpi stuff 19:22 heiko: with your own boilerplate code? 19:23 it is not a solution 19:23 I run stuff on clusters all the time, thats very easy if you just use one process 19:23 just upload program, write a 5 line allocation script and submit 19:23 I agree it would be easier with a framework, but not that much that its worth to put all the effort into that 19:24 heiko: ha! 19:24 But I really like the idea anyway 19:24 it is worth as some things are impossibru 19:24 since you are right: algorithms can come then once this exists 19:24 you can't make MMD faster now, right? 19:24 what do you mean? 19:24 heiko: with cluster 19:25 with the shogun implementation, no 19:25 you'd be able to do that with proper framework 19:25 yes 19:25 thats why I asked, which methods would benefit 19:25 since MMD is not so important for practical problems :D 19:25 heiko: main thing - you can write your script on your laptop but run somewhere else 19:25 blackburn: agreed 19:26 so how would this work 19:26 heiko: just stubs 19:26 I have some interface class to the server 19:26 and I can submit workers 19:26 which have an interface to start/stop/result/bla 19:26 you don't care about workers 19:26 you mean internally? 19:27 yes 19:27 from implementation side of view 19:27 yeah something like that 19:27 and with that I can implement my new SVM 19:27 for example 19:27 lets say multiclass svm 19:27 with one against all 19:27 you define how workers should act 19:27 and how data should be distributed 19:27 so I package all the different problems into one worker and submit 19:28 wait 19:28 and return locally 19:28 and the server distributs them on any kind of machine 19:28 why one worker? 19:28 either with shared memory or completely separate 19:29 yeah 19:29 no each problem into one worker 19:29 each classification task of the many 19:29 heiko: if we go crazy it could be even heterogeneous in means of technology 19:29 heiko, blackburn about interfaces & swig... 19:29 5 MPI workers and some MapReduce farm and a GPU here 19:29 blackburn: that would be certainly crazy :D 19:30 heiko: it sounds like a crazy dream but 19:30 the issue I am having with swig & R is that the refcounting doesn't work 19:30 which means one gets crashes or memory leaks 19:30 heiko: imagine speedups you can get 19:30 sonney2k: yeah I know about R 19:30 sonney2k: I see, what do the swig people say to that? 19:30 sonney2k: the main concern is matlab 19:30 blackburn, so this would be like matlab's parfor, even cooler would be if the workers could communicate, but maybe this is a bit too much for now. even the independent jobs on a cluster would help massively 19:31 heiko: no they *should* be able to communicate from the very beginning 19:31 heiko, I reported that 2(3?) years ago but this one R maintainer did not really care. we would need to craft a minimal example showing the problem 19:31 blackburn, mine is not matlab is *crap* 19:32 I can easily live w/o matlab 19:32 use octave 19:32 same syntax same everything 19:32 and blackburn what you are describing is e.g. http://graphlab.org/ 19:32 sonney2k: I agree, but we would reach a much bigger audience with a modular matlab binding 19:33 sonney2k: haha 19:34 sonney2k: invented a wheel again 19:34 heiko, I don't see a problem doing it (no more than doing that for octave) but it needs someone with deep swig skills. if you look at the mailinglist archive of swig you would see that there was a guy Xavier sth (who wrote the octave bindings) with whom I tried to start this maybe 4-5 years back 19:35 but then he left (also no longer maintaining the octave part) 19:35 sonney2k: I see 19:35 sonney2k: well graphlab with language bindings :D 19:36 heiko, I understand that some researchers still use matlab but that is not really my focus any longer at least 19:36 haven't been using matlab for years and I am much happier with python ... 19:37 it is fast has tons of bindings and free software 19:37 sonney2k: researchers are lame with real programming languages for some reason 19:38 sonney2k: I like python too, but I cannot send it to people. 19:38 sonney2k: even worse, the number of people who are using mac grows like crazy here 19:38 heiko: why? mac is ok for me 19:39 well I never used it :D 19:39 heiko, but python and osx go well together 19:39 sonney2k: blackburn:  about that parallel thing. graphlab has its focus a bit different. I think having some kind of independent parallel engine would be really helpful 19:39 sonney2k: idea is: objects in our bindings become stubs to represent objects in the serverspace 19:40 sonney2k: I really dont want to get into this python-matlab or X-Y discussion, I just think it would be great to properly support it. But it seems tricky 19:41 server could run it as is or with some other backend 19:41 blackburn, the issue with going massively parallel is that I don't have access to such cluster park 19:41 sonney2k: I'd like to keep this idea in mind and implement and prototype 19:41 and then see if it is nice 19:41 blackburn: maybe we could have a separate branch or so 19:42 no 19:42 well client part yes 19:42 :) 19:42 but server-side should be from the blank I am afraid 19:42 so? 19:43 blackburn, well I am stuck on many core machines 19:43 okay my idea - I will try to implement the whole stack 19:43 with one distributable algorithm 19:43 but it would take months I think 19:43 sonney2k: we don't use either multicore or cluster machines 19:44 blackburn, I dont know whether this should be so massive due to the lack of algorithms that exploit this 19:44 I think if we had something that could handle independent jobs, this would help a lot 19:44 heiko: jobs should not really be independent 19:44 they should be independent as possible 19:45 heiko, yeah sure I understand. I don't care about matlab though and it is >5 years since I've seen a really talented guy with whom one could have done this within 1-2 months 19:45 and I don't have the time nor will to do it 19:45 if at some point swig perfectly supports R / matlab we can easily switch to using it 19:46 sonney2k: do you know the swig people? 19:46 well? 19:46 the only question that remains is what do we do with all the static interfaces? 19:46 maybe we could push them to do something in gsoc 19:46 heiko, not well enough 19:46 I met some of them at gsoc mentor summit 19:46 what are their current goals? 19:47 heiko, no idea 19:47 heiko, they just switched over to using github 19:47 oh finally :D 19:47 sonney2k: I saw that  :) 19:48 https://github.com/swig 19:48 (and git) 19:48 I see no reason to use anything else 19:48 they were on svn for years 19:48 gsoc 2012 had a new module for java script 19:49 so heiko blackburn - what do we do with the static interfaces? 19:49 https://dl.dropbox.com/u/10139213/shogun/tsne.png t-sne unrolls swissroll in a strange way :D 19:49 these are becoming more and more obsolete... 19:49 sonney2k: I dont know, I never added something until shortly. Wanted to add some MMD stuff and found it rather painful 19:50 sonney2k: drop :D 19:50 l 19:50 and the danger is that people think this is shogun 19:50 I mean all shogun can do 19:50 haha yeah 19:50 blackburn, yeah I would love to drop them 19:50 is sg('set_shit') 19:50 or at least hide them 19:50 sonney2k: hide 19:50 many people are using shogun as an libsvm interface 19:50 from matlab/R 19:50 so there will be no (documented) configure option 19:50 sonney2k: could we separate them to another project? 19:50 blackburn, yes sure 19:50 then lets do it this way 19:51 heiko, but libsvm has a matlab interface too 19:51 sonney2k: 'sorry we can't support it, it is an outdated project' 19:51 haha shogun as a libsvm interface, really? 19:51 sonney2k: I know, but there are not all those kernels right? 19:51 hehe! 19:52 heiko: if they are still willing to use it this way we just tell them to install that different thing 19:52 blackburn: sonney2k agreed! 19:53 sonney2k: blackburn, btw I will probably soon implement a little module into graphlab, and I am thinking of linking against shogun for kernel/feature implementations 19:53 heiko, why not 19:54 heiko, blackburn - we should release shogun 2.1 19:54 hah sure 19:54 too bad wiking didn't push it :( 19:55 sonney2k: have you seen this mkl bug? 19:55 heiko, ? 19:56 I updated the issue 19:56 added an example 19:56 to reproduce 19:56 sonney2k: blackburn what is missing for 2.1? 19:56 apart from removing warnings? 19:56 heiko: I am working on tapkee still.. no idea where to stop 19:57 blackburn: just stop adding new things :) 19:57 I can't 19:57 heiko: chris added 'including more recent' algorithms to the paper 19:57 and I had to add a new algorithm because of that 19:57 :D 19:57 blackburn: but that does not have to be in shogun2.1 right? 19:58 heiko: yes and now I am in trouble 19:58 sonney2k: blackburn I got my MMD stuff finally ready, also tutorial updated, new tests/examples, and I commented on all the bugs and solved some, so from my side, we can go for it 19:59 blackburn, heiko so waht is missing for shogun 2.1? 19:59 I am under the impression we are in good shape for a release... 19:59 hahah guys have you seen that? http://www.youtube.com/watch?feature=player_detailpage&v=CL3jvaq-VO4 20:00 sonney2k: I agree 20:00 blackburn:  no 20:00 not yet :) 20:00 sonney2k:  have you heard something from the guy who impolemented the streaming basics? 20:00 it is not required to watch all 15 mins but the more you listen to it the more normal it becomes 20:01 blackburn, terminate called after throwing an instance of 'tapkee::eigendecomposition_error' 20:01 what():  eigendecomposition failed 20:01 sonney2k: cool! where? 20:01 we have some failing examples blocking the release... 20:01 http://shogun-toolbox.org/buildbot/builders/nightly_default/builds/314/steps/test/logs/stdio 20:01 sonney2k: i was just about to tell that maybe it'd be a good idea to switch on the bsd bot to clang instead of gcc 20:01 wiking, hi ! 20:02 sonney2k: how did that appear after perceptron? 20:02 wiking, could you change the unit-tests to all be compiled/executed seperately? this would make things much easier 20:02 heiko: whatyamean? 20:02 heiko: aaaah 20:03 sonney2k: I don't mind to fix it but where it is.. 20:03 heiko, btw I wanted to comment on how examples are written in shogun and how they are documented 20:03 wiking, so currently if you run make unit-tests 20:03 heiko: why's that good? 20:03 verything runs at once 20:03 sonney2k: yes? 20:03 heiko, you write your example in the undocumented// folder 20:03 heiko: yeah that's the purpose of unit test 20:03 heiko: i mean now i get waht you want 20:03 heiko: each unit test is a separate executable 20:03 wiking yes 20:03 it's doable imho 20:03 but still i dont see why's that good 20:04 sonney2k: so since the unit-tests finally arrived the examples (at least mine) will change. less testing things, more illustration 20:04 heiko, then you write the description of the example separetely in examples/descriptions 20:04 wiking, if I add a new test and it fails I cannot run it isolated 20:04 sonney2k: under the same name? 20:04 it is then prepended to each example of the same name for each $LANG 20:04 heiko: what if i make you selectable? 20:04 heiko: so there's still only one executable 20:04 heiko: but you can specify which test u wanna ran on command like 20:05 like 20:05 make unit-tests SGVector 20:05 or something like that? 20:05 sonney2k: I see 20:05 wiking, yes that would be good 20:05 and make unit-test would be doing the whole test by default 20:05 wiking, also compile shogun with --enable-trace-mallocs and run the tests 20:05 heiko: mmmm 20:05 wiking: this will show loads of loads of memeory leaks 20:05 where? 20:06 wiking: in configure 20:06 heiko, so that is how it has been for a few years - now there is one exception: the examples in$lang/graphical 20:06 or you mean it would be good to have tests runnning  --enable-trace-mallocs ? 20:06 sonney2k: ok, thats good to know 20:06 these are not documented 20:06 heiko, examples should be written as functions and called 20:07 heiko: bcoz the thing is the unit test flags really depends on ./configure flags... and that is pretty much up to the user... 20:07 wiking: no, I just use trace-mallocs by default, and it creates this annoying output at the end 20:07 heiko: ok i'll check 20:07 heiko, this way we get integration tests for free! 20:07 sonney2k: ok! I changed one of mine recently to that 20:07 sonney2k: btw the graphical examples are a problem: the get outdated quite quickly 20:07 since not detected by make tests 20:07 but we cannot run them since they dont terminate alone 20:08 any ideas for that? 20:08 heiko, unfortunately no one is taking care of examples/integration tests 20:08 sonney2k: these big tests? 20:08 heiko, yes - very useful to know that the svm actually still produces the same result with this particular kernel and data :) 20:10 sonney2k: I will test it w/o arpack now 20:11 sonney2k: indeed! 20:11 heiko, and it is testing all the serialization stuff too btw 20:11 sonney2k: what is the state of that? 20:11 for each and every method 20:11 sonney2k: I have to admit that I never looked at this 20:12 heiko, look at http://shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/869/steps/test%20python_modular/logs/stdio 20:12 sonney2k: so how does it work? 20:12 OOOOOOOOOPS 20:13 how is each an every method tested? 20:13 sonney2k: I added similar things to my unit-tests 20:14 like the result on this fixed data has to be that 20:14 heiko, go to shogun/tests/integration/python_modular 20:14 there is tester.py 20:14 and generator.py 20:14 *very* small scripts 20:15 generator.py does nothing more than run one example with the parameters specified in that example 20:16 and write the output to a file 20:16 sonney2k: I see thats why some examples have parameters 20:16 tester loads that output and runs the example and really 1:1 compares the stuff 20:16 like binary comparison 20:16 sonney2k: so this is to ensure that methods do not change 20:17 for this to to work you need deterministic algorithms 20:17 that is no parallel stuff 20:17 and init random number generator 20:17 exactly 20:17 I see 20:17 and if they change 20:17 just run generator.py with the example name that needs updating 20:18 so I added a lot of assertions in the unit-tests for similar things: fixed seed, fixed data, assert result 20:18 do you think its a bad idea to have two separate places where this is happening? 20:18 heiko, yes 20:19 just return the stuff in the function you want to see asserted 20:19 sonney2k:  but how do I add the results 20:20 sonney2k: found a bug, soon to come 20:20 sonney2k: I mean its not enough to just return it right? I need to specify the truth somewhere 20:20 heiko, well you just run generator.py with that example once 20:20 sonney2k: ok I see, this generates the files 20:21 sonney2k: but there is one difference: I am comparing against matlab 20:21 the tester compares against the program against itself 20:21 the tester compares against what the generator has once witten out 20:22 so the procedure would be, write example that works , compare with other implementation by hand, when correct, add integration test 20:22 heiko, exactly 20:23 that was my idea 20:23 sonney2k: so then unit-tests should be more implementation things 20:23 rather than results of numerical methods 20:24 well, this goes hand in hand 20:24 I think I will just add the integration tests additionally 20:24 doesnt hurt to have the others 20:24 sonney2k, blackburn, wiking I will go home now, long day, have a good evening! 20:24 heiko: see you 20:24 -!- heiko [~heiko@nat-164-89.internal.eduroam.ucl.ac.uk] has left #shogun [] 20:26 -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun 20:48 -!- shogun-notifier- [~irker@7nn.de] has joined #shogun 20:56 shogun: Soeren Sonnenburg :master * b837e0e / tests/integration/python_modular/ (2 files): https://github.com/shogun-toolbox/shogun/commit/b837e0e589b2ecd67385532d7a9b0bcdae3cf327 20:56 shogun: fix integration test directory 20:56 build #870 of deb3 - modular_interfaces is complete: Success [build successful]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/870 21:49 -!- heiko [~heiko@5ac1f59a.bb.sky.com] has joined #shogun 21:56 -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has joined #shogun 22:10 -!- heiko [~heiko@5ac1f59a.bb.sky.com] has left #shogun [] 22:13 -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has quit [Ping timeout: 264 seconds] 22:26 -!- sumit [ca4eaca2@gateway/web/freenode/ip.202.78.172.162] has quit [Quit: Page closed] 23:44 -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] 23:56 -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] 23:57 --- Log closed Fri Mar 08 00:00:04 2013