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