gsomix droopy @sonney2k --- Log opened Sat Jul 21 00:00:17 2012 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has quit [Quit: Leaving.] 00:20 -!- blackburn [~blackburn@109.226.92.17] has quit [Quit: Leaving.] 02:34 -!- emrecelikten [~emre@176.40.251.10] has quit [Ping timeout: 276 seconds] 03:54 -!- puffin444 [187b4283@gateway/web/freenode/ip.24.123.66.131] has joined #shogun 05:46 -!- gsomix [~gsomix@188.168.2.62] has quit [Remote host closed the connection] 05:56 -!- gsomix [~gsomix@85.26.233.122] has joined #shogun 06:39 good morning 06:39 -!- puffin444 [187b4283@gateway/web/freenode/ip.24.123.66.131] has quit [Quit: Page closed] 07:22 -!- zxtx [~zv@ool-457e7550.dyn.optonline.net] has joined #shogun 08:37 -!- gsomix [~gsomix@85.26.233.122] has quit [Ping timeout: 246 seconds] 09:25 -!- rieck [~rieck@134.76.96.43] has joined #shogun 09:32 rieck!! 09:32 -!- rieck [~rieck@134.76.96.43] has left #shogun [] 09:35 -!- gsomix [~gsomix@83.149.21.227] has joined #shogun 09:38 -!- pluskid [~pluskid@li411-226.members.linode.com] has joined #shogun 09:45 -!- gsomix [~gsomix@83.149.21.227] has quit [Ping timeout: 252 seconds] 10:42 -!- rieck [~rieck@134.76.96.43] has joined #shogun 10:53 -!- gsomix [~gsomix@85.26.165.155] has joined #shogun 10:54 -!- gsomix [~gsomix@85.26.165.155] has quit [Ping timeout: 246 seconds] 11:09 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has joined #shogun 11:35 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has quit [Quit: Leaving.] 11:41 haha droopy can you say droopy? 11:41 sonney2k: there you go 11:41 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has joined #shogun 11:56 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has quit [Client Quit] 11:58 -!- emrecelikten [~emre@176.40.251.10] has joined #shogun 12:09 wiking, please update your PR with the trivial changes such that I can merge it! 12:09 -!- emrecelikten [~emre@176.40.251.10] has quit [Client Quit] 12:10 -!- hoijui [~hoijui@dslb-088-074-122-056.pools.arcor-ip.net] has joined #shogun 12:26 -!- hoijui_ [~hoijui@dslb-088-074-122-056.pools.arcor-ip.net] has joined #shogun 12:29 -!- hoijui [~hoijui@dslb-088-074-122-056.pools.arcor-ip.net] has quit [Client Quit] 12:30 -!- hoijui_ [~hoijui@dslb-088-074-122-056.pools.arcor-ip.net] has quit [Client Quit] 12:30 -!- hoijui [~hoijui@dslb-088-074-122-056.pools.arcor-ip.net] has joined #shogun 12:31 -!- blackburn [~blackburn@109.226.92.17] has joined #shogun 12:48 -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun 13:10 hi all 13:11 hey 13:23 n4nd0: how did you holidays go? 13:27 blackburn: they were good! 13:27 I have been out in the wild camping and so on, it has been fun :) 13:28 cool 13:31 -!- hoijui [~hoijui@dslb-088-074-122-056.pools.arcor-ip.net] has quit [Quit: Leaving] 13:59 -!- pluskid [~pluskid@li411-226.members.linode.com] has quit [Ping timeout: 264 seconds] 14:34 -!- pluskid [~pluskid@111.120.10.104] has joined #shogun 14:54 pluskid: hey 14:56 n4nd0: btw we with wiking wanted to test shogun on ILSVRC2012, wanna join? 14:57 I also would like to build a team to participate in kaggle stuff 14:57 blackburn: I read about it in the mail wiking sent a couple of days in the list 15:00 exactly 15:00 it sounds very good, I would like to be in, yes 15:01 wiking: ^ 15:01 n4nd0: we both are just curious how to handle SUCH BIG data 15:01 138 Gb! 15:01 and actually now we need to come up with some features 15:02 wow, 138 GB 15:02 I am going to come up with some fast HOG and wiking wanted to adapt FREAK 15:02 http://infoscience.epfl.ch/record/175537/files/2069.pdf I am looking forward to try FREAK actually 15:03 it is something faster and more accurate than SIFT/SURF 15:03 blackburn: hi! 15:06 pluskid: how is it going? you became rare here ;) 15:06 blackburn: I hang here, but rarely speak :D 15:06 struggling with some 300+ line matlab code... 15:07 matlab function 15:07 exactly like I do 15:07 to turn it into C++ 15:07 haha 15:07 HA 15:07 blackburn: what algor are you working on now? 15:08 pluskid: https://github.com/shogun-toolbox/shogun/blob/master/src/shogun/lib/slep/slep_solver.cpp that thing is just 8 matlab files (loc ~200) generalized into one solver 15:08 pluskid: well I am currently fixing bugs in recently introduced multitask algorithms ported from the MALSAR library 15:08 they are basically about the same 15:09 regularizers are different :) 15:09 hrhr 15:09 blackburn: not better here :P, https://github.com/pluskid/shogun/blob/multiclass/src/shogun/multiclass/tree/RelaxedTree.cpp 15:10 two big functions 15:10 pluskid: btw we now can use eigen3, did you know? 15:10 blackburn: don't know :-/ 15:10 pluskid: here is the example 15:11 https://github.com/shogun-toolbox/shogun/blob/master/src/shogun/lib/malsar/malsar_clustered.cpp 15:11 there are some double* but they are just for libqp interfacing 15:11 blackburn: eigen3 is a matrix library? 15:12 yes 15:12 cool! 15:12 vectorizing actually 15:13 so we can expect even some performance impact here 15:13 longing for a matrix library in shogun :D 15:13 and I guess this would be much easier to code than raw LAPACK 15:13 A*B is A*B 15:14 not cblas_dgemm(CblasColMajor,CblasNoTranspose, ... N,M,K 15:14 :D 15:14 then what about SGMatrix? 15:14 will it stay? 15:14 well just store everything in sgmatrices 15:14 but in solvers/algorithms 15:15 you may use eigen3 15:15 I don't like idea of having eigen3 matrices members 15:15 I see 15:15 anyway, such a good news! 15:16 actually if you want to treat SGMatrix as Eigen3 matrix 15:16 you may do that using Map 15:16 so it looks like a good idea for me to keep eigen3 only inside 15:16 hmm, that's reasonable 15:17 -!- gsomix [~gsomix@80.234.50.198] has joined #shogun 15:20 hi 15:23 -!- rieck [~rieck@134.76.96.43] has left #shogun [] 15:38 -!- pluskid [~pluskid@111.120.10.104] has quit [Quit: Leaving] 16:01 -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] 16:07 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has joined #shogun 16:27 heiko: hey 16:28 blackburn heyho 16:28 heiko: I am thinking how can I make multitask work with xval or at least subsets 16:28 heiko: can we know original indices of subset? 16:29 nice 16:30 well 16:30 original indices? 16:30 or initial or any other word 16:30 :) 16:30 I mean 16:30 You could find that out, however, its expensive 16:30 why do you need that? 16:30 in multitask you have something liek 16:31 0:20 is first task 16:31 20:40 is second task 16:31 and if you apply to first 20 vectors 16:31 you have to use first learned w 16:31 or learned model generally 16:31 cant you do that via the store_model_features? 16:32 let me try to think (it's hard for me) :D 16:32 heiko: what can I store? 16:32 mmh 16:34 I must admit that I dont really get the problem you have 16:34 for doing xval, you would just need to train/test on different indices 16:34 these come from the SplittingStrategy 16:34 Now if you want only certain combinations, just build a new splitting strategy 16:35 no I need to tell machine 'it is the second task vector, use second model' 16:35 which respects you taks etc 16:35 you should do that via the indices 16:35 but the cross-validation class just takes the indices and performs train/test 16:35 -!- rieck [~rieck@134.76.96.43] has joined #shogun 16:36 yeah 16:36 damn I need to rearrange vectors somehow 16:37 or to construct an explicit mapping 16:37 I think the splitting strategy would be good for that 16:37 because currently it doesn't work with non contiguous tasks 16:38 no idea... 16:38 heiko: I mean now I am using a vector [0,20,40] 16:38 to indicate 0:20 is the first task 16:38 if I get something random 16:39 like [second task vector, first task vector, second task vector, ... ] 16:39 it won't work at all 16:39 and I don't really like it :) 16:39 but if you know which indices are which tasks 16:40 then you could build training/test indices that reflect that 16:40 right? 16:40 yeah 16:40 but still time to change things I think 16:40 indices vector would be better here.. 16:41 might be, yes 16:41 blackburn, what do you think about the first section of the tutorial? 16:46 let me check 16:51 hmm it doesnt' complile here :D 16:52 yep 16:52 heiko: okay so what do you mean first section? 16:54 for statistical tests 16:54 really? 16:54 what error do you get? 16:54 probably package missing 16:54 I just installed 16:54 all is ok now 16:54 I meant more like style 16:55 I more focussed on the algo basics rather than SHOGUN internals 16:55 looks cool 16:55 exactly 16:56 and just saying see shogun class bla 16:56 but we need a way of doing this 16:56 I mean a uniform way 16:56 I currently only added TODO's 16:56 well style is something subjective 16:56 but I like the style you use and it probably fits to mine 16:57 I'll add some stuff in next few days too 16:57 kk 16:58 How to reference shogun classes/methods? 16:58 just mention name? 16:58 yeah I think so 16:58 and then user can look up class reference 16:58 ok 16:58 lets put the class names in some courier font 16:59 well actually may be we can set up some reference 16:59 yeah I thought so 16:59 yeah \textt 16:59 but by hand=lots of work 16:59 tt 16:59 no why by hand 16:59 http://www.shogun-toolbox.org/doc/en/current/classshogun_1_1CBinaryFile.html 17:00 could that be embeddedn in latex? 17:00 \defcommand[1]{\shogunclass}{\href{http://www.shogun-toolbox.org/doc/en/current/classshogun_1_1%1.html}{%1}} 17:01 try that 17:01 k will do 17:01 that might be an idea 17:01 ehm 17:01 \newcommand 17:01 now defcommand :D 17:01 ^_^ 17:01 or just put in url to class reference 17:01 on dis 17:01 disc 17:01 or so 17:01 dont know 17:01 no, why 17:01 just use that kind of command 17:01 \shogunclass{CBinaryFile} should work 17:02 let me try 17:02 kk 17:03 a few mistakes here :) 17:05 oh the weather is sweet finally 17:07 whether? 17:08 :) 17:08 same here 17:09 first sunny day in ages 17:09 has been raining all the time 17:09 well opposite 17:09 was way too sunny :D 17:09 heiko: \shogunclass{anything} 17:11 heiko: I commited it 17:11 thats supercool 17:12 thanks 17:12 is it also in \tt ? :) 17:12 yes 17:12 heiko: it points to shogun-toolbox doc 17:12 so if you click you see doc of the class *magic* 17:13 :) 17:13 hrhr 17:13 heiko: I wonder whether anyone would be able to parse my english in that tutorial :D 17:15 lol :) 17:15 well we should correct each other 17:15 and its a good chance to learn for you :) 17:16 I remember I had to fix a lot of wrong usages in my wannabe-jmlr-paper 17:16 heiko: I had one idea on authorship 17:16 which is? :) 17:17 something like \authors{Heiko Strathmann} in section/part 17:17 blackburn, I like the commadn you added 17:17 which is shown in footer 17:17 ok, good idea 17:17 so user can kick ass of correct person 17:17 :D 17:17 heiko: about style or rather desing 17:19 design 17:19 I remember there was a cool package to set up section headers 17:19 blackburn, theres the git blamelist for that :) 17:22 but I agree anyway 17:22 and I like fancy chapter headers 17:22 like with capital letters 17:22 heiko: I actually like fonts 17:23 no 17:23 I love fonts 17:23 :D 17:23 heiko: http://www.tug.dk/FontCatalogue/mathfonts.html which do you like most? 17:24 lol :) 17:25 Well ,I think we should stay with the standard since people are used to it. 17:25 But I love facy capital letters at section beginnings 17:25 how can people get used to font? ;) 17:25 because everybody uses it 17:26 I find palatino much more readable than computer modern roman 17:26 so it sorts in smoothly 17:26 heiko: just try it 17:26 \usepackage[sc]{mathpazo} 17:26 dont know, lets just play around with that 17:27 see what people think :) 17:27 heiko, he 17:27 can always change, nice thing about LaTeX 17:27 heiko: I just ran some script I used before but now with shogun compiled with optimizations 17:37 never thought it depends SO MUCH 17:37 10 times faster at least 17:38 what? 17:38 blackburn, what did you do? 17:38 ah alright 17:38 optimisations 17:38 yeah 17:38 yeah these count massively 17:38 take for example loops 17:38 I never thought so much 17:38 when you dont optimize, i++ takes three operations 17:38 ++i just one 17:39 heiko: do you know whether gcc uses SSE here in loops? 17:39 when you optimise, its always one 17:39 no idea 17:39 heiko: if I had \infty time I'd analyze asm code 17:42 :D 17:42 blackburn, I did that in uni intensively, completely boring, believe me, you dont wanna do that 17:42 heiko: why did you? 17:42 I am a computer-scientist 17:42 had to do it 17:42 :) 17:43 -!- gsomix_ [~gsomix@80.234.25.187] has joined #shogun 17:43 I already changed lots of these courses to math, but couldnt avoid all :D 17:43 well I am too but I hadn't ;) 17:43 lucky you! 17:43 gotta have a coffee now, see you later! 17:43 see you 17:43 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has quit [Quit: Leaving.] 17:43 -!- gsomix [~gsomix@80.234.50.198] has quit [Ping timeout: 248 seconds] 17:46 http://cat.shogun-toolbox.org.meowbify.com/ 18:12 shogun: Sergey Lisitsyn master * r6eea837 / (7 files in 4 dirs): Introduced random search model selection - http://git.io/SMuH5Q 18:47 -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun 18:47 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has joined #shogun 18:50 heiko: I added random search model selection 18:53 blackburn, random search? 18:53 yeah :D 18:53 what should that give? :) 18:53 no idea 18:53 Actually, for high dimensions, this is some kind of genetical programming approach, where you randomly find a good estimate and then refine from there 18:53 so useful  in conjunction with other methods :) 18:54 heiko: well let it be anyway 18:54 blackburn, sure gcc uses sse123, mmx etc 19:15 I see 19:15 blackburn, there is close to no gain to do assembly tweaks 19:19 heiko, ^ 19:19 sonney2k: no I meant different thing 19:19 blackburn, for example I used a for loop to compute a dot product 19:19 it is useful to know what compiler produces 19:19 vs. one that uses sse 19:19 sonney2k, yeah, also its boring and can be done automatically by software which smart people wrote :) 19:19 about the same speed 19:19 sonney2k, what do you think about adding a test framework 19:20 based on unit tests like googletest? 19:20 but when you overoptimize it runs slower on other tasks 19:20 heiko, I am not so convinced... won't enabling the tests we have be sufficient? 19:20 I mean what is the gain? 19:20 I mean a focus on small scale tests 19:21 I write a method 19:21 I add a test for that method 19:21 like index conversion or so 19:21 store_model_features 19:21 with defined input output 19:21 the test framework is for larger scale tests 19:21 heiko, so sth like SVM cannot be tested then 19:21 I am more interested on the engineering side , not so much on ML 19:21 ok 19:22 memory errors 19:22 guaranteed input/output 19:22 this stuff 19:22 I understand then - however I can tell that these 'way too big tests' would cover these smaller ones somehow 19:22 because most errors that pop up are exactly caused by this: somebody forgot a case .. 19:22 at least the buildbot would tell us what failed 19:22 Thats true, most errors are found 19:22 however, it always takes ages to debug 19:23 And so much code is not even tested at all 19:23 well it would point us to the commit that broke *a* test 19:23 In practice, errors are more complicated 19:23 for example this mkl stuff recently 19:23 but yes it would take more time to fix this than when you have such small tests 19:23 It took quite a while till I found the method that was wrong: strore_model_features did a wrong job 19:24 a test would have detected that 19:24 I think so 19:24 heiko, the problem here really is that we changed so much recently that basically all the 'big' tests were no longer working 19:24 (think of serialization framework here!) 19:24 yeah I know 19:24 I think its a lot about actually running the code with defined input/output at least once 19:25 so people would think more about stuff 19:25 rather than quickly committing as soon as the first test case worked 19:25 heiko, I can only tell that even blackburn doesn't always add an example to the code he added. And it is even more difficult with anyone submitting patches... 19:25 I know, thats much more work 19:25 people just give up 19:26 because writing tests is not a fun taks 19:26 I know 19:26 but its crucial to *any* larger software 19:26 you are right - that is why I require an example before I merge anything 19:26 it is useless currently because tests are no longer enabled 19:27 (as in not running) 19:27 Another reason why I suggest it is that we currently dont really have a place for these kind of tests 19:27 I am always commiting them to examples 19:27 but actually many are not examples, way to complicated/technical 19:28 for small tests we don't yes 19:28 but rather just checks that everything works as I want it to 19:28 in python modular I think examples are nice to show how things work and are great tests too 19:28 yes they are great for detecting errors 19:28 but its always hard to debug since you only know that this large example fails 19:29 I think it would be worth so much if you knew that a method failed 19:29 another thing: sometimes code is committed too fast. When you would have to write a test, you would think more about what you actually did there 19:29 more of a incremental development 19:29 -!- rieck [~rieck@134.76.96.43] has quit [Quit: ZNC - http://znc.sourceforge.net] 19:29 heiko, I don't disagree - I just don't know who would write those tests 19:29 -!- rieck [~rieck@134.76.96.43] has joined #shogun 19:30 rieck :> 19:30 When somebody writes code, it has to be tested anyway, people do that locally 19:30 you can't program without tests 19:30 droopy: old chap! 19:30 what 19:30 so why not adding that bit of extra work to nail it down 19:30 I suggest a rule: each new method has to get a test 19:31 just all code covered at least once 19:31 its not that much work actually 19:31 and since they are all small scale, its easy to write them 19:31 since you already wrote the method 19:31 heiko, yeah I use sth that I turn into an example examples (in python modular) 19:32 yeah like that, but only small scale 19:33 imagine every method had one of these 19:33 bug tracing would be so easy 19:33 well any method you modify and any method that gets added 19:33 and methods would be more reliable 19:33 yeah 19:33 so over the time, we collect more and more 19:33 -!- rieck [~rieck@134.76.96.43] has quit [Client Quit] 19:34 and also, one could make it madatory that all tests (also old ones) pass and have no mem-leaks 19:34 =less new bugs 19:34 (at least in my fantasy its like this :) 19:34 *g* 8) 19:34 well, its just a suggestion 19:34 Now with all the new people, might be easier than a year ago 19:34 I wouldn't mind - lets ask the others: blackburn, n4nd0, wiking - opinions on  new rule: "for any method you modify and any method that gets added a test is required" 19:34 I would add: "with defined input/output assertions" 19:35 how? 19:35 blackburn, leave aside the how for now. 19:36 I share heiko's opinion, I think it is a good idea that will decrease the number of bugs introduced 19:36 I don't mind 19:36 ok then - so heiko any ideas how to do that practically then? 19:37 what about a new folder new to example called tests 19:37 choose a free framework 19:37 copy folder structure from libshogun 19:38 and simply add units there 19:38 add additionaly target to make 19:38 heiko, so these would be all .cpp right? 19:38 yeah 19:38 Could add some for other languages but thats more complicated and I think the core ist most important 19:38 modular could in fact be handled in examples, and usually one does not change things too much in there 19:39 except for gsomix currently, but thats covered through new examples he makes 19:39 so this would mean we have mini-unit tests and huge regression tests 19:39 yeah 19:39 gsomix_, btw - any news on the PR? 19:39 I actually agree we are BUG-O-TRONIC 19:40 sonney2k, I want to add setters to my PR. 19:40 -!- rieck [~rieck@134.76.96.43] has joined #shogun 19:42 heiko: still here? 20:09 wiking, yes 20:09 heiko: i've started off with the following structure 20:09 add to each class a _unittest.cc implementation 20:09 that has the unittests 20:09 each class one .cpp file with tests for each method? 20:10 and then just modified the Makefile.template that it complies it with different flags (i.e. addig the flags for gtest/gmock 20:10 I would rather go for each shogun .cpp file gets one *_unittest.cpp 20:10 instead of each class 20:10 nice 20:10 heiko: well that's the idea 20:10 and then you have a main_unittest.cc 20:11 but the tests should be in a different dir 20:11 that calls all the tests 20:11 heiko: i've tried that one as well 20:11 like 20:11 src/testing 20:11 like a copy of the src dir 20:11 one could symlink all the .cpp files 20:11 but it's very bizzare to have the same dir structure 20:11 just for the unittesting 20:11 imho 20:11 really? well, ok 20:11 so same dir 20:11 this way you have to create right next to your implementation 20:12 your _unittest.cpp implementation as well 20:12 but then again 20:12 year, but it becomes a bit messy then 20:12 many files 20:12 this can change 20:12 i'm ok with anything 20:12 i've just started of with SGVector 20:12 to define some unittest 20:12 yeah, dont know, blackburn, sonney2k, ^ 20:12 yeah good place to start 20:12 like multiply, fill with zeros etc 20:12 yes 20:12 exactly 20:12 dot product 20:13 etc. 20:13 we should somehow add a memory test 20:13 heiko: that's tricky 20:13 that it *always* fails if there is a memory leak or something 20:13 heiko: unittest is not meant for that 20:13 I know 20:13 heiko: but there are various solutions 20:13 we could add a script to run all these with valgrind 20:13 like blackburn did for the examples 20:13 heiko: well in some way that's already there in examples/libshogun 20:13 the thing is: it should be automatically enabled 20:13 heiko: the problem is that gtest for example 20:14 otherwise, one forgets 20:14 does some tricky things 20:14 and thus valgrind will sometimes start crying 20:14 so valgrind complains about that? 20:14 for no reason 20:14 yes 20:14 oh 20:14 thats bad 20:14 or at least this is what i've read about 20:14 at some forums 20:14 but there are other ways 20:14 the problem is that those ones are system specific 20:14 I think we should definately check the tests for memory in some way 20:14 i.e. depends on the OS 20:14 mh, other solutions? 20:15 so for win there's a straightforward 20:15 http://msdn.microsoft.com/en-us/library/e5ewb1h3(v=vs.80).aspx 20:15 but that's really for M$20:15 aah way 20:16 wait! 20:16 i remember now 20:16 so yeah i forgot 20:16 boost.testing has an option 20:16 for memory leak detectio 20:16 http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/execution-monitor/user-guide.html 20:17 buut that's actually m$ only as well 20:17 so i'll push soon my 'gtest based' attempt for unittest into my repo 20:17 so you can comment on it 20:17 wiking, ok great work, we can still think of how to detect memory issues 20:18 heiko: yeah i've googled some 20:18 but w/o luck 20:18 i think valgrind is still the best way to go in this case 20:18 ok, well lets see how it behaves with gtest 20:18 i mean osx has it's on way as well 20:18 but that's as well osx 20:18 and i dont think we want to handle all the OSes 1-by-1 20:19 the funny thing about gtest is actually 20:19 that you can even define that what should be the execution time of a given test 20:19 so if the test doesn't run within that time it'll still report it as fail 20:19 so it has some good stuff in there .... 20:20 I agree with the OS's 20:20 maybe thats second step 20:20 basic tests first 20:21 theres probably lot to discuss with the others on your patch 20:21 but yeah i think basic unittesting would be already a good thing to have 20:21 so that really we can point out if there's suddenly something broken 20:21 heiko: yeah i've just felt that something should be done about it and didn't really felt for discussion 20:21 we'll see when there's already something to discuss about 20:22 agreed, nice! :) 20:22 ok i'm aw now a bit to polish the example 20:22 and then i'll send a mail to the list 20:22 so that anybody can add their thoughts 20:22 great work wiking, Ill try to add something tomorrow then 20:26 heiko: okie 20:29 wiking: i'll add multiple output multiclass labels for task 1 20:30 we don't support it now actually 20:30 thanks %deity we have well designed multiclass ;) 20:30 -!- heiko [~heiko@host86-177-183-33.range86-177.btcentralplus.com] has quit [Quit: Leaving.] 21:06 -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] 21:45 shogun: Sergey Lisitsyn master * r2b6dcd3 / (14 files in 3 dirs): Changed task indexing way of MALSAR based algorithms and task api in general - http://git.io/5eGMZA 22:03 build #84 of bsd1 - libshogun is complete: Failure [failed compile]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/84  blamelist: Sergey Lisitsyn 22:10 blackburn: yeey 22:27 wiking: what? 22:27 on your prev message 22:27 i didn't see it 22:27 shogun: Sergey Lisitsyn master * r7a0f065 / (2 files in 2 dirs): Fixes for feature blocked logistic regression - http://git.io/jtO7tA 22:59 build #85 of bsd1 - libshogun is complete: Success [build successful]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/85 23:05 sonney2k, around? 23:22 bujjaaa 23:47 this works \o/ 23:47 --- Log closed Sun Jul 22 00:00:17 2012