| --- Log opened Sun Apr 29 00:00:21 2012 | ||
| -!- PhilTillet [~Philippe@npasserelle10.minet.net] has joined #shogun | 00:07 | |
| -!- PhilTillet [~Philippe@npasserelle10.minet.net] has quit [Remote host closed the connection] | 00:41 | |
| -!- pluskid [~pluskid@111.120.75.191] has joined #shogun | 03:32 | |
| pluskid | sonney2k: I have no concern about new SGVector/SGIVector now, after reading last night's IRC log | 03:35 |
|---|---|---|
| -!- emrecelikten [~emre@92.44.238.239] has joined #shogun | 04:59 | |
| -!- emrecelikten [~emre@92.44.238.239] has quit [Ping timeout: 265 seconds] | 06:33 | |
| -!- emrecelikten [~emre@92.44.124.86] has joined #shogun | 06:38 | |
| -!- pluskid [~pluskid@111.120.75.191] has quit [Quit: Leaving] | 07:15 | |
| -!- emrecelikten [~emre@92.44.124.86] has quit [Ping timeout: 246 seconds] | 07:44 | |
| -!- n4nd0 [~n4nd0@153.Red-2-137-55.dynamicIP.rima-tde.net] has joined #shogun | 07:48 | |
| n4nd0 | good morning | 07:48 |
| -!- gsomix [~gsomix@109.169.253.0] has joined #shogun | 07:50 | |
| -!- n4nd0 [~n4nd0@153.Red-2-137-55.dynamicIP.rima-tde.net] has quit [Quit: Ex-Chat] | 08:00 | |
| -!- n4nd0 [~n4nd0@153.Red-2-137-55.dynamicIP.rima-tde.net] has joined #shogun | 08:00 | |
| gsomix | good morning | 08:04 |
| -!- n4nd0 [~n4nd0@153.Red-2-137-55.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 08:28 | |
| -!- Marty28 [~marty@cable-158-181-78-199.cust.telecolumbus.net] has joined #shogun | 08:33 | |
| Marty28 | Moin | 08:34 |
| -!- n4nd0 [~n4nd0@153.Red-2-137-55.dynamicIP.rima-tde.net] has joined #shogun | 08:41 | |
| -!- Marty28 [~marty@cable-158-181-78-199.cust.telecolumbus.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] | 08:44 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 08:46 | |
| -!- Priyans [~Priyans@115.248.130.148] has joined #shogun | 09:26 | |
| -!- Priyans [~Priyans@115.248.130.148] has left #shogun [] | 09:28 | |
| -!- gsomix [~gsomix@109.169.253.0] has quit [Ping timeout: 246 seconds] | 09:31 | |
| -!- gsomix [~gsomix@95.67.182.154] has joined #shogun | 09:45 | |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 10:17 | |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 10:17 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 10:17 | |
| -!- n4nd0 [~n4nd0@153.Red-2-137-55.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 10:27 | |
| -!- blackburn [~qdrgsm@85.114.185.217] has joined #shogun | 11:49 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 12:31 | |
| -!- wiking [~wiking@vpna095.ugent.be] has joined #shogun | 12:31 | |
| -!- wiking [~wiking@vpna095.ugent.be] has quit [Changing host] | 12:31 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 12:31 | |
| CIA-64 | shogun: Sergey Lisitsyn master * r549fddc / (7 files in 3 dirs): Moved rejectionstrategy - http://git.io/GGaHGw | 12:35 |
| shogun-buildbot | build #793 of libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/libshogun/builds/793 blamelist: blackburn91@gmail.com | 12:37 |
| shogun-buildbot | build #222 of nightly_all is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/222 | 12:38 |
| wiking | heheeey | 12:39 |
| wiking | blackburn: wazza u broke the ssyyyyystem! | 12:41 |
| blackburn | wiking: heh | 12:44 |
| CIA-64 | shogun: Sergey Lisitsyn master * rda1d7b8 / (2 files): Fixed includes in external libs - http://git.io/tLBR2g | 12:51 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Ping timeout: 246 seconds] | 12:55 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 12:59 | |
| wiking | ocas fix needed: : Exception in thread "main" java.lang.RuntimeException: Out of memory error, tried to allocate -12627258368 bytes using malloc. | 13:02 |
| blackburn | shogun-buildbot has bad health lately | 13:12 |
| CIA-64 | shogun: Sergey Lisitsyn master * r1455284 / src/shogun/multiclass/MulticlassOCAS.cpp : Fixes memory allocation at ocas - http://git.io/mH2Lew | 13:16 |
| -!- pluskid [~pluskid@li164-218.members.linode.com] has joined #shogun | 14:29 | |
| pluskid | I defined shogun::CECOCStrategy::CECOCStrategy(CECOCEncoder *,CECOCDecoder *) | 14:32 |
| pluskid | and exported to python_modular | 14:32 |
| pluskid | but in the python code, when constructing a CECOCStrategy object | 14:33 |
| pluskid | with a subclass of CECOCEncoder and a subclass of CECOCDecoder | 14:33 |
| pluskid | it complains that NotImplementedError: Wrong number or type of arguments for overloaded function 'new_ECOCStrategy'. | 14:33 |
| pluskid | https://github.com/pluskid/shogun/blob/multiclass-ecoc/examples/undocumented/python_modular/classifier_multiclass_ecoc_ovr.py | 14:34 |
| blackburn | pluskid: hmm strange | 14:34 |
| pluskid | blackburn: do you know why? | 14:34 |
| pluskid | I also tested in C++ with libshogun | 14:34 |
| blackburn | let me check | 14:34 |
| pluskid | seems OK | 14:34 |
| pluskid | this example is in C++, runs without problem: https://github.com/pluskid/shogun/blob/multiclass-ecoc/examples/undocumented/libshogun/classifier_multiclass_ecoc.cpp | 14:35 |
| blackburn | pluskid: all looks ok.. let me double check :D | 14:38 |
| pluskid | blackburn: thanks! I'm really confused | 14:38 |
| blackburn | pluskid: try to add | 14:39 |
| blackburn | class CECOCEncoder; | 14:39 |
| blackburn | class CECOCDecoder; | 14:39 |
| blackburn | right before definition of CECOCStrategy | 14:39 |
| pluskid | OK | 14:39 |
| blackburn | however this error looks strange | 14:40 |
| pluskid | the full output is this: http://pastebin.com/wUcmQ4sF | 14:42 |
| pluskid | re-compiling | 14:43 |
| pluskid | blackburn: OK this time... | 14:43 |
| blackburn | pluskid: it looks like he didn't get that your en- and de-coders are descendants | 14:43 |
| blackburn | works? | 14:43 |
| pluskid | works! | 14:43 |
| blackburn | hooray | 14:43 |
| pluskid | blackburn: you cool! | 14:44 |
| pluskid | SWIG sucks! | 14:44 |
| blackburn | :D | 14:44 |
| wiking | lol | 15:07 |
| wiking | something changed | 15:07 |
| wiking | i've rebased the shogun repo and now i'm getting better accuracy | 15:08 |
| wiking | :S | 15:08 |
| blackburn | wiking: ??? | 15:08 |
| wiking | yeah go figure :) | 15:08 |
| blackburn | wiking: what is the timerange? | 15:08 |
| wiking | mmm good question | 15:09 |
| blackburn | classifier? features? | 15:09 |
| wiking | Sat Apr 14 | 15:09 |
| wiking | i've rebased till here | 15:09 |
| wiking | commit c12e96c7f3c662512ebd1054fda4a89bcdc4bdca | 15:09 |
| wiking | Merge: 2f00592 d716ae0 | 15:09 |
| wiking | Author: Heiko Strathmann <heiko.strathmann@gmail.com> | 15:09 |
| wiking | Date: Sat Apr 14 13:27:52 2012 -0700 | 15:09 |
| CIA-64 | shogun: Chiyuan Zhang master * r1cac205 / (2 files in 2 dirs): Fix SWIG error of not recognizing class hierarchy. (+5 more commits...) - http://git.io/gZRA0w | 15:09 |
| wiking | but i cannot recall | 15:09 |
| wiking | what was the previous stage | 15:09 |
| blackburn | wiking: uh I'd rather pray the problem is solved already :D | 15:10 |
| wiking | but it's funny with the CombinedDotFeatures | 15:11 |
| wiking | i've created the combineddotfeatures with HKM | 15:11 |
| wiking | and the result is much worse | 15:11 |
| wiking | than simply joining the features | 15:11 |
| wiking | a | 15:11 |
| wiking | nd | 15:11 |
| wiking | the | 15:11 |
| wiking | n do a hkm | 15:11 |
| wiking | but i'm using the same him | 15:11 |
| blackburn | wiking: no that shouldn't be | 15:12 |
| blackburn | it is the same | 15:12 |
| wiking | blackburn: the difference is HUGE | 15:12 |
| wiking | 0.19 vs 0.80 | 15:12 |
| wiking | accuracy wise | 15:12 |
| blackburn | wiking: it should be normalization issue then | 15:13 |
| blackburn | or something like that | 15:13 |
| wiking | blackburn: what i'll try now is that simply do a hkm on each feature | 15:13 |
| wiking | and then | 15:13 |
| wiking | concatenate the feature | 15:13 |
| wiking | and see if that makes a difference | 15:13 |
| blackburn | wiking: are you sure weighting is the same? | 15:14 |
| wiking | blackburn: weightening? :) | 15:14 |
| blackburn | why so? weighting sounds ok :D | 15:15 |
| wiking | blackburn: how do you weight? :) | 15:15 |
| blackburn | wiking: there are weights for each feature instance.. | 15:16 |
| wiking | i'm using simple features<float64_t> | 15:17 |
| wiking | so where do u set the weight? :)) | 15:17 |
| blackburn | wiking: set_subfeature_weights does the job | 15:18 |
| blackburn | however it needs to be obviously patched to make possible to use it from modular | 15:18 |
| wiking | hehehe | 15:19 |
| wiking | set_subfeature_weights(org.shogun.SWIGTYPE_p_double,int) in org.shogun.CombinedDotFeatures cannot be applied to (double[],int) | 15:21 |
| wiking | :) | 15:21 |
| blackburn | exactly what I said | 15:23 |
| wiking | lets see a quick fix for this :0 | 15:24 |
| blackburn | wiking: just replace it with SGVector<float64_t> | 15:26 |
| wiking | that does not exits in java modular | 15:27 |
| wiking | but DoubleMatrix is equivalent for the story | 15:27 |
| wiking | or at least it was | 15:28 |
| blackburn | wiking: huh it looks like you do not know how this mapping works ;) | 15:34 |
| wiking | ? | 15:34 |
| wiking | which :) | 15:34 |
| blackburn | wiking: what do you mean? | 15:35 |
| wiking | which mapping :) | 15:35 |
| blackburn | isn't it working in case of SGVector? | 15:35 |
| blackburn | SGVector -- DoubleMatrix | 15:35 |
| wiking | well sgvector doesn't exists per se in java | 15:35 |
| blackburn | SGMatrix -- DoubleMatrix | 15:35 |
| blackburn | does it exist in python? | 15:35 |
| wiking | but yeah doubleMatrix was till now sufficient in case when it was expecting an SGVector | 15:36 |
| blackburn | wiking: it should be sufficient right now too :) | 15:36 |
| wiking | still bitching | 15:39 |
| blackburn | wiking: I'll commit fix in a min | 15:53 |
| -!- n4nd0 [02893bbe@gateway/web/freenode/ip.2.137.59.190] has joined #shogun | 15:58 | |
| wiking | blackburn: yo this is now really strange | 15:59 |
| wiking | the combined dot vs concatenating story | 15:59 |
| -!- n4nd0_ [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has joined #shogun | 16:00 | |
| wiking | so now one additional thing. if i take the features, do the HKM on it one by one, but after that i don't use the combineddotfeatures but rather just simply concatenate the features | 16:00 |
| wiking | i'm getting very similar results to the one where first i concatenate all the features and then HKM it | 16:00 |
| wiking | there's something wrong with combineddotfeatures i'm guessing | 16:01 |
| CIA-64 | shogun: Sergey Lisitsyn master * rccbdee1 / (3 files in 2 dirs): Fix for set subfeatures weights - http://git.io/STg1wg | 16:03 |
| -!- pluskid [~pluskid@li164-218.members.linode.com] has quit [Ping timeout: 272 seconds] | 16:06 | |
| blackburn | wiking: I don't mind you fixing it ;) | 16:06 |
| wiking | heheh i have no time for it today | 16:06 |
| wiking | but i'll look into it tomorrow | 16:06 |
| blackburn | yeah and it is not critical | 16:06 |
| blackburn | looks ok, no idea what can be wrong | 16:07 |
| -!- pluskid [~pluskid@111.120.67.198] has joined #shogun | 16:08 | |
| wiking | it looks as if it only uses one feature | 16:09 |
| wiking | i mean feature_obj | 16:09 |
| blackburn | uh code is pretty cumbersome | 16:09 |
| -!- n4nd0 [02893bbe@gateway/web/freenode/ip.2.137.59.190] has quit [Quit: Page closed] | 16:14 | |
| -!- n4nd0_ is now known as n4nd0 | 16:14 | |
| -!- n4nd0 [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has quit [Quit: Ex-Chat] | 16:24 | |
| -!- n4nd0 [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has joined #shogun | 16:24 | |
| -!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 16:45 | |
| -!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 16:45 | |
| -!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 16:45 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 265 seconds] | 16:49 | |
| -!- wiking_ is now known as wiking | 16:49 | |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 16:49 | |
| -!- wiking [~wiking@vpna120.ugent.be] has joined #shogun | 16:51 | |
| -!- wiking [~wiking@vpna120.ugent.be] has quit [Changing host] | 16:51 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 16:51 | |
| -!- emrecelikten [~emre@92.44.124.86] has joined #shogun | 17:32 | |
| -!- pluskid [~pluskid@111.120.67.198] has quit [Quit: Leaving] | 17:36 | |
| -!- emrecelikten [~emre@92.44.124.86] has quit [Quit: Leaving.] | 17:41 | |
| -!- emrecelikten [~emre@92.44.124.86] has joined #shogun | 17:44 | |
| -!- emrecelikten [~emre@92.44.124.86] has quit [Quit: Leaving.] | 17:53 | |
| -!- emrecelikten [~emrecelik@92.44.124.86] has joined #shogun | 17:54 | |
| -!- emrecelikten [~emrecelik@92.44.124.86] has quit [Client Quit] | 17:55 | |
| -!- emrecelikten [~emrecelik@92.44.124.86] has joined #shogun | 18:13 | |
| -!- emrecelikten [~emrecelik@92.44.124.86] has quit [Client Quit] | 18:14 | |
| -!- emrecelikten [~emrecelik@92.44.124.86] has joined #shogun | 18:18 | |
| -!- n4nd0 [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 18:47 | |
| -!- n4nd0 [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has joined #shogun | 19:00 | |
| -!- karlnapf [~heiko@host109-148-116-163.range109-148.btcentralplus.com] has joined #shogun | 19:36 | |
| -!- in3xes [~in3xes@49.14.101.92] has joined #shogun | 19:44 | |
| @sonney2k | karlnapf, you ok too with the SGVector / SGIVector split? | 19:46 |
| karlnapf | sonney2k, tell me more about it | 19:47 |
| @sonney2k | karlnapf, we agree on that we need some kind of SGVector that allows shared memory, i.e. one can call get_vector multiple times | 19:49 |
| @sonney2k | and garbage collection takes care of cleaning things up | 19:50 |
| @sonney2k | karlnapf, right? | 19:50 |
| karlnapf | so you want to create a vector class based on SGObject? | 19:50 |
| karlnapf | sonney2k, yes, agreed | 19:50 |
| @sonney2k | so that means we need sth like we have w/ SGObject: refcount, thread locking, and potentially some flag that deleting is not required at all (just some ptr to some memory somewhere) | 19:51 |
| @sonney2k | karlnapf, so I would create an SGVector that just has all the vector functions and a ptr to the data | 19:51 |
| @sonney2k | e.g. double*, int | 19:51 |
| @sonney2k | (for vector data, length of vector) | 19:52 |
| blackburn | I have doubts we need it at all.. | 19:52 |
| karlnapf | sonney2k, when we last talked about it you were against the vector class, what made you change your mind? | 19:52 |
| @sonney2k | karlnapf, the overhead | 19:52 |
| karlnapf | but its still there isnt it? | 19:53 |
| @sonney2k | SGIVector will cost like 20 bytes or so more than SGVector | 19:53 |
| @sonney2k | so for low-dim data that is *huge* | 19:53 |
| karlnapf | mmh, so now the idea is to split things so that the overhead is only there when the ref-couting is really needed | 19:54 |
| @sonney2k | (8 bytes for ptr, >8 bytes for potential virtual functions, 4 bytes for refcount, 1 byte for boolean flag) | 19:54 |
| @sonney2k | karlnapf, yeah - but almost everywhere we use SGIVector | 19:54 |
| @sonney2k | only when performance matters *a lot* we don't | 19:55 |
| karlnapf | seems like a good idea to me | 19:55 |
| karlnapf | my only fear is the transition | 19:55 |
| karlnapf | in many cases in the code, its not automatically doable | 19:56 |
| karlnapf | because memory managment is done around the SGVector class | 19:56 |
| @sonney2k | karlnapf, yes I know | 19:57 |
| @sonney2k | rough road | 19:57 |
| karlnapf | and since our tests dont cover all the code where SGVector are used ..... | 19:57 |
| @sonney2k | but the hack we have currently makes things soo difficult | 19:57 |
| karlnapf | indeed | 19:57 |
| karlnapf | I encountered this with the subsets | 19:58 |
| @sonney2k | karlnapf, that is why I want gsomix to do this asap | 19:58 |
| karlnapf | they are always copied currently | 19:58 |
| blackburn | sonney2k: I am sorry to ask but what is the problem we can't solve right now? | 19:58 |
| @sonney2k | and then after a few weeks this transitions hsould be over | 19:58 |
| karlnapf | yes | 19:58 |
| @sonney2k | blackburn, as I said shared vectors | 19:58 |
| karlnapf | asap is good | 19:58 |
| @sonney2k | example | 19:58 |
| @sonney2k | class A has a vector foo | 19:58 |
| @sonney2k | you do a->get_vector() | 19:59 |
| @sonney2k | in some class B | 19:59 |
| @sonney2k | and in some class C | 19:59 |
| @sonney2k | who is supposed to free foo now? | 19:59 |
| @sonney2k | we have lots of issues with uselessly copying labels | 19:59 |
| @sonney2k | but we could just have passed ptrs | 19:59 |
| blackburn | sonney2k: do we have such problem right now? | 20:00 |
| blackburn | A B C case | 20:01 |
| karlnapf | blackburn, its not really a problem, but the longer we wati with this, the more complicated it gets to change the system | 20:01 |
| karlnapf | in the new subset system this shared inices would be extremely useful | 20:01 |
| @sonney2k | blackburn, karlnapf btw - I don't mind if we do a different naming like SGVector being the one with refcounting | 20:01 |
| @sonney2k | blackburn, yes | 20:01 |
| blackburn | I feel really unhappy with all these things | 20:01 |
| @sonney2k | with labels this appears everywhere | 20:01 |
| @sonney2k | blackburn, which things/ | 20:02 |
| @sonney2k | ? | 20:02 |
| blackburn | sonney2k: this sgvector hell :) | 20:02 |
| @sonney2k | blackburn, what do you propose? | 20:02 |
| blackburn | sonney2k: nevermind I am just crying :D | 20:02 |
| @sonney2k | blackburn, just recall last years gsoc | 20:03 |
| @sonney2k | double* int -> sgvector was painful | 20:03 |
| gsomix | sonney2k, moin. I will console blackburn. | 20:03 |
| @sonney2k | this here is piece of cake | 20:03 |
| blackburn | what? what will you do with me? | 20:03 |
| blackburn | sonney2k: it was clear what to do | 20:04 |
| @sonney2k | blackburn, it is now too - we just need an SGVector with refcounts | 20:04 |
| karlnapf | blackburn, sonney2k, I think this will be easier than last year | 20:06 |
| blackburn | sonney2k: is feature_iterator overhead significant? | 20:06 |
| @sonney2k | blackburn, huge | 20:07 |
| karlnapf | however, its important that it is done with care. Last year we missed some cases, but this wasnt a problem. One can fix these on the fly nowadays, but with the ref-counting we might run into unexpected memory issues if we forget cases | 20:07 |
| @sonney2k | that is why I don't use it :) | 20:07 |
| blackburn | sonney2k: ehmm dotfeatures one? | 20:07 |
| @sonney2k | blackburn, yeah | 20:07 |
| @sonney2k | if possible don't use it | 20:07 |
| blackburn | sonney2k: how? | 20:07 |
| @sonney2k | blackburn, try to express things with add* *dot | 20:08 |
| blackburn | I need to support both dense and sparse here (S in SLEP stands for sparse) | 20:08 |
| @sonney2k | karlnapf, yes that is true | 20:08 |
| blackburn | sonney2k: I need A'*x operation.. | 20:08 |
| blackburn | i.e. feature row multiplied with vector | 20:08 |
| blackburn | sonney2k: any other suggestions? | 20:09 |
| @sonney2k | blackburn, dense_dot? | 20:09 |
| @sonney2k | or is A sparse too? | 20:09 |
| blackburn | sonney2k: A is feature matrix | 20:09 |
| @sonney2k | is x dense? | 20:09 |
| blackburn | sonney2k: yes | 20:09 |
| @sonney2k | then dense_dot | 20:09 |
| karlnapf | sonney2k, blackburn, gotta go, will be back later this evening | 20:09 |
| @sonney2k | karlnapf, thansk for your opinion | 20:10 |
| blackburn | sonney2k: dense dot performs dot product of each vector with given vector | 20:10 |
| blackburn | karlnapf: ok see you later | 20:10 |
| karlnapf | bye :) | 20:10 |
| blackburn | sonney2k: I need to multiply each *row* of feature matrix | 20:10 |
| blackburn | err to product | 20:10 |
| blackburn | with vector of size num_vectors | 20:10 |
| blackburn | dense_dot does different job | 20:11 |
| @sonney2k | blackburn, because it is transposed you mean? | 20:11 |
| blackburn | sonney2k: yes | 20:11 |
| @sonney2k | then store the data transposed | 20:11 |
| blackburn | sonney2k: I need both kind of operations.. | 20:11 |
| blackburn | Ax and A'x | 20:12 |
| @sonney2k | then no idea - one of these operations will be dog slow | 20:12 |
| blackburn | sonney2k: we have feature iterator in liblinear crammer-singer | 20:12 |
| blackburn | works pretty well though | 20:12 |
| blackburn | sonney2k: hmm it can be done with dot probably? | 20:15 |
| @sonney2k | blackburn, yeah but I introduced this really only to be able to run things - it is not fast | 20:15 |
| @sonney2k | blackburn, the memory access pattern is horrible for dense | 20:15 |
| @sonney2k | for sparse I don't even know how to properly do it | 20:15 |
| @sonney2k | gsomix, do you have time to work on the SGVector stuff *now* | 20:15 |
| @sonney2k | gsomix, or when would you have time? | 20:16 |
| @sonney2k | karlnapf, btw I suspect mostly double free errors ... and the memleaks we can figure out with --trace-mallocs | 20:17 |
| @sonney2k | so it shouldn't be too bad | 20:17 |
| blackburn | sonney2k: can it be dense add? | 20:17 |
| blackburn | n_vectors additions? | 20:18 |
| @sonney2k | blackburn, we have add_to_dense_vec if you mean that | 20:18 |
| blackburn | yes | 20:18 |
| @sonney2k | blackburn, not sure what you are asking | 20:18 |
| blackburn | sonney2k: I broke my head - looks like Ax can be done with n_vectors calls of add_to_dense_vec | 20:18 |
| -!- karlnapf [~heiko@host109-148-116-163.range109-148.btcentralplus.com] has quit [Ping timeout: 276 seconds] | 20:18 | |
| gsomix | sonney2k, right now? Do I have one hour? Some case. ?) | 20:19 |
| gsomix | *:) | 20:19 |
| @sonney2k | blackburn, ??? | 20:20 |
| @sonney2k | gsomix, 1 hour to finish you mean :D | 20:20 |
| @sonney2k | gsomix, I would suggest to (for now) just add all the refcount features to SGVector | 20:21 |
| @sonney2k | then add a int* ptr for the refcount | 20:21 |
| @sonney2k | make the class destructor virtual | 20:21 |
| @sonney2k | and copy the ref/unref stuff over from SGObject | 20:21 |
| blackburn | sonney2k: yes it can be done with add_to_dense_vec | 20:22 |
| @sonney2k | blackburn, explain what you want to do please? | 20:22 |
| blackburn | sonney2k: Ax | 20:22 |
| blackburn | A - feature matrix | 20:22 |
| blackburn | x is a vector of n_vectors*1 size | 20:23 |
| @sonney2k | and x any double* ? | 20:23 |
| blackburn | yes | 20:23 |
| blackburn | given double vector | 20:23 |
| gsomix | sonney2k, huh, ok. :] | 20:23 |
| blackburn | A'x is a dense dot range | 20:23 |
| blackburn | and Ax is a sum of dense add | 20:23 |
| blackburn | that's I was asking :) | 20:23 |
| @sonney2k | blackburn, I cannot follow on the Ax part | 20:24 |
| blackburn | sonney2k: each ith feature vector is multiplied with x[i]? | 20:25 |
| @sonney2k | gsomix, I think there is no way other than commiting this refcount enabled SGVector then and fixing all the breakage with everyone else together | 20:25 |
| @sonney2k | blackburn, ahh | 20:25 |
| @sonney2k | sure | 20:26 |
| @sonney2k | np | 20:26 |
| blackburn | sonney2k: was not clear for me how to use add here - that's why I was asking :) | 20:26 |
| blackburn | so I guess I need to patch liblinear | 20:26 |
| blackburn | to use it too | 20:26 |
| blackburn | sonney2k: is it much faster? | 20:26 |
| @sonney2k | blackburn, I can tell that this will be hundred times faster | 20:26 |
| blackburn | lol | 20:26 |
| blackburn | sonney2k: ooh different issue there.. | 20:27 |
| blackburn | w_i[d_ind[m]] | 20:27 |
| blackburn | crazy indices | 20:27 |
| @sonney2k | w_i == x? | 20:28 |
| blackburn | sonney2k: it is in liblinear | 20:28 |
| blackburn | in my slep code it is simple | 20:28 |
| blackburn | and can be done with add | 20:28 |
| blackburn | but in liblinear it is painful.. | 20:28 |
| @sonney2k | because of some subindices | 20:28 |
| blackburn | yeah | 20:28 |
| blackburn | sonney2k: btw do you think shrinking is possible for libocas? | 20:29 |
| blackburn | like in liblinear | 20:29 |
| @sonney2k | blackburn, ocas usually needs <100 iterations | 20:29 |
| @sonney2k | so what would you want to shrink? | 20:29 |
| blackburn | sonney2k: update only subset of ws | 20:30 |
| @sonney2k | IIRC that was not the most time consuming operation | 20:31 |
| blackburn | yeah actually yes | 20:31 |
| blackburn | most time consuming is outputs | 20:31 |
| @sonney2k | and that is even done in parallel (IIRC) | 20:31 |
| blackburn | sonney2k: yes my main concern is that it is still slower | 20:32 |
| blackburn | sonney2k: than liblinear's coordinate descent | 20:32 |
| @sonney2k | blackburn, no way to fix it ... | 20:32 |
| blackburn | bad bad | 20:33 |
| @sonney2k | for 2 classes it can be faster at times | 20:33 |
| @sonney2k | it certainly is more accurate optimization wise | 20:33 |
| blackburn | sonney2k: results are equal but times slower :( | 20:33 |
| @sonney2k | but that's about it | 20:33 |
| blackburn | sonney2k: about SLEP - do you think I can already put a gpl header and include files at least to my fork? | 20:33 |
| @sonney2k | blackburn, did they answer? | 20:34 |
| blackburn | nothing after you did | 20:34 |
| blackburn | but intention is clear | 20:34 |
| blackburn | sonney2k: may be I should suggest to do it by myself and give them patched version? | 20:34 |
| blackburn | I admit they seems to be not very good in development stuff.. | 20:35 |
| @sonney2k | blackburn, good idea - sent them a patch with the added copyright and then continue | 20:35 |
| blackburn | sonney2k: have you seen the code? | 20:35 |
| @sonney2k | no | 20:35 |
| @sonney2k | n4nd0, btw how are you exams going? how many do you have left? | 20:36 |
| blackburn | sonney2k: http://pastebin.com/wyHWQnjG | 20:36 |
| blackburn | sonney2k: my intention was to include it as is but it looks I have to patch it seriously | 20:37 |
| blackburn | it is easier still though | 20:37 |
| blackburn | than do it from the paper :D | 20:37 |
| @sonney2k | blackburn, yeah well it is not too bad I would say | 20:38 |
| blackburn | sonney2k: they do loop unrolling manually sometimes and other stuff I do not really like | 20:38 |
| blackburn | and codestyle is random | 20:38 |
| blackburn | totally random | 20:38 |
| @sonney2k | certainly better than svmlight code :P | 20:38 |
| blackburn | hmm let me check svmlight | 20:38 |
| @sonney2k | blackburn, yeah and twonorm is not an extra function | 20:38 |
| @sonney2k | etc | 20:38 |
| blackburn | sonney2k: svmlight seems to be not that bad.. | 20:39 |
| blackburn | oh | 20:39 |
| @sonney2k | blackburn, what? | 20:39 |
| blackburn | no forget what I said | 20:40 |
| @sonney2k | a lot worse | 20:40 |
| blackburn | chosen[i]=9999 | 20:40 |
| blackburn | :D:D:D | 20:40 |
| blackburn | yaya | 20:40 |
| blackburn | wtf is going on | 20:40 |
| blackburn | omg | 20:40 |
| blackburn | sonney2k: what a detailed naming | 20:41 |
| blackburn | compute_matrices_for_optimization | 20:41 |
| blackburn | qp->opt_g0[i]=(learn_parm->eps[key[i]]-(float64_t)label[key[i]]*c[key[i]]) + qp->opt_g0[i]*(float64_t)label[key[i]]; | 20:41 |
| blackburn | I have no idea how to handle this code | 20:41 |
| * sonney2k has to stop watering plants before I have to swim home | 20:42 | |
| blackburn | what? | 20:42 |
| blackburn | sonney2k: are you watering plants and chat? | 20:42 |
| gsomix | sonney2k - master | 20:43 |
| n4nd0 | sonney2k, for the moment I have just one left on the 7th | 20:46 |
| n4nd0 | sonney2k, so I can come back to the work :) | 20:47 |
| n4nd0 | Shogun work I mean | 20:47 |
| blackburn | n4nd0: btw if you are free please consider fix doc warnings for JLCoverTree | 20:47 |
| n4nd0 | blackburn, all right | 20:48 |
| @sonney2k | gsomix, yes? | 20:49 |
| blackburn | :D | 20:49 |
| @sonney2k | gsomix, you can also call me $DEITY | 20:49 |
| @sonney2k | n4nd0, yeah that doc fix would be great | 20:49 |
| @sonney2k | pretty annoying to see these warnings all the time | 20:49 |
| @sonney2k | blackburn, yeah I am sitting outside in the garden | 20:50 |
| blackburn | sonney2k: heh that should be nice | 20:50 |
| @sonney2k | gsomix, so whats up? | 20:51 |
| gsomix | sonney2k, thanks for new word in my vocabulary | 20:52 |
| gsomix | sonney2k, I'm ready. | 20:52 |
| @sonney2k | gsomix, $ you mean :D | 20:52 |
| @sonney2k | gsomix, you did SGVector you mean? | 20:52 |
| gsomix | sonney2k, yep. | 20:52 |
| @sonney2k | ok, please show me | 20:53 |
| gsomix | sonney2k, bjjj, I'm ready to work, I mean. | 20:53 |
| @sonney2k | gsomix, hehe | 20:53 |
| @sonney2k | that is why I was asking | 20:53 |
| gsomix | ok, I see | 20:54 |
| @sonney2k | gsomix, then please go ahead. btw we don't need the sgvector& stuff / typemaps | 20:54 |
| @sonney2k | if this all works ok | 20:54 |
| @sonney2k | gsomix, btw the other thing that is needed and very related to sgvector | 20:55 |
| @sonney2k | is the remove Array/Array2/Array3 etc and replace it with SGVector/Matrix ... | 20:55 |
| @sonney2k | gsomix, but please one step at a time | 20:56 |
| @sonney2k | I will investigate which issues this will create... | 20:57 |
| @sonney2k | and of course there are some :/ | 20:59 |
| @sonney2k | CArray2<CPlifBase*> PEN_state_signals | 21:00 |
| @sonney2k | crap | 21:00 |
| @sonney2k | CArray3<T_STATES> psi | 21:00 |
| shogun-buildbot | build #224 of nightly_none is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_none/builds/224 | 21:00 |
| @sonney2k | ahh T_STATES is just uint16_t or so | 21:01 |
| @sonney2k | no problem w/ that | 21:01 |
| blackburn | ????? | 21:02 |
| gsomix | blackburn, ?? ???????, ??????. | 21:02 |
| gsomix | sonney2k, small question. Should I add a new macroses for ref/unref? This macroses in SGObject works with pointers. | 21:03 |
| CIA-64 | shogun: Sergey Lisitsyn master * rdc9d421 / src/shogun/classifier/svm/QPBSVMLib.cpp : Fixed wrong include - http://git.io/TLU5ag | 21:03 |
| @sonney2k | gsomix, investigating | 21:04 |
| CIA-64 | shogun: Sergey Lisitsyn master * reff395d / src/shogun/classifier/svm/SVMLight.cpp : Fixed wrong include - http://git.io/8ptmYQ | 21:06 |
| @sonney2k | gsomix, urgs that sucks... SG_REF(&vec) seems to be the only half way consistent thing | 21:06 |
| blackburn | sonney2k: will somebody fix HMM? :D | 21:08 |
| @sonney2k | gsomix, so lets just do it like that, if we prefer SG_VREF macros later (I don't think so) we can add them at some stage | 21:08 |
| @sonney2k | blackburn, what happened? | 21:08 |
| blackburn | sonney2k: parallel training | 21:09 |
| @sonney2k | blackburn, that is super tough | 21:09 |
| blackburn | yes I am too scaried to even take a look | 21:09 |
| @sonney2k | so I guess not | 21:09 |
| blackburn | nice :D | 21:09 |
| @sonney2k | the code for the parallel stuff in HMM is so messy that I can hardly understand it | 21:10 |
| @sonney2k | the only way to fix it is to compare outputs at each iteration of a parallel vs. sequential HMM | 21:10 |
| @sonney2k | *ly run HMM | 21:11 |
| @sonney2k | blackburn, do you get emails on all pull requests comments in github? | 21:12 |
| @sonney2k | because I for some reason only get some | 21:12 |
| blackburn | sonney2k: no, only for ones I had discussion in | 21:12 |
| @sonney2k | blackburn, I am just now reading harshits help request | 21:12 |
| blackburn | sonney2k: yes I did not receive it too | 21:13 |
| @sonney2k | and I think he might run things with different parameters | 21:13 |
| blackburn | sonney2k: yes I told that him before | 21:13 |
| blackburn | daaaaaaaaamn | 21:13 |
| @sonney2k | ok let me reply in the pull request | 21:13 |
| blackburn | I always miss something | 21:13 |
| CIA-64 | shogun: Sergey Lisitsyn master * r25b89ec / src/shogun/ui/SGInterface.cpp : Fixed wrong include - http://git.io/kg_gYQ | 21:14 |
| blackburn | my commit messages are terribly different today | 21:14 |
| @sonney2k | blackburn, git clean -dfx and do a full compile... | 21:16 |
| blackburn | sonney2k: should be totally fixed now.. | 21:17 |
| @sonney2k | or totally b0rken :D | 21:17 |
| blackburn | sonney2k: I did find shogun/classifier | xargs grep to find out wrong includes | 21:17 |
| blackburn | no idea how I missed svmlight but know why I missed ui | 21:17 |
| blackburn | sonney2k: actually you are closer to truth - nevertheless it compiles we are b0rken | 21:18 |
| blackburn | sonney2k: do you know what is SLEP for? | 21:19 |
| @sonney2k | no | 21:19 |
| shogun-buildbot | build #798 of libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/libshogun/builds/798 | 21:20 |
| blackburn | sonney2k: ^ ;) | 21:20 |
| @sonney2k | heh | 21:20 |
| blackburn | sonney2k: just fyi in particular we plan to integrate tree based stuff from slep | 21:20 |
| blackburn | cases are - features have tree structure | 21:20 |
| @sonney2k | blackburn, do you have any suggestion what we could do about CArray2<CPlifBase*> PEN? | 21:20 |
| blackburn | or tasks have structure | 21:20 |
| @sonney2k | i see | 21:21 |
| blackburn | or even outputs have structure of tree | 21:21 |
| @sonney2k | your tree labels | 21:21 |
| blackburn | sonney2k: let me check api of array2.. | 21:21 |
| @sonney2k | how are trees encoded? | 21:21 |
| blackburn | sonney2k: internally some lists but I will build some api on top of that | 21:21 |
| blackburn | list of indices actually | 21:21 |
| @sonney2k | blackburn, so you will create TreeFeatures ? | 21:22 |
| blackburn | sonney2k: noo | 21:22 |
| blackburn | it is only tree structure describing relations between features | 21:22 |
| blackburn | can be applied on top of any features | 21:22 |
| blackburn | (DotFeatures) | 21:22 |
| blackburn | I don't think we need to patch features for that | 21:22 |
| @sonney2k | blackburn, wait you mean within each feature vector - the relation between individual dims? | 21:23 |
| blackburn | sonney2k: yes | 21:23 |
| @sonney2k | blackburn, CArray2 is just a 2d-array | 21:23 |
| blackburn | yes I am checking | 21:23 |
| blackburn | why not to replace with sgmatrix? | 21:23 |
| @sonney2k | blackburn, yeah exactly | 21:23 |
| blackburn | ah CPlifBase.. | 21:23 |
| @sonney2k | yeah | 21:23 |
| blackburn | sonney2k: would it be infeasible to patch to use flattened indexing? | 21:24 |
| @sonney2k | I just don't want this code duplicateion | 21:24 |
| blackburn | it looks funny in fact | 21:24 |
| @sonney2k | blackburn, no but it is nice | 21:24 |
| blackburn | if you would need 4d array | 21:24 |
| blackburn | would it be Array4? :D | 21:24 |
| @sonney2k | heh | 21:25 |
| blackburn | sonney2k: then no idea how to redup code there | 21:25 |
| blackburn | I assume we deny non numeric in sg types | 21:26 |
| @sonney2k | blackburn, I simply want to get rid of Array{,2,3} and use the SGVec* stuff | 21:26 |
| blackburn | sonney2k: I thought you deny any pointers in SGVector? | 21:26 |
| @sonney2k | yeah | 21:26 |
| @sonney2k | we never needed 2d arrays so far IIRC | 21:27 |
| -!- n4nd0 [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 21:28 | |
| @sonney2k | and it creates huge overhead in swig interfaces | 21:28 |
| @sonney2k | since we have to support all types | 21:28 |
| @sonney2k | hmmhh what is this free_array for | 21:30 |
| @sonney2k | seems to be a nop | 21:30 |
| blackburn | sonney2k: which free_array? | 21:32 |
| @sonney2k | blackburn, I don't know if you like it but how about just moving this Array2/3 functionality into Dyn*Array | 21:32 |
| @sonney2k | I mean if we add some access operators called element(int i, int j, int k) ... | 21:32 |
| blackburn | sonney2k: I don't mind at all | 21:32 |
| @sonney2k | and other constructors accepting 2(or 3) indices | 21:33 |
| @sonney2k | it could just be inside the same thing | 21:33 |
| blackburn | to be honest I actually do not like this infrastructure at all.. :D | 21:33 |
| @sonney2k | I mean not necessary to have 3 classes for that | 21:33 |
| @sonney2k | whcih infrastructure? | 21:33 |
| blackburn | DynArray stuff, etc | 21:33 |
| @sonney2k | blackburn, the one in Array* | 21:33 |
| blackburn | I do not really understand why it is better than some stl stuff | 21:33 |
| @sonney2k | blackburn, great | 21:34 |
| @sonney2k | which stl stuff? | 21:34 |
| blackburn | sonney2k: why not to use std vector instead of dyn array? | 21:34 |
| blackburn | sonney2k: like in multiclass machines | 21:35 |
| blackburn | sonney2k: 2d 3d stuff can actually be done in place using macroses I think | 21:36 |
| @sonney2k | no macros | 21:38 |
| @sonney2k | just functions | 21:38 |
| blackburn | sonney2k: functions of dyn arrays? | 21:39 |
| -!- n4nd0 [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has joined #shogun | 21:40 | |
| @sonney2k | yes | 21:41 |
| -!- in3xes [~in3xes@49.14.101.92] has quit [Read error: Connection reset by peer] | 21:45 | |
| -!- n4nd0 [~n4nd0@190.Red-2-137-59.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 21:51 | |
| blackburn | In file included from ../shogun/lib/memory.h:16:0, | 21:52 |
| blackburn | from ../shogun/lib/common.h:15, | 21:52 |
| blackburn | from ../shogun/features/DotFeatures.h:15, | 21:52 |
| blackburn | from ../shogun/lib/slep/slep_tree_lsr.h:15, | 21:52 |
| blackburn | from lib/slep/slep_tree_lsr.cpp:11: | 21:52 |
| blackburn | /usr/include/stdio.h:30:1: error: expected unqualified-id before string constant | 21:52 |
| blackburn | O_O | 21:52 |
| blackburn | sonney2k: have you ever seen something like that? | 21:53 |
| @sonney2k | blackburn, yes but I don't remember | 21:54 |
| blackburn | sonney2k: could you please edit my name in your g+ post? ;) | 21:55 |
| blackburn | sonney2k: reason: forgotten ; in other included .h | 21:57 |
| @sonney2k | blackburn, Sergey? | 22:05 |
| @sonney2k | or sth else? | 22:05 |
| blackburn | yes, Lisitsyn | 22:05 |
| blackburn | Sergej Lisityn currently | 22:05 |
| blackburn | I am ok with j but last name is wrong ;) | 22:06 |
| @sonney2k | Sergey Lisitsyn then share it :D | 22:06 |
| blackburn | sonney2k: done ;) | 22:07 |
| @sonney2k | heh | 22:07 |
| @sonney2k | alright - I think adding CArray{1,2,3} to DynArray and DynamicArray should enable us to drop CArray* crap | 22:08 |
| blackburn | agree | 22:08 |
| gsomix | sonney2k, SG_REF(&vec) | hehe, but { if (x) { if ((x)->unref()==0) (x)=NULL; } } | 22:08 |
| @sonney2k | reduced compile time all good | 22:08 |
| @sonney2k | gsomix, yes? | 22:09 |
| @sonney2k | what is the problem? | 22:09 |
| @sonney2k | ahh | 22:09 |
| @sonney2k | (x)=NULL? | 22:09 |
| blackburn | loses pointer lol | 22:09 |
| @sonney2k | blackburn, even worse impossible | 22:09 |
| gsomix | sonney2k, aha. | 22:10 |
| @sonney2k | gsomix, so SG_VREF it is then... | 22:10 |
| blackburn | yay! managed to compile first version of tree regularized shit | 22:10 |
| blackburn | sonney2k: | 22:10 |
| blackburn | install: cannot stat `libshogun.a': No such file or directory | 22:10 |
| blackburn | I get this error sometimes | 22:10 |
| blackburn | what can be a cause? | 22:11 |
| @sonney2k | never seen it | 22:11 |
| @sonney2k | really *never* | 22:11 |
| blackburn | sonney2k: it stays until I clean up.. | 22:11 |
| @sonney2k | blackburn, sounds like some dependency in makefile is not ok. i guess only you have the qualification to produce this error :D | 22:12 |
| * gsomix is trying to defuse a new laptop. | 22:12 | |
| blackburn | sonney2k: autogenerated or set before? | 22:13 |
| blackburn | sonney2k: there are routines in slep that solving problem requiring W vector to be w1>w2>w3>...>wn :D | 22:14 |
| -!- karlnapf [~heiko@host109-148-116-163.range109-148.btcentralplus.com] has joined #shogun | 22:16 | |
| @sonney2k | blackburn, you mean increasing sparsity or reducting norm? | 22:17 |
| @sonney2k | reducing | 22:17 |
| blackburn | sonney2k: lasso problem *but* coefficients are decreasing | 22:18 |
| @sonney2k | ok makes sense | 22:19 |
| blackburn | sonney2k: looks like it would be hard to promote sparsity when features have wrong in means of influence order.. | 22:19 |
| blackburn | sonney2k: that's why slep is of interest not only in multitask scope | 22:19 |
| blackburn | there are a lot of other problem solvers | 22:19 |
| blackburn | however they share same thing | 22:20 |
| gsomix | sonney2k, I need your review. | 22:29 |
| -!- PhilTillet [~Philippe@npasserelle10.minet.net] has joined #shogun | 22:36 | |
| PhilTillet | hello everybodyy | 22:38 |
| blackburn | hi | 22:39 |
| @sonney2k | gsomix, done | 22:39 |
| gsomix | sonney2k, aha. | 22:40 |
| gsomix | sonney2k, so what about void free_vector()? I think it should go. | 22:41 |
| -!- karlnapf [~heiko@host109-148-116-163.range109-148.btcentralplus.com] has quit [Ping timeout: 276 seconds] | 22:41 | |
| @sonney2k | gsomix, yes indeed | 22:44 |
| @sonney2k | also destroy_vector | 22:45 |
| @sonney2k | gsomix, ^ | 22:45 |
| gsomix | sonney2k, and not needed to allocate m_refcount if do_free == false, isn't it? | 22:45 |
| @sonney2k | yes set to NULL and good | 22:46 |
| gsomix | ok | 22:46 |
| @sonney2k | but rename do_free | 22:46 |
| @sonney2k | to what I said in comment | 22:46 |
| @sonney2k | gsomix, once this is done nothing will compile | 22:47 |
| gsomix | sonney2k, aha. | 22:47 |
| @sonney2k | gsomix, so the quick fix is to replace vec.destroy_vector() and vec.free_vector() with SG_VUNREF(vec) | 22:48 |
| @sonney2k | once this compiles we commit this | 22:48 |
| @sonney2k | and gradually (with help of hopefully many others) fix the rest | 22:48 |
| @sonney2k | s/rest/the crashers/ | 22:48 |
| PhilTillet | sonney2k, is there any documentation I can find to get a sense of how svm_train() works? Is it SMO? | 22:50 |
| blackburn | huh | 22:51 |
| PhilTillet | blackburn, i've been super unclear? :p | 22:53 |
| blackburn | PhilTillet: svm_train() of? | 22:53 |
| PhilTillet | SVM.h | 22:53 |
| PhilTillet | :p | 22:53 |
| PhilTillet | wait no | 22:53 |
| PhilTillet | fail | 22:53 |
| PhilTillet | >< | 22:53 |
| PhilTillet | shogun_libsvm.cpp | 22:53 |
| PhilTillet | I heard libsvm was based on SMO, but not exactly SMO | 22:53 |
| @sonney2k | PhilTillet, look at http://shogun-toolbox.org/doc/en/current/classshogun_1_1CSVM.html | 22:54 |
| @sonney2k | which SVM do you mean :D | 22:54 |
| blackburn | we have a few :D | 22:54 |
| @sonney2k | gsomix, I have to sleep now will be back tomorrow evening... | 22:55 |
| @sonney2k | cu | 22:55 |
| PhilTillet | yep now I have read some litterature about svm training, chunking, interior points and SMO :p I want to start with SMO first, but I do not really know whether this is what libsvm implements :p | 22:55 |
| PhilTillet | good night sonney2k :) | 22:55 |
| gsomix | sonney2k, nite | 22:55 |
| blackburn | PhilTillet: are you familiar with dual / primal formulations? | 22:56 |
| PhilTillet | blackburn, well not super experienced but yes I know a bit about them | 22:56 |
| blackburn | formulations are the key I'd say | 22:56 |
| blackburn | PhilTillet: what do you want to learn exactly? | 22:57 |
| PhilTillet | I spent the last week reading a book about svms, but it is kinda complicated :p | 22:57 |
| PhilTillet | blackburn, nothing in particular, I want to start implementing something for OpenCL | 22:58 |
| PhilTillet | I thought about SMO cause Interior Points is somewhat not adapted to big datasets | 22:58 |
| PhilTillet | and chunking sounds outdated :p | 22:59 |
| blackburn | I think some gradient based methods would be more openclable | 22:59 |
| PhilTillet | well, no challenge :p it's just about using opencl-compatible linalg libs :p | 23:00 |
| PhilTillet | I have some papers who cuda-ized smo | 23:00 |
| PhilTillet | and had some impressive improvements ( 50x ...) | 23:00 |
| blackburn | no surprise there :) | 23:02 |
| PhilTillet | seems like a good challenge and it can be very fruitful :p | 23:02 |
| PhilTillet | I just do not know where to start :p is SMO what is used in classifier_libsvm.cpp? | 23:03 |
| blackburn | PhilTillet: http://www.csie.ntu.edu.tw/~cjlin/papers/libsvm.pdf libsvm is smo type but not exactly smo | 23:09 |
| PhilTillet | it's what I needed :) | 23:10 |
| PhilTillet | thanks ^^ | 23:10 |
| gsomix | good night guys | 23:17 |
| PhilTillet | good night:) | 23:17 |
| -!- gsomix [~gsomix@95.67.182.154] has quit [Ping timeout: 246 seconds] | 23:30 | |
| -!- blackburn [~qdrgsm@85.114.185.217] has quit [Quit: Leaving.] | 23:38 | |
| --- Log closed Mon Apr 30 00:00:37 2012 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!