Open in new window / Try shogun cloud
--- Log opened Tue Apr 10 00:00:19 2012
harshit_n4nd0: hey do you know how to open libSVM format files in libshogun ?00:01
n4nd0harshit_: I didn't know that libSVM has its own format :P00:01
n4nd0harshit_: do you know if there is something about that in LibSVM files?00:02
-!- harshit_ [~harshit@] has quit [Ping timeout: 244 seconds]00:08
-!- harshit_ [~harshit@] has joined #shogun00:08
-!- harshit_ [~harshit@] has quit [Remote host closed the connection]00:43
-!- n4nd0 [] has quit [Quit: leaving]01:43
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking]01:46
-!- wiking [] has joined #shogun02:13
-!- wiking [] has quit [Changing host]02:13
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun02:13
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]02:13
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun02:14
-!- wiking_ [] has joined #shogun02:17
-!- wiking_ [] has quit [Changing host]02:17
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun02:17
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 244 seconds]02:21
-!- wiking_ is now known as wiking02:21
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking]02:43
-!- av3ngr [av3ngr@nat/redhat/x-uzcgjuqrebqavizk] has joined #shogun03:21
-!- av3ngr [av3ngr@nat/redhat/x-uzcgjuqrebqavizk] has quit [Quit: That's all folks!]03:57
-!- muddo [~muddo@gateway/tor-sasl/muddo] has quit [Quit: Leaving]04:34
-!- pluskid [~chatzilla@] has joined #shogun05:01
-!- av3ngr [av3ngr@nat/redhat/x-hzfodrrevubortjd] has joined #shogun05:32
-!- blackburn [~qdrgsm@] has joined #shogun06:09
CIA-64shogun: Viktor Gal master * r58ebbf0 / (3 files in 2 dirs): PNorm: changes suggested by Soeren -
CIA-64shogun: Viktor Gal master * r67aca90 / src/shogun/mathematics/Math.h :06:13
CIA-64shogun: Fix qnorm calculation06:13
CIA-64shogun: absolute value should be taken of each element before calculating06:13
CIA-64shogun: the q power of the element -
CIA-64shogun: Sergey Lisitsyn master * ra690dd7 / (3 files in 2 dirs): Merge branch 'nearest_centroid' of git:// -
CIA-64shogun: Sergey Lisitsyn master * r73db76e / (7 files in 3 dirs): Merge branch 'master' of git:// -
-!- blackburn [~qdrgsm@] has quit [Ping timeout: 244 seconds]06:28
-!- n4nd0 [] has joined #shogun07:56
-!- genix [~gsomix@] has quit [Ping timeout: 240 seconds]08:06
@sonney2kn4nd0, btw did you try to get OvO to work with heikos new subsetting stuff?08:19
n4nd0sonney2k: blackburn told me that there was still one thing missing, that it had to be added for the labels too08:20
n4nd0sonney2k: he said he would take care of it08:20
n4nd0sonney2k: I am working with JL's cover tree for the moment08:22
-!- genix [~gsomix@] has joined #shogun08:22
n4nd0have to go, see you later08:25
-!- n4nd0 [] has quit [Quit: leaving]08:25
-!- av3ngr [av3ngr@nat/redhat/x-hzfodrrevubortjd] has quit [Remote host closed the connection]08:50
-!- sonne|work [~sonnenbu@] has joined #shogun08:53
-!- pluskid [~chatzilla@] has quit [Remote host closed the connection]09:24
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun09:34
sonne|workwiking: so the qnorm was b0rken?09:42
wikinga bit09:42
sonne|worka bit?09:42
sonne|workeither broken or working :)09:42
sonne|workwhat was wrong?09:42
wikingCMath::pow(x[i], q)09:43
wikingfor q mod 2 =0 it was working09:43
wikingfor q mod 2 =1 it was wrong09:43
wikingas it should have been CMath::pow(fabs(x[i]), q)09:43
sonne|workso the fabs was missing?09:44
sonne|workuhh oh09:44
sonne|workthat would explain why we had some instability in the MKL algorithm09:45
sonne|workgetting NaNs09:45
* sonne|work smacks head09:45
sonne|works/mkl/q-norm mkl/09:45
wikingbut now my cluster's hard drive is broken09:46
wikingand i have 2 days to submit my paper09:46
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]09:47
-!- wiking [] has joined #shogun09:47
-!- wiking [] has quit [Changing host]09:47
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun09:47
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun09:55
-!- wiking_ [~wiking@huwico/staff/wiking] has quit [Client Quit]09:55
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 244 seconds]09:58
-!- V[i]ctor [] has quit [Quit: Leaving.]10:11
-!- V[i]ctor [] has joined #shogun10:12
-!- V[i]ctor [] has quit [Client Quit]10:14
-!- Marty28 [] has joined #shogun11:18
genixhi all11:20
Marty28The R?tsch group page at T?bingen is gone as the group is gone. This affects some shogun tutorial pages. When will you move the links?11:22
-!- Marty28 [] has quit [Ping timeout: 245 seconds]11:43
-!- Marty28 [] has joined #shogun11:51
-!- PSmitAalto [82e9b263@gateway/web/freenode/ip.] has joined #shogun11:54
sonne|workMarty28: I guess we will just remove these links - shogun doc has the tutorial now12:00
PSmitAaltoHey all12:03
PSmitAaltoSmall question about the cache size of a kernel12:03
PSmitAaltohow should I chose this, and how can I check how much cache was actually used?12:03
sonne|workPSmitAalto: the more the better - it will limit requirements by #elements in kernel :)12:04
PSmitAaltoBut if I define more then necessary, will I be wasting memory?12:06
Marty28sonne: thx12:11
-!- n4nd0 [] has joined #shogun12:20
-!- Marty28 [] has quit [Quit: ChatZilla [Firefox 11.0/20120312181643]]12:21
sonne|workn4nd0: so how does the covercode look like?12:26
n4nd0sonne|work: it is taking me some time to get used to the code and how to use it12:26
n4nd0sonne|work: I am preparing a small test to benchmark JL's code and compare it to shogun so we will know how much improvement we should expect12:27
sonne|workI can imagine so..12:27
n4nd0sonne|work: for the tests I have done so far it looks pretty fast, the construction was taking nothing compared to the previous one12:27
n4nd0less than 0.1 (s) if I remember correctly12:28
n4nd0sonne|work: the query time was nice too12:28
n4nd0I am going to try to compare the output now ... apart from being fast it would be interesting if it gives the correct results :D12:29
sonne|workI can design arbitrarily fast algorithms that produce wrong results :D12:30
n4nd0haha exactly12:30
n4nd0I want to be sure that this cover tree is not one of those12:30
n4nd0sonne|work: so it is tonight when they say about the number of slots for each organization, isn't it?12:33
sonne|workno tomorrow12:34
-!- wiking [] has joined #shogun12:35
-!- wiking [] has quit [Changing host]12:35
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun12:35
n4nd0aham, ok12:36
sonne|workCarol said: I will announce slot allocations Wednesday, 11 April after the close of business pacific time.12:50
sonne|workso it will even be April 1212:50
sonne|workn4nd0: ^12:51
genixn4nd0, hello12:52
n4nd0sonne|work: the 12th then12:52
n4nd0genix: hey!12:52
wikingsonney2k: u reckon mkl would get better results now with the qnorm being fixed?12:52
-!- PSmitAalto [82e9b263@gateway/web/freenode/ip.] has quit [Quit: Page closed]12:52
wikingalthough i guess it'll only matter in case of q being odd12:53
sonne|workso how much?12:53
sonne|workanyway I only have good experience with q=212:53
genixn4nd0, what about memory leaks in covertree?12:53
n4nd0genix: well, I got pretty lost there12:54
wikingalthough i cannot run any tests now since my cluster died and the raid is just rebuilding itself...12:54
n4nd0genix: valgrind didn't help me that much either12:55
wikingso i have to wait at least 6 hours to get it fixed...12:55
n4nd0genix: so I started to look at JL's implementation, the one on his webpage12:55
-!- genix is now known as gsomix13:05
-!- PhilTillet [~android@] has joined #shogun13:13
-!- pluskid [~chatzilla@] has joined #shogun13:14
-!- n4nd0_ [] has joined #shogun13:33
-!- n4nd0 [] has quit [Ping timeout: 246 seconds]13:34
-!- n4nd0_ [] has quit [Client Quit]13:38
-!- n4nd0 [] has joined #shogun13:38
-!- PhilTillet2 [~android@] has joined #shogun13:51
-!- PhilTillet [~android@] has quit [Ping timeout: 244 seconds]13:51
-!- n4nd0 [] has quit [Read error: Connection reset by peer]13:51
-!- PhilTillet2 [~android@] has quit [Remote host closed the connection]13:51
-!- n4nd0 [] has joined #shogun13:56
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun14:22
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 252 seconds]14:25
-!- wiking_ is now known as wiking14:25
-!- muddo [~muddo@gateway/tor-sasl/muddo] has joined #shogun14:35
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection]15:28
-!- wiking [] has joined #shogun15:28
-!- wiking [] has quit [Changing host]15:28
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun15:28
gsomixsonney2k, sonne|work around?15:28
-!- Marty28 [] has joined #shogun15:49
-!- Marty28 [] has quit [Remote host closed the connection]15:53
-!- blackburn [5bdfb203@gateway/web/freenode/ip.] has joined #shogun16:01
blackburnsonne|work: we definitely need your help there with traffic16:02
n4nd0gsomix: hey, I have some problems with the cover tree, do you have a moment?16:08
gsomixn4nd0, yep16:09
n4nd0gsomix: did you manage to make tests with JL's tree to see what are the nearest neigbors of some query points?16:10
n4nd0gsomix: I am trying to make that now, it should be easy, but the output I get makes no sense to me16:10
blackburnn4nd0: uh complicated task right? ;)16:10
gsomix>> makes no sense to me16:11
gsomixwhat do you mean?16:11
n4nd0blackburn: I feel completely retarded for real :S16:11
blackburnn4nd0: you always can leave it if you feel unhappy with it16:11
n4nd0gsomix: so to start with, I query 10 points with k 1016:12
n4nd0gsomix: that should ouput 100 points, 10 nearest neighbors for each one of the query points16:12
n4nd0gsomix: I don't know why but I get only 19 points16:12
n4nd0gsomix: 10 for the first one, and one for each of the others16:13
blackburnn4nd0: at university I had a spare time and tried that precompute stuff on lle16:13
n4nd0gsomix: and other thing that makes probably no much sense is that the first two points that are output are always the same16:13
blackburnn4nd0: surprisingly w/o precomputing it is faster16:13
n4nd0blackburn: haha really?16:14
blackburnn4nd0: yes, do you have any explanation? I have16:14
n4nd0blackburn: it might be that all the distances that are computed are not used16:15
blackburnn4nd0: no they are and not only once16:15
blackburnsomething more interesting16:15
n4nd0blackburn: that it is not so different to do vector[i + j*N] than to compute the distance between two vectors?16:15
gsomixn4nd0, strange16:16
n4nd0blackburn: low dimensional vectors maybe?16:16
gsomixn4nd0, unfortunately, my queries were composed of a single point16:16
blackburnyes 3d16:16
blackburnbut why is it faster then?16:16
blackburn[i,j] and [j,i]16:16
n4nd0blackburn: is the matrix computed without taking into account that it is triangular?16:17
n4nd0symmetric is the word for that sorry, not triangular16:17
n4nd0gsomix: but using just one point, did you get coherent results?16:17
blackburnn4nd0: not really I think it is16:18
blackburnn4nd0: cache misses16:18
gsomixn4nd0, yep. however, covertree returns the nearest neighbors are not in order.16:19
blackburnit sets [i,j] and [j,i]16:19
blackburnand it takes a WHILE16:19
n4nd0blackburn: it takes a while to set the value in a matrix?16:19
blackburnn4nd0: to jump from [i,j] to [j,i]16:19
n4nd0blackburn: aham, ok I see16:20
n4nd0blackburn: lot of jumps to far places16:20
blackburnyeah and while it is predicted that you will go to [i,j+1]16:20
blackburnyou have to jump again16:21
n4nd0blackburn: but anyway, my intuition is that it shouldn't make a big difference for low dimensional vectors16:21
n4nd0blackburn: to re-compute distances there is not very expencise16:21
blackburnyes it is faster w/o precomputing that stuff16:21
blackburnhowever if distance are really expensive it worths trying16:21
n4nd0yes, I agree16:21
n4nd0gsomix: ok, but even if they are not in order, it is given me twice the same point for example, weird thing16:22
-!- V[i]ctor [] has joined #shogun16:31
sonne|workblackburn: will you look at pluskid's LARS stuff16:48
blackburnsonne|work: yes16:48
n4nd0blackburn: alternative solution16:50
blackburnn4nd0: for?16:51
blackburnsonne|work: it is in progress so we can wait a little more16:52
n4nd0blackburn: cover tree, the code that pluskid suggested, the one that is in github is pretty neat and clear16:52
blackburnn4nd0: feel free :)16:52
n4nd0blackburn: I think I'll port that one :)16:53
n4nd0blackburn: the code uses boost quite a bit and stuff16:56
n4nd0blackburn: what do you think is best, to do some wrappers or to adapt it to shogun?16:56
blackburnwhich boost things?16:56
n4nd0blackburn: it is about 200 lines of understandable code so it shouldn't be a madness to port it16:56
n4nd0blackburn: hash table (unordered map) and smart pointers16:57
blackburnjust be sure it is rather fast than not :)16:57
n4nd0blackburn: yes, it comes with a test to compare it to brute force and it is faster than that16:57
n4nd0in any case16:57
n4nd0I will first compare it to our KNN16:58
n4nd0before starting to port and stuff16:58
blackburnn4nd0: it is strange still for me16:58
blackburnLLE takes 4.16s to embed 10000 vectors16:58
blackburnwith k = 1016:58
n4nd0I don't really understand it16:59
n4nd0gtg now17:00
n4nd0see you later!17:00
blackburnsee you17:00
-!- n4nd0 [] has quit [Ping timeout: 265 seconds]17:06
pluskid what's wrong with JL's cover tree?17:06
blackburnpluskid: wrong karma probably :)17:07
pluskidblackburn: karma?17:07
blackburnit gives headache for ever one trying to integrate it to shogun17:08
pluskidso is it actually faster?17:08
blackburnno idea17:08
blackburncan be17:08
pluskidhaven't tested yet?17:08
pluskidI scanned the previous log17:09
blackburnI didn't17:09
pluskidit produce strange result?17:09
pluskidBTW, have you guys finally got JL's reply (and my reply) in the mailing list?17:09
blackburnno there were only your messages17:10
pluskidanyway, if there's problems, maybe we can seek him for help17:10
pluskidhe seems to be a nice person17:10
pluskidand cares about cover tree17:10
blackburnyeah but we need to formulate the problem17:11
pluskidhmm, seem not an easy task17:11
blackburntime to go home !17:12
blackburnsee you17:12
pluskidgot to sleep now17:12
-!- blackburn [5bdfb203@gateway/web/freenode/ip.] has quit [Quit: Page closed]17:12
-!- pluskid [~chatzilla@] has quit [Quit: ChatZilla [Firefox 11.0/20120314124128]]17:22
-!- V[i]ctor [] has quit [Quit: Leaving.]17:29
-!- V[i]ctor [] has joined #shogun17:36
wikingmmm is there a chance that GMM clusterer can handle 5*10^6 vectors and do the clustering on it?17:54
-!- V[i]ctor [] has quit [Quit: Leaving.]18:17
-!- V[i]ctor [] has joined #shogun18:56
@sonney2knahh I don't like having boost as yet another dependency19:13
@sonney2kwe already have too many of them19:13
@sonney2kdoes anyone want to fix some warnings ?19:14
@sonney2kbtw wiking they are also in your code ^ :)19:14
-!- n4nd0 [] has joined #shogun19:18
-!- n4nd0 [] has quit [Client Quit]19:19
gsomixsonney2k, hey19:23
-!- V[i]ctor [] has quit [Quit: Leaving.]19:24
gsomixsonney2k, I'm glad to see you. I have some questions.19:25
gsomix>> then first thing to do is to convert everything from returning copies of SGVector to references19:25
gsomixwhy should we use references instead of pointers?19:25
-!- V[i]ctor [] has joined #shogun19:26
@sonney2kgsomix, I think it would be nice if one can just do a[0] for an SGVector19:27
@sonney2kso when SGVector& a is a parameter one can do this19:27
@sonney2kfor SGVector* a one woul dhave to (*a)[0] ...19:28
@sonney2kgsomix, would you prefer pointers?19:28
@sonney2kthe other reason next to this is that one doesn't have to change current code19:28
@sonney2kjust adding a & won't hurt *that* much19:29
gsomixsonney2k, yes, I would prefer pointers. I think SGVector* is more "transparent".19:30
gsomix>> one doesn't have to change current code19:30
gsomixsonney2k, I think it's wrong. We'll have to fix all SGVector variables on SGVector&.19:34
gsomixit's equivalent to SGVector -> SGVector* corrections19:37
gsomixsonney2k, isn't it?19:37
gsomixsorry. I forgot about dereferencing. =___=19:39
gsomixanyway I prefer pointers19:39
-!- V[i]ctor [] has quit [Quit: Leaving.]19:40
-!- V[i]ctor [] has joined #shogun19:41
@sonney2kgsomix, hmmhh talk to n4nd0 / blackburn / wiking and convince them :)19:49
@sonney2ksry gtg19:49
wikingconvince me19:50
gsomixsonney2k, ok. su19:50
gsomixwiking, yo. we want to make reference counting for the SGVector.19:52
gsomixwhich is better: all of the SGVectors in code is a reference or a pointer?19:52
wikingaaah that'd be great19:52
wikingi know people hate pointers and c++ has a fancy reference shit19:53
wikingbut i prefer pointers19:54
wikingalthough yeah if you change everything to pointers19:54
wikingyou'll have trouble with rewriting some code...19:54
wikingwhile having a reference it'll just be fine19:54
wikingso sonney2k is right about & being an easier solution19:54
wikingand you don't have to care about null pointer references :P19:55
wikingand 'somepointer' is either a null pointer or a bad mem addr19:55
wikingi mean what you could do with a pointer case of course that when you do the script for doing the SGVector<>* a for the function argument19:57
wikingthen simply add something like this right after the function call19:57
wikingi mean function definition19:58
gsomixwiking, I see19:58
wikingASSERT(pointer check);19:58
wikingSGVector<> = *a;19:58
wikingSGVector<>b = *a;19:58
wikingand then u use b normally ;)19:58
wikingso that you can do b[0]19:58
wikingas is19:58
wikingso it's really a matter of taste... but if you follow c++ standards and check STL things as well19:59
wikingyou usually pass containers by their reference19:59
wikingvery seldomly you do something like function (std::vector<double>* a);20:00
wikingbut anyhow having either of them will save us a lot of memory on the stack ;)20:00
wikingso now if you ask me again i'd vote as well for reference... :P20:00
wikingeven if i prefer pointers more20:00
gsomixwiking, hah. :) thank you very much20:01
wikinggsomix: sorry :(20:02
gsomixwiking, wut?20:02
wikingas you saw i wanted to go with pointers as well... but then again if you consider now redoing all the coooode.... it's safer to go with a reference :(20:02
gsomixwiking, you and sonney2k are saying the right things. :)20:07
-!- n4nd0 [] has joined #shogun20:21
n4nd0gsomix: I vote for references too :)20:28
gsomixn4nd0, ok. thanks20:29
n4nd0gsomix: will you try to convince for pointers? :)20:29
gsomixn4nd0, no, I will not :)20:31
-!- harshit_ [~harshit@] has joined #shogun20:48
n4nd0harshit_: hey! how is it going with semi-supervised learning?20:49
harshit_n4nd0: Almost done ! But there is one problem though20:49
n4nd0harshit_: oh! that was fast man20:49
harshit_SVMlin website has a broken link to its examples20:50
n4nd0too bad20:50
harshit_have a look:
-!- PhilTillet [] has joined #shogun20:50
harshit_try to download examples.tar.gz20:50
harshit_I have sent a mail to its author, Hope he replies and take action!20:51
n4nd0yeah, those links are dead20:52
harshit_n4nd0: And the task was not too difficult, I just had to create a wrapper class20:52
n4nd0harshit_: aham, ok20:52
harshit_:( cant succeed without those :(20:52
harshit_will ask blackburn, maybe he have the archived files with him20:53
harshit_n4nd0: Whats the status of your covertree ?20:53
harshit_I think thats merged, am I right ?20:54
n4nd0harshit_: well the thing that is merged is integration in KNN20:54
n4nd0harshit_: but our current cover tree structure is too slow20:54
n4nd0at least according to my tests20:54
harshit_ohk..Is that the problem with the algo or implementation ?20:54
n4nd0so I am working on the port of another cover tree20:55
harshit_Any news about gsoc20:56
n4nd0none AFAIK20:56
harshit_hope shogun gets enough seats !20:57
n4nd0harshit_: cruza los dedos ;)20:58
harshit_yo tambian :)20:59
shogun-buildbotbuild #205 of nightly_none is complete: Failure [failed compile]  Build details are at
-!- PhilTillet [] has quit [Ping timeout: 260 seconds]21:03
-!- muddo [~muddo@gateway/tor-sasl/muddo] has quit [Ping timeout: 276 seconds]21:22
-!- PhilTillet [] has joined #shogun21:41
-!- V[i]ctor [] has quit [Ping timeout: 240 seconds]21:44
wikingmmmm iterative pca? :)22:00
wikinganyone ?:)22:00
wikingi mean sequential :)))22:00
wikingi ran out of ram :>22:00
-!- blackburn [5bde8018@gateway/web/freenode/ip.] has joined #shogun22:24
blackburnhey there22:25
blackburnwiking: having problems with kinda largescale?22:26
wikinghehehe yeah22:26
blackburnwiking: well I have some tools for DR however would not work on such sizes22:33
wikingwhat is the ascii code for scroll lock :)))22:33
blackburnno idea heh22:34
blackburnwiking: are you aware of some *dynamic* sparse matrix class/struct in C/C++?22:46
wikingmmm not really22:46
harshit_blackburn: Is there any built in function in shogun, Which can open and parse libsvm data files ?22:47
blackburnharshit_: yes, libsvmfile22:48
harshit_okay, thanks ..!22:48
blackburnharshit_: I am afraid it is not complete22:49
blackburnonly headers there22:49
harshit_then I think i should use libsvm's mex file22:49
harshit_in octave22:49
blackburnyeah probably22:49
harshit_But I wanted to make an example which could be portable .. !22:50
harshit_blackburn: Any idea on how to convert libsvm datafiles to normal txt format22:50
harshit_ohh sry I think i can do that22:50
harshit_octave can help me save22:51
blackburnwell if you can read it from octave just save from octave ;)22:51
harshit_yeah exactly22:51
-!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking]22:52
blackburnsonney2k: here?22:54
gsomixgood night, guys23:03
n4nd0good night gsomix23:04
blackburnn4nd0: how are your covertreeing?23:04
n4nd0blackburn: awesome :D23:05
blackburndoes it work?23:05
gsomixn4nd0, great!23:06
blackburnn4nd0: any preliminary speedup rate?23:06
n4nd0blackburn: not yet :(23:06
n4nd0blackburn: I need a bit more time23:07
blackburnno problem :)23:07
n4nd0blackburn: take a look here a moment, KNN.cpp:15723:07
n4nd0I don't think that ASSERT makes sense23:07
n4nd0it is like number of neighbors k has to be equal than the number of points to query23:08
n4nd0but we may want to find out the 2-nearest neigbors of just one point23:08
-!- wiking [] has joined #shogun23:10
-!- wiking [] has quit [Changing host]23:10
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun23:10
n4nd0blackburn: do you see what I mean?23:10
-!- blackburn [5bde8018@gateway/web/freenode/ip.] has quit [Ping timeout: 245 seconds]23:11
-!- blackburn [5bde8018@gateway/web/freenode/ip.] has joined #shogun23:11
blackburndamned connection23:11
blackburnn4nd0: what s up with 15723:11
n4nd0I don't think that ASSERT makes sense23:12
n4nd0it is like number of neighbors k has to be equal than the number of points to query23:12
n4nd0but we may want to find out the 2-nearest neighbors of just one point23:12
n4nd0(I just copied+pasted :))23:13
blackburnhow can k be greater than total number of objects?23:13
n4nd0because rhs is not the number of training objects23:14
n4nd0but the number of test objects23:14
n4nd0think of it23:14
blackburnhah yes sure you are right23:14
n4nd0after 5 trials of doing 2-nearest neighbor of one vector I realized23:15
n4nd0do you want to change it and we save ourselves pull request and stuff?23:15
n4nd0I can do it otherwise, it would be no problem23:16
blackburnyes but next morning probably23:16
n4nd0sure, no problem23:16
blackburnn4nd0: I don't like 217 line also23:17
blackburnI did add that but that makes no sense for me now23:17
blackburnit is kind of weighting23:17
blackburnq q^2 q^3 ...23:17
blackburnactually it is ~ 1-NN I think23:18
blackburnwill remove that23:18
blackburnokay only one more day and one more night and things will become clearer23:19
n4nd0yeah, the weighting23:20
n4nd0apart that I think that it doesn't match with the one it is presented in the doxygen documentation23:21
n4nd0there it appears that there is one different weight23:21
blackburnn4nd0: why?23:21
blackburnq^i stil23:21
n4nd0I mean one different for every neighbor23:21
n4nd0maybe I read it bad23:21
blackburncorrect for me23:22
n4nd0some results23:22
n4nd0Shogun's time: 00:00:00.46650823:22
n4nd0Build time 00:00:00.06096323:22
n4nd0CoverTree time (cover_tree) 00:00:00.07883923:22
blackburnnot example but neighbor23:22
blackburn(should be)23:22
n4nd0I have to double checked that everything is correct though23:23
blackburnn4nd0: 0.07s?23:23
n4nd0yes, it is .5 agains .0723:24
n4nd01000 training23:24
n4nd01000 queries23:24
blackburn>5 times faster?23:24
n4nd0K = 523:24
n4nd0not taking into account build time23:25
blackburntry 10000? ;)23:25
n4nd0for 10000 queries23:25
n4nd0Shogun's time: 00:00:04.80486223:26
n4nd0Build time 00:00:00.06713423:26
n4nd0Out time (cover_tree) 00:00:00.77240823:26
n4nd0really nice23:26
blackburnhmmm it scales linearly23:26
n4nd0but let's wait until I've double check the results23:26
blackburnn4nd0: do you test it standalone now?23:26
n4nd0blackburn: do you mean not integrated in shogun?23:27
n4nd0and it is not that it scales linearly23:27
n4nd0I just increased the number of queries23:27
n4nd0i.e. the size of the cover tree is the same23:27
blackburnn4nd0: why? N=10*N and time is similar23:28
n4nd0yes but I mean23:28
n4nd0in # queries is obvious that it is going t oscale linearly23:28
n4nd0it is like shogun's time23:28
n4nd0it "scaled linearly" even if doing quicksort is N?log(N)23:29
blackburnah sure I'm stupid a little23:29
blackburnhow does it scale wrt to trainset?23:29
n4nd0it is just late :)23:29
n4nd0it scales to a seg fault :P23:30
blackburninteresting things are23:30
n4nd0I am doing something wrong in my example23:30
blackburnscalability wrt to K23:30
blackburnand wrt to train N23:30
blackburnlol large-fault learning23:31
n4nd0I think I am wasting too much memory in my example23:31
blackburnhowever this constant plays a role sure23:31
n4nd0but let me try with the example that it is not compared to shogun's23:31
n4nd0this is one query when we manage 1000 training vectors23:32
n4nd0Build time 00:00:00.21597223:32
n4nd0Out time (linear) 00:00:00.00166523:32
n4nd0Out time (cover_tree) 00:00:00.00062923:32
n4nd0linear is doing something similar to the quick sort approx23:32
blackburnno, one query is not so informative23:33
blackburncan bump :)23:33
n4nd0in any case if you want to see23:33
n4nd0Build time 00:00:15.86803423:33
n4nd0Out time (linear) 00:00:00.01884523:33
n4nd0Out time (cover_tree) 00:00:00.00339023:33
n4nd0I think it is informative though23:33
n4nd0the increment with brute force is bigger than the increment with cover tree23:34
n4nd0in proportion23:34
n4nd0but here you can see the big disadvantage of this cover tree implementation23:34
n4nd0with 100023:34
n4nd0Build time 00:00:00.21597223:34
n4nd0with 1000023:34
n4nd0Build time 00:00:15.86803423:34
n4nd0it is crazy23:34
n4nd0for 100000 it took like 20 minutes23:35
blackburnwhy so? strange23:35
n4nd0I have been doing some research on cover tree23:35
n4nd0(there is a nice video lecture by JL)23:35
n4nd0there are different methods to build it23:35
n4nd0the best is one call23:35
n4nd0batch construction23:36
n4nd0the best in that it is the fastest23:38
n4nd0in JL's code it was all the time below 0.0 (s)23:38
blackburnn4nd0: oh may be this weekend if I manage to complete some univ stuff I'll try to integrate JL's again23:38
n4nd0I think that maybe I can start porting this one I am using23:40
n4nd0and later we could include batch construction and other stuff23:40
blackburnmay be we will get insight and it will become clear how JL's one works23:41
n4nd0and as I told you I consider that it shouldn't take much time to port this cover tree23:43
blackburnwhich this?23:44
n4nd0the one I am using now23:44
blackburnbut no batch there?23:44
n4nd0no batch there23:44
blackburnbad, right?23:45
n4nd0mmm idk23:45
n4nd0construction is just construction23:45
n4nd0it shouldn't be that important23:45
blackburnimportant for me - I need to construct covertree each time I do embedding23:46
n4nd0then it is important too23:46
--- Log closed Wed Apr 11 00:00:00 2012