| --- Log opened Mon Jun 27 00:00:24 2011 | ||
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 00:03 | |
| -!- blackburn1 [~blackburn@31.28.40.202] has joined #shogun | 00:55 | |
| -!- blackburn [~blackburn@31.28.40.202] has quit [Read error: No route to host] | 00:55 | |
| -!- blackburn1 [~blackburn@31.28.40.202] has quit [Quit: Leaving.] | 01:07 | |
| -!- alesis-novik [~alesis@188.74.87.206] has quit [Quit: I'll be Bach] | 03:19 | |
| -!- heiko [~heiko@main.uni-duisburg.de] has joined #shogun | 09:34 | |
| heiko | sonney2k, are you there? | 10:15 |
|---|---|---|
| @sonney2k | yes | 10:15 |
| heiko | i have a question for the subset stuff we talked about | 10:15 |
| heiko | you suggested to just add a getter for the subset variable and then to call set/remove methods directly on it | 10:15 |
| heiko | However, some feature classes require some post set/remove stuff | 10:16 |
| heiko | such as determine_maximum_string_length for string features | 10:16 |
| heiko | Yet, this was handled by the wrapper methods | 10:17 |
| heiko | I thought about perhaps registering a callback function or something | 10:18 |
| heiko | or do you have a better idea? | 10:18 |
| -!- blackburn [~blackburn@31.28.40.202] has joined #shogun | 10:26 | |
| @sonney2k | heiko, I guess I don't understand the problem | 10:27 |
| heiko | if you have a subset | 10:27 |
| heiko | and you remove it | 10:27 |
| @sonney2k | I meant the setters / getters are needed only to get the actual subset indices | 10:28 |
| @sonney2k | resp. set them | 10:28 |
| heiko | then, it is sometimes necessary to do some stuff afterwards | 10:28 |
| heiko | for example the maximum string length | 10:28 |
| heiko | changes if the subset changes | 10:28 |
| @sonney2k | heiko, ok - but? | 10:28 |
| heiko | so, then if a subset is set, the maximum string length is wrong | 10:28 |
| @sonney2k | heiko, well you have to update it of course after setting | 10:29 |
| heiko | ok thats my point | 10:29 |
| heiko | if I call string_features::get_subset::set_idx | 10:29 |
| heiko | then string_features does not know when the subset has changed | 10:29 |
| @sonney2k | heiko, now I understand - I was assuming that you create a subset object and set that | 10:30 |
| @sonney2k | not change the index of an existing subset object | 10:30 |
| heiko | ok, I see | 10:31 |
| heiko | so the subsets are never changed but alyways newly created? | 10:31 |
| @sonney2k | I would do it this way | 10:32 |
| heiko | Ok, good that I asked then :) | 10:32 |
| heiko | then the set_subset methods of CSubset can go | 10:33 |
| @sonney2k | I am not really sure if this is consistent to what we do usually | 10:33 |
| * sonney2k is pondering | 10:33 | |
| heiko | mmh --- | 10:33 |
| @sonney2k | with features - if you change the matrix - but applied preprocs before I don't think preprocs will be applied again | 10:34 |
| @sonney2k | so I would say to have some kind of 'update' function | 10:34 |
| @sonney2k | that can be called manually | 10:34 |
| heiko | Can you explain this some more? | 10:35 |
| @sonney2k | heiko, in the respective feature class you could have some update function that can be called manually to e.g. check for string length, compute nnz elements etc | 10:39 |
| heiko | ok, but this may be simply called in the get/set methods for the CSubset variable | 10:40 |
| @sonney2k | heiko, yes or manually if someone changes just the idx in subset | 10:41 |
| heiko | but this should not be possible, or? | 10:42 |
| @sonney2k | heiko, if documented supported it could - as you wish | 10:55 |
| heiko | ok | 10:55 |
| * blackburn is wondering how it would look like if sonney2k and heiko was discussing it in deutsch | 11:01 | |
| heiko | hehe :) it would look very deutsch | 11:01 |
| blackburn | how much deutsch? :D | 11:02 |
| @sonney2k | blackburn, ganz doll deutsch eben | 11:02 |
| blackburn | sonney2k: last word sounds very rude in russian :D | 11:02 |
| @sonney2k | blackburn, german is a rude language :D | 11:03 |
| heiko | sonney2k | 11:05 |
| heiko | another question for the subset stufdf | 11:05 |
| heiko | If the num_vectors variable is not touched | 11:05 |
| heiko | then its usage has to be replaced by some get_num_vectors() method which returns the number of vectors of the possibly set subset | 11:05 |
| heiko | Initialliy, before gsoc, we had something like this | 11:06 |
| heiko | but you suggested to use another variable to avoid overhead | 11:06 |
| heiko | but now, If this is removed again and we have only one variable and this get_num_vectors method, I have to change it all over again | 11:07 |
| @sonney2k | you are right (as always) | 11:08 |
| @sonney2k | so one thing is more readable the other is faster | 11:08 |
| @sonney2k | (maybe) | 11:08 |
| @sonney2k | actually - I prefer the more readable variant in this case | 11:08 |
| @sonney2k | in every performance critical loop one could fetch the number of vectors before doing anything | 11:09 |
| blackburn | I love the wrapper I'm writing now! | 11:09 |
| heiko | ok, alright | 11:09 |
| @sonney2k | blackburn, being in love is always a good thing :D | 11:17 |
| blackburn | I should not tell my gf :D | 11:17 |
| bettyboo | he | 11:17 |
| blackburn | sonney2k: is it possible to 'borrow' that cover tree code by Langford? | 11:30 |
| @sonney2k | blackburn, I think so | 11:44 |
| blackburn | sonney2k: the only thing - it should be some object-like, right? | 12:05 |
| blackburn | not just a couple of funcs :) | 12:06 |
| -!- blackburn [~blackburn@31.28.40.202] has quit [Quit: Leaving.] | 12:15 | |
| -!- alesis-novik [~alesis@188.74.87.206] has joined #shogun | 13:21 | |
| -!- heiko [~heiko@main.uni-duisburg.de] has quit [Quit: Leaving.] | 13:31 | |
| -!- f-x [~user@117.192.198.247] has joined #shogun | 13:46 | |
| -!- serialhex [~quassel@99-101-148-183.lightspeed.wepbfl.sbcglobal.net] has quit [Read error: Connection reset by peer] | 14:35 | |
| @sonney2k | mlsec, around? | 15:15 |
| -!- blackburn [~blackburn@31.28.40.202] has joined #shogun | 16:57 | |
| -!- in3xes_ [~in3xes@180.149.49.230] has joined #shogun | 17:12 | |
| -!- blackburn [~blackburn@31.28.40.202] has quit [Read error: Connection reset by peer] | 17:51 | |
| -!- blackburn [~blackburn@31.28.40.202] has joined #shogun | 17:52 | |
| -!- serialhex [~quassel@99-101-148-183.lightspeed.wepbfl.sbcglobal.net] has joined #shogun | 18:06 | |
| serialhex | bettyboo's been demoted?? | 18:06 |
| bettyboo | serialhex: I had been sick for a while just like Chris, such a wonder - cold is going around Samara and Tuebingen both :D | 18:06 |
| serialhex | well i hope you're feeling better bettyboo | 18:07 |
| bettyboo | serialhex: whatev!! it sepends on who you're asking! | 18:07 |
| blackburn | serialhex: :D | 18:07 |
| bettyboo | ^_^ | 18:07 |
| serialhex | whats going on blackburn?? | 18:07 |
| blackburn | serialhex: nothing special, day by day :) | 18:08 |
| serialhex | cool cool | 18:08 |
| blackburn | what about you? | 18:08 |
| serialhex | not too much, just went on an appt to sell some knives & didn't sell NOTHIN!!! | 18:10 |
| serialhex | really kinda bummed, i think i'm gonna dive into some more code here in a min | 18:10 |
| blackburn | ah bad | 18:10 |
| serialhex | yeah | 18:10 |
| blackburn | I'm now writing prettiest arpack wrapper :) | 18:11 |
| serialhex | really?? is that sarcasm i hear in your voice or is it really pretty?? :P | 18:12 |
| blackburn | yes I try to make it pretty | 18:12 |
| serialhex | cool cool, i like pretty code. it makes life *SOOO* much easier | 18:14 |
| blackburn | well I hope nobody will have to touch it - I should make it good | 18:14 |
| -!- f-x [~user@117.192.198.247] has left #shogun ["ERC Version 5.3 (IRC client for Emacs)"] | 18:16 | |
| blackburn | hey he uses emacs for irc?? | 18:17 |
| serialhex | really... thats kind of interesting | 18:20 |
| serialhex | what dosn't emacs do?? make toast??? | 18:21 |
| blackburn | serialhex: I guess everything | 18:21 |
| blackburn | hey it have dildo-mode :D | 18:21 |
| blackburn | has* | 18:21 |
| serialhex | lol :P | 18:22 |
| -!- f-x [~user@117.192.198.247] has joined #shogun | 18:25 | |
| -!- in3xes_ [~in3xes@180.149.49.230] has quit [Ping timeout: 246 seconds] | 18:27 | |
| -!- in3xes_ [~in3xes@180.149.49.227] has joined #shogun | 18:28 | |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 18:31 | |
| -!- in3xes1 [~in3xes@180.149.49.227] has joined #shogun | 18:35 | |
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 18:37 | |
| -!- in3xes_ [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 18:38 | |
| -!- in3xes_ [~in3xes@180.149.49.227] has joined #shogun | 18:39 | |
| -!- in3xes__ [~in3xes@180.149.49.230] has joined #shogun | 18:40 | |
| -!- in3xes1 [~in3xes@180.149.49.227] has quit [Ping timeout: 258 seconds] | 18:40 | |
| -!- in3xes__ is now known as in3xes1 | 18:40 | |
| -!- mrsrikanth [~mrsrikant@59.92.81.39] has joined #shogun | 18:41 | |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 258 seconds] | 18:43 | |
| -!- in3xes__ [~in3xes@59.163.196.5] has joined #shogun | 18:50 | |
| -!- in3xes [~in3xes@210.212.58.111] has joined #shogun | 18:51 | |
| -!- in3xes1 [~in3xes@180.149.49.230] has quit [Ping timeout: 240 seconds] | 18:53 | |
| -!- in3xes__ is now known as in3xes1 | 18:53 | |
| -!- in3xes_ [~in3xes@180.149.49.227] has quit [Ping timeout: 258 seconds] | 18:54 | |
| -!- serialhex [~quassel@99-101-148-183.lightspeed.wepbfl.sbcglobal.net] has quit [Remote host closed the connection] | 19:23 | |
| -!- in3xes1 [~in3xes@59.163.196.5] has quit [Quit: Ooops..!!] | 19:31 | |
| -!- blackburn [~blackburn@31.28.40.202] has quit [Ping timeout: 255 seconds] | 20:19 | |
| -!- blackburn [~blackburn@31.28.40.202] has joined #shogun | 20:32 | |
| -!- blackburn [~blackburn@31.28.40.202] has quit [Read error: Connection reset by peer] | 20:48 | |
| -!- blackburn [~blackburn@31.28.40.202] has joined #shogun | 20:54 | |
| blackburn | landmark isomap is wrong.. | 21:34 |
| blackburn | mlsec: around? | 21:39 |
| @mlsec | Not really | 21:40 |
| blackburn | mlsec: have you worked with L-Isomap? if so will ask you for some help later | 21:41 |
| @mlsec | Nope. Just used standard isomap | 21:41 |
| blackburn | okay | 21:41 |
| blackburn | thanks anyway | 21:41 |
| -!- blackburn [~blackburn@31.28.40.202] has left #shogun [] | 21:50 | |
| -!- blackburn [~blackburn@31.28.40.202] has joined #shogun | 21:51 | |
| CIA-32 | shogun: Sergey Lisitsyn master * r596755e / (2 files): Temporarly remove LandmarkIsomap - http://bit.ly/kWUDDb | 22:08 |
| blackburn | ah that would cause errors | 22:09 |
| CIA-32 | shogun: Sergey Lisitsyn master * r1114044 / (2 files): Restore LandmarkIsomap with not implemented tags - http://bit.ly/jtREp6 | 22:10 |
| @sonney2k | blackburn, ? | 22:12 |
| blackburn | sonney2k: ? ;) | 22:12 |
| @sonney2k | not enough vodka today? | 22:12 |
| @sonney2k | man you need your fuel! | 22:12 |
| blackburn | sonney2k: hhaha | 22:12 |
| blackburn | something like that.. | 22:13 |
| blackburn | well I thought that erroneus algo should be here, then recalled that it would cause errors | 22:13 |
| @sonney2k | I feel like merging with my evil twin | 22:13 |
| blackburn | shouldn't* | 22:14 |
| CIA-32 | shogun: Soeren Sonnenburg master * ra42094c / (14 files in 6 dirs): | 22:14 |
| CIA-32 | shogun: Merge pull request #139 from karlnapf/master | 22:14 |
| CIA-32 | shogun: first working version of subset support for SimpleFeatures - http://bit.ly/khm2PZ | 22:14 |
| @sonney2k | f-x, around? | 22:14 |
| f-x | sonney2k: yes | 22:14 |
| @sonney2k | f-x, what is the issue with calling free_feature_vector()? | 22:15 |
| @sonney2k | f-x, simplefeatures work like this: | 22:15 |
| @sonney2k | 1. you have either a feature matrix (in memory) | 22:15 |
| @sonney2k | or some method to get just one feature vector | 22:15 |
| @sonney2k | 2. on top of this there can be preprocessor chains | 22:15 |
| @sonney2k | these preprocessors can be applied inplace to the feature matrix or only on-the-fly to the feature vector | 22:16 |
| @sonney2k | 3. for that reason you might get copies of the feature vector and have to call free_* | 22:16 |
| @sonney2k | but usually (i.e. when working with a feature matrix) this is just a NOP | 22:17 |
| @sonney2k | f-x, OK? | 22:17 |
| f-x | sonney2k: okay.. there isn't any issue with adding free_feature_vector() | 22:17 |
| f-x | it's just that i've done delete[] vector in release_example() | 22:17 |
| f-x | so i have to change a bit of the code there | 22:17 |
| f-x | (to make it work for examples extracted from a CSimpleFeatures object) | 22:18 |
| @sonney2k | yes ok | 22:18 |
| @sonney2k | regarding streamingfile changes | 22:19 |
| @sonney2k | don't you think you should rather derive from streamingfile? | 22:19 |
| f-x | sonney2k: yes.. "StreamingFile" is becoming too broad a class for the things it handles | 22:19 |
| @sonney2k | and then override just the functions to return the examples etc | 22:20 |
| @sonney2k | I mean in principle StreamingSimpleFeatures shouldn't change when streamingfile's design is right or? | 22:20 |
| f-x | i guess, but i wouldn't commit on that | 22:21 |
| f-x | because for now the input source has always been the FILE* pointer in StreamingFile | 22:21 |
| @sonney2k | I think you could just override the get_*_vector functions and return what is in simplefeatures and that's it | 22:21 |
| f-x | StreamingSimpleFeatures won't change, but InputParser code may change somewhat | 22:22 |
| f-x | okay, so a class derived from StreamingFile specific to SimpleFeatures? | 22:22 |
| @sonney2k | f-x, I think that makes more sense | 22:23 |
| f-x | which has its input source as a CFeatures* | 22:23 |
| @sonney2k | f-x, or SimpleFeatures even | 22:23 |
| f-x | sonney2k: correct.. but now i'm thinking there will be too many new files | 22:24 |
| f-x | while writing the code to use all this | 22:24 |
| f-x | one would have to know about all the different kinds of Streaming*File | 22:25 |
| f-x | and Streaming*Features etc | 22:25 |
| f-x | i was wondering if something more convenient could be made for the user | 22:25 |
| @sonney2k | f-x, maybe you are right | 22:26 |
| f-x | sonney2k: my ideal implementation would be: | 22:27 |
| f-x | CStreamingSimpleFeatures* feat=new CStreamingFeatures(a CSimpleFeatures object) | 22:28 |
| f-x | <and then the rest the same as for a normal file input> | 22:28 |
| f-x | or new CStreamingFeatures(an explicit CStreamingFile object) | 22:28 |
| f-x | <and the rest the same> | 22:28 |
| f-x | for a file based input | 22:28 |
| f-x | *sorry 'new CStreamingSimpleFeatures' everywhere | 22:29 |
| @sonney2k | f-x, exactly | 22:30 |
| @sonney2k | that is the most convenient | 22:30 |
| f-x | sonney2k: maybe just a two-way split -- one for reading from files/sockets, etc., and the other from features objects? | 22:31 |
| @sonney2k | f-x, what I don't like is that the file class is getting so messy | 22:31 |
| f-x | sonney2k: me too.. it's going to be difficult to edit later | 22:32 |
| @sonney2k | (and that free_feature_vector is missing currently) | 22:32 |
| * blackburn is staring to FLOAT K parameter at LandmarkIsomap | 22:34 | |
| blackburn | garcon, vodka! | 22:34 |
| f-x | sonney2k: i think i'll make StreamingFile-like (or maybe derived) class to deal purely with getting vectors from features objects | 22:35 |
| @sonney2k | f-x, I really wonder how to simplify streamingfile further | 22:38 |
| blackburn | sonney2k: just take some vodka, it helps | 22:38 |
| @sonney2k | I mean - in the end you only need a few functions | 22:38 |
| @sonney2k | f-x, like get_*_vector stuff or get_string | 22:38 |
| @sonney2k | or get_sparse_vector | 22:38 |
| @sonney2k | no more than that | 22:38 |
| f-x | get_*_vector, where * includes simplefeatures etc. right? | 22:39 |
| @sonney2k | So maybe you should make 3 base classes - one for simplefeatures, one for sparse and one for strings | 22:39 |
| @sonney2k | and then you can overload these for ascii | 22:40 |
| @sonney2k | etc | 22:40 |
| @sonney2k | (etc here would then be StreamingFileFromFeatures or so) | 22:40 |
| @sonney2k | blackburn, I am trying chocolate instead | 22:41 |
| blackburn | sonney2k: just try vodka, I'm telling you as old alcoholic :D | 22:41 |
| f-x | sonney2k: that should work. thinking of where i may have problems with that... | 22:43 |
| @sonney2k | f-x, currently it is really becoming to messy I think. But sleep one night over it - maybe tomorrow you will see the problems clearly :) | 22:44 |
| @sonney2k | blackburn, you are a freshman - but I guess still very experienced alcoholic | 22:45 |
| blackburn | sonney2k: exactly I am | 22:45 |
| f-x | sonney2k: yeah and i dislike that we have to do that #define thing for all the template variations.. it's nice as a hack though.. | 22:46 |
| blackburn | I have an polyurethane liver | 22:46 |
| @sonney2k | f-x, yeah but it becomes unhandy when you have to do that massively as we do now | 22:47 |
| f-x | sonney2k: yup.. it's the kind of thing which drives people away from touching the code | 22:47 |
| @sonney2k | yeah - so better change it while the streamingfeatures code is still fresh | 22:49 |
| f-x | sonney2k: hehe... that doesn't apply to my own code however.. at least for now :) | 22:49 |
| @sonney2k | streamingfile code I meant | 22:51 |
| f-x | yeah, will do it now | 22:52 |
| @sonney2k | f-x, thanks - btw you should add some small examples that read some data and do sth. otherwise we cannot check that things work | 22:52 |
| @sonney2k | if you want just in C++ for now (in examples/undocumented/libshogun then) | 22:53 |
| @sonney2k | blackburn, did you make any progress on arpack? | 22:53 |
| f-x | sonney2k: sure, i'll put up some files i made for testing myself | 22:53 |
| blackburn | sonney2k: writing wrapper step by step | 22:53 |
| @sonney2k | f-x, thanks | 22:53 |
| @sonney2k | blackburn the rapper | 22:54 |
| @sonney2k | err wrapper ;-) | 22:54 |
| blackburn | sonney2k: in fact now I'm stucked with L-Isomap - it acts not like it should | 22:54 |
| @sonney2k | blackburn, doesn't anyone else implement this? | 22:54 |
| @sonney2k | I mean not even the matlab dim red toolbox? | 22:55 |
| blackburn | yes, it is in that toolbox | 22:55 |
| @sonney2k | (such that you could check?) | 22:55 |
| blackburn | well I tried to understand that shity crap of shit | 22:56 |
| blackburn | and seems like they do it just like me | 22:56 |
| @sonney2k | blackburn, but their code works right :D | 22:58 |
| @sonney2k | sometimes shitty code is better than glossy code | 22:58 |
| blackburn | sonney2k: yes, but I can't really understand what was on their mind while they was writing it :D | 23:00 |
| blackburn | matlab + some optimizations = luv | 23:00 |
| @sonney2k | blackburn, well if they do auxiliary calculations - try to check if you get the same results | 23:01 |
| blackburn | sonney2k: I just need to get comprehension how to do it in math - that way worked for all other algos | 23:02 |
| blackburn | found some python - should be compherensive | 23:04 |
| blackburn | sonney2k: btw why are you asking about arpack? :) | 23:04 |
| @sonney2k | blackburn, because you wanted it - now I want results :D | 23:05 |
| blackburn | sonney2k: ah ok, working on it | 23:07 |
| f-x | sonney2k: in Leon's svmsgd, is there an online algorithm listed separately or i have to set epochs=1 in his svmsgd2.cpp and be done with it? | 23:13 |
| @sonney2k | f-x, yeah epochs = 1 is what you need | 23:13 |
| f-x | sonney2k: so is there a need to refer back to the original code or the few minor modifications required in SVMSGD.cpp in shogun are sufficient? | 23:14 |
| @sonney2k | f-x, in principle the few minor modifications should do | 23:15 |
| @sonney2k | I mean in the end we only want 1 algorithm | 23:15 |
| @sonney2k | SVMSGD in there | 23:15 |
| @sonney2k | I guess you could add a reset_stream() function that restarts at the beginning (if possible) | 23:15 |
| @sonney2k | so you could do multiple epochs even | 23:16 |
| f-x | sonney2k: that's an option when we're reading from a file, definitely | 23:16 |
| @sonney2k | then SVMSGD code can work with streamingfeatures and only has to exist once | 23:16 |
| @sonney2k | f-x, or simplefeatures | 23:16 |
| @sonney2k | or dotfeatures etc | 23:16 |
| @sonney2k | and if unsupported SG_ERROR :) | 23:17 |
| f-x | right, right.. forgot about that.. | 23:17 |
| blackburn | to embed or not to embed | 23:17 |
| f-x | :) | 23:17 |
| blackburn | whether tis' isomap | 23:17 |
| blackburn | in the mind to suffer | 23:17 |
| blackburn | not to embed, i'll better wrap instead | 23:22 |
| @sonney2k | blackburn! | 23:24 |
| blackburn | yes? | 23:25 |
| @sonney2k | the new Goethe! | 23:25 |
| blackburn | :D | 23:25 |
| f-x | sonney2k: again, about the free_feature_vector(): since i'm using the SGVector<ST> get_feature_vector(int32_t num) which implicitly does free_feature_vector(), should i add something more to my code? | 23:31 |
| blackburn | isomap works cool, classicmds works cool, even landmark mds works pretty cool | 23:31 |
| blackburn | why this god damn landmark isomap is wrong | 23:32 |
| @sonney2k | blackburn, ^ seen f-x's question? | 23:32 |
| @sonney2k | sounds to me like we need another consolidation | 23:32 |
| blackburn | sonney2k: eh.. don't understand the issue | 23:33 |
| @sonney2k | blackburn, in simplefeatures you can do get_feature_vector | 23:33 |
| blackburn | yes | 23:33 |
| @sonney2k | but you always have to call *free_feature_vector* afterwards | 23:33 |
| @sonney2k | now when SGVector has the same thing this is somehow double'd | 23:33 |
| blackburn | yeess | 23:33 |
| blackburn | sonney2k: why SGVector has the same thing? | 23:34 |
| @sonney2k | blackburn, recall the do_free flag? | 23:34 |
| @sonney2k | hmmhh | 23:34 |
| blackburn | sonney2k: I just don't recall if SGVector has destructor | 23:34 |
| blackburn | has it? | 23:34 |
| @sonney2k | no | 23:34 |
| @sonney2k | why? | 23:35 |
| @sonney2k | it has a free_vector() function | 23:35 |
| blackburn | so can't see anything double | 23:35 |
| blackburn | doubled* | 23:35 |
| blackburn | what is doubled? | 23:35 |
| @sonney2k | free_feature_vector / free_vector | 23:35 |
| blackburn | ahh | 23:35 |
| @sonney2k | more vodka please | 23:35 |
| @sonney2k | but the free_feature_vector is a bit more general | 23:35 |
| @sonney2k | it could be that the features are coming from some strange thing | 23:36 |
| blackburn | sonney2k: I will be smart some day, I swear :D | 23:36 |
| @sonney2k | and so the free is some more complex function | 23:36 |
| @sonney2k | blackburn, smart enough for my taste | 23:36 |
| blackburn | okay I see | 23:37 |
| blackburn | but can't see any way to avoid this | 23:37 |
| @sonney2k | f-x, anyway for now please call just free_feature_vector() | 23:37 |
| f-x | sonney2k: okay.. | 23:37 |
| blackburn | what exactly free_feature_vector could do? | 23:38 |
| @sonney2k | blackburn, yeah but I would rather simplify things and avoid free_feature_vector | 23:38 |
| blackburn | I think I have a E.coli instead of my brain | 23:38 |
| @sonney2k | blackburn, anything | 23:38 |
| blackburn | sonney2k: even mess around with girls? | 23:39 |
| @sonney2k | for sure | 23:39 |
| @sonney2k | blackburn, even date bettyboo | 23:40 |
| bettyboo | sonney2k: or should i do it side by side | 23:40 |
| * sonney2k does not want further details | 23:40 | |
| blackburn | bettyboo: would you like to have a luv time with some free_feature_vector() methods? | 23:40 |
| bettyboo | blackburn: I'm pretty new to the project but there's no c# interface from what I've seen in the code and documentation. I have no idea about the scale of the samples with regards to your second question so I'll let someone else more knowledgable answer that lol | 23:41 |
| blackburn | sonney2k: well how can it be possible to avoid that method? | 23:41 |
| @sonney2k | blackburn, by restricting shogun to platonic love - and just allowing free_vector() | 23:43 |
| blackburn | sonney2k: well let it be this way if possible :) | 23:44 |
| blackburn | sonney2k: do you use some autocompletion in vim? | 23:44 |
| @sonney2k | blackburn, I looked at the code - not so easy. if features are cached, free_feature_vector will unlock the cached row for example | 23:45 |
| @sonney2k | so hmhhh don't want to touch it | 23:45 |
| blackburn | the only thing I lack - how to get e.g. at least param names of cblas_dgemm | 23:45 |
| @sonney2k | blackburn, google | 23:46 |
| blackburn | sonney2k: google of course can help - but in vim?? | 23:46 |
| @sonney2k | blackburn, I don't use that autocompletion stuff... | 23:47 |
| blackburn | okaay | 23:47 |
| -!- blackburn [~blackburn@31.28.40.202] has quit [Quit: Leaving.] | 23:52 | |
| -!- blackburn [~blackburn@31.28.40.202] has joined #shogun | 23:53 | |
| -!- mrsrikanth [~mrsrikant@59.92.81.39] has quit [Quit: Leaving] | 23:58 | |
| --- Log closed Tue Jun 28 00:00:27 2011 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!