| --- Log opened Thu Jul 28 00:00:38 2011 | ||
| @sonney2k | uh | 00:01 |
|---|---|---|
| serialhex | yeah, when you install it with a gem it installes it as a subdir in the gems dir | 00:01 |
| @sonney2k | then I guess you need some magic to get that detected too | 00:01 |
| serialhex | yes, that is the plan for today, lots of magic! | 00:01 |
| serialhex | and i shall become, THE ALL POWERFUL COMPATIBILITY WIZARD!!!! BUAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAH1!!!!!!!!1!!!!! | 00:03 |
| CIA-87 | shogun: Soeren Sonnenburg master * r1454579 / (7 files in 2 dirs): | 00:05 |
| CIA-87 | shogun: enable memory tracing when compiled with --enable-trace-mallocs | 00:05 |
| CIA-87 | shogun: just call CSGObject::list_memory_allocs() or list_memory_allocs() if | 00:05 |
| CIA-87 | shogun: you've include lib/memory.h - https://github.com/shogun-toolbox/shogun/commit/14545797611459782da964cb59559e79063f3464 | 00:05 |
| CIA-87 | shogun: Soeren Sonnenburg master * r57066ac / (47 files in 9 dirs): Merge branch 'master' of github.com:shogun-toolbox/shogun - https://github.com/shogun-toolbox/shogun/commit/57066ac8ec89a73253a7a21e8d9f215efb9aae55 | 00:05 |
| @sonney2k | blackburn, please try the new malloc tracing stuff! | 00:06 |
| blackburn | sonney2k: I will, but now I'm messing with some lapack shit | 00:06 |
| @sonney2k | blackburn, it gives you a good feeling when you do list_memory_allocs() at the end of a script when it then says 0 objects alloc'd :) | 00:07 |
| @sonney2k | blackburn, I have a dejavu | 00:07 |
| blackburn | why? | 00:07 |
| @sonney2k | didn't you say this yesterday and the day before and the day before the day before and ... too ? | 00:07 |
| blackburn | yes I have regular sex with lapack | 00:08 |
| serialhex | LOLZ blackburn | 00:09 |
| blackburn | well as I said before - there are some fancy dsyevr I haven't tried before | 00:09 |
| * sonney2k senses blackburns lapackorgasm ahead | 00:11 | |
| blackburn | this time I got only segfault | 00:13 |
| blackburn | sudo apt-get install valgrind | 00:17 |
| blackburn | hmm got it | 00:19 |
| blackburn | I got semi-lapack-orgasm | 00:22 |
| blackburn | serialhex: I'm gradually sth .. OR I gradually sth? | 00:24 |
| serialhex | i'm gradually sth | 00:25 |
| serialhex | ^ blackburn | 00:25 |
| blackburn | thanks :) | 00:25 |
| @bettyboo | ha ha | 00:25 |
| serialhex | so how ya been blackburn? i've been away but you're still here :D | 00:26 |
| @bettyboo | :^) | 00:26 |
| blackburn | sonney2k: when you was away? i'm fine, and you? | 00:26 |
| blackburn | shhhhh | 00:26 |
| blackburn | serialhex: | 00:26 |
| blackburn | sonney2k: not you :D | 00:26 |
| @bettyboo | hihi | 00:26 |
| @sonney2k | pfff! | 00:27 |
| serialhex | HAHAHA!!! | 00:28 |
| serialhex | confusion EVRYWHER!!! | 00:28 |
| blackburn | for everyone | 00:29 |
| blackburn | feel free to confuse ;) | 00:29 |
| serialhex | it's what i do best!! :) | 00:32 |
| blackburn | I shall remove my test prints | 00:32 |
| blackburn | FUCKED 205 50FUCKEY NOOOOOEFUCKED YEAHvector=[5.69951159312013189,193.850759879128816,858.82707863487451] | 00:33 |
| blackburn | that's strange! | 00:33 |
| blackburn | :D | 00:33 |
| serialhex | wtf dude? you alright?? | 00:34 |
| blackburn | hahaha | 00:35 |
| blackburn | it is what my DSYEVR wrapper produce | 00:35 |
| blackburn | for test :D | 00:35 |
| @sonney2k | blackburn is a confUSER | 00:46 |
| blackburn | :D | 00:46 |
| * sonney2k is off to ZZZzzzz..... | 00:46 | |
| @sonney2k | cu | 00:46 |
| blackburn | cu | 00:46 |
| blackburn | wow | 01:03 |
| blackburn | factor of 3 speedup | 01:03 |
| * blackburn is lying | 01:06 | |
| * blackburn is lying that he is lying | 01:12 | |
| blackburn | sonney2k: classicmds, 2000 examples: 75s for DSYEV (old), 27s for DSYEVR(new), 17s for Arpack | 01:17 |
| blackburn | who's your daddy :D | 01:18 |
| CIA-87 | shogun: Sergey Lisitsyn master * r5286e94 / (2 files): Added wrapper for DSYEVR lapack routine - https://github.com/shogun-toolbox/shogun/commit/5286e9425b20f0f1dd89365208b8220ad2b4c562 | 01:45 |
| CIA-87 | shogun: Sergey Lisitsyn master * r0238667 / src/shogun/preprocessor/ClassicMDS.cpp : Changed MDS solver to DSYEVR - https://github.com/shogun-toolbox/shogun/commit/0238667449394761a104560c33973a7c02c7975e | 01:45 |
| CIA-87 | shogun: Sergey Lisitsyn master * r8bc3d93 / src/shogun/mathematics/lapack.cpp : Cleaned lapack wrappers - https://github.com/shogun-toolbox/shogun/commit/8bc3d93c5fbb28609d061a7140529e874e3aa7b6 | 01:47 |
| -!- blackburn [~blackburn@109.226.76.87] has quit [Quit: Leaving.] | 02:04 | |
| -!- sploving1 [~sploving@124.16.139.134] has joined #shogun | 03:15 | |
| -!- sploving1 [~sploving@124.16.139.134] has left #shogun [] | 03:25 | |
| -!- gsomix [~gsomix@80.234.50.40] has joined #shogun | 05:37 | |
| -!- f-x [~user@117.192.219.5] has joined #shogun | 06:04 | |
| -!- f-x [~user@117.192.219.5] has quit [Ping timeout: 260 seconds] | 06:59 | |
| -!- f-x [~user@117.192.203.28] has joined #shogun | 07:03 | |
| -!- f-x_ [fx@213.155.190.134] has quit [Remote host closed the connection] | 08:11 | |
| -!- blackburn [~blackburn@109.226.76.87] has joined #shogun | 11:16 | |
| -!- gsomix [~gsomix@80.234.50.40] has quit [Ping timeout: 258 seconds] | 11:29 | |
| -!- f-x [~user@117.192.203.28] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] | 11:54 | |
| -!- blackburn [~blackburn@109.226.76.87] has quit [Quit: Leaving.] | 11:55 | |
| -!- heiko [~heiko@134.91.52.218] has joined #shogun | 11:55 | |
| -!- gsomix [~gsomix@88.200.214.229] has joined #shogun | 12:30 | |
| -!- gsomix [~gsomix@88.200.214.229] has quit [Client Quit] | 12:33 | |
| @sonney2k | heiko, try the new trace malloc stuff! | 12:34 |
| CIA-87 | shogun: Soeren Sonnenburg master * rd3602de / (5 files in 2 dirs): | 12:37 |
| CIA-87 | shogun: Merge pull request #244 from sploving/master | 12:37 |
| CIA-87 | shogun: add some ruby examples (+5 more commits...) - https://github.com/shogun-toolbox/shogun/commit/d3602de6dc7b55ba0bb8142cf700dcd0664c9f2d | 12:37 |
| heiko | sonney2k, alright :) | 12:40 |
| @sonney2k | just call list_memory_allocs() | 12:40 |
| @sonney2k | and don't forget to enable it in configure | 12:40 |
| @sonney2k | --enable-trace-mallocs | 12:40 |
| @sonney2k | or call CSGObject::list_memory_allocs() | 12:40 |
| @sonney2k | heiko, it will tell you everything for SG_ALLOC'd memory (which line allocated / size) | 12:41 |
| @sonney2k | for SGObjects it will tell you how much you name, refcount, size and ptr | 12:42 |
| @sonney2k | for other objects just ptr & size | 12:42 |
| @sonney2k | it is pretty slick... this way I could check that examples really don't leak memory :) | 12:42 |
| heiko | and are objects still created with new? | 12:43 |
| @sonney2k | yes | 12:47 |
| @sonney2k | heiko, and? | 13:08 |
| heiko | sonney2k, just checked out | 13:46 |
| heiko | how to activate the trace? | 13:46 |
| heiko | compiling with trace mem allocs | 13:47 |
| @sonney2k | ./configure --enable-trace-mallocs | 13:52 |
| @sonney2k | and then CSGObject::list_memory_allocs() | 13:52 |
| @sonney2k | heiko, and? | 14:01 |
| heiko | smooth :) | 14:01 |
| heiko | works perfect | 14:02 |
| @sonney2k | heiko, yeah great isn't it? | 14:09 |
| @sonney2k | this will really help fixing memory leaks | 14:09 |
| heiko | really cool | 14:10 |
| heiko | yes i think so | 14:10 |
| heiko | sad that i didnt have it while building the model tree stuff :) | 14:10 |
| heiko | sonney2k, i found some vector related methods in CMath | 14:15 |
| heiko | fill_vector range_fill_vector | 14:15 |
| @sonney2k | heiko, it was there - but not as good | 14:15 |
| heiko | these should be with SGVector right? | 14:15 |
| heiko | and also they iterator over the arrays (fill_vector) | 14:16 |
| heiko | and clone_vector also | 14:16 |
| heiko | instead of using memset/memcpy | 14:16 |
| heiko | should i change this? | 14:16 |
| @sonney2k | heiko, yeah makes sense - however it would make sense to have them static in there too to just fill memory | 14:16 |
| @sonney2k | heiko, there is a lot of low-hanging fruits in there | 14:16 |
| heiko | and another question: if i introduce the methods with SGVector, should I delete the old ones? or add a SG_DEPRECATED | 14:16 |
| heiko | or just leave them? | 14:16 |
| @sonney2k | like max() | 14:16 |
| @sonney2k | min() | 14:16 |
| @sonney2k | etc | 14:17 |
| @sonney2k | mean | 14:17 |
| @sonney2k | all these simple operations... | 14:17 |
| @sonney2k | it is quite a bit of work though | 14:19 |
| @sonney2k | heiko, first add tehm to sgvector | 14:19 |
| @sonney2k | then transition all code and then remove all these max/min/fill_vector/mean etc stuff from CMath | 14:20 |
| heiko | sonney2k, how to enable print of dSG_DEBUG messages | 14:27 |
| @sonney2k | obj.io.set_loglevel(MSG_DEBUG) | 14:28 |
| -!- blackburn [~blackburn@109.226.76.87] has joined #shogun | 14:38 | |
| @sonney2k | hi papa blackburn | 14:39 |
| blackburn | :D | 14:39 |
| @bettyboo | ;D | 14:39 |
| blackburn | I guess now our mds is the fastest one ;) | 14:40 |
| -!- blackburn [~blackburn@109.226.76.87] has left #shogun [] | 14:40 | |
| -!- blackburn [~blackburn@109.226.76.87] has joined #shogun | 14:40 | |
| blackburn | sonney2k: how can I realloc feature matrix? | 14:42 |
| blackburn | get it and then just realloc? | 14:42 |
| @sonney2k | blackburn, I would suggest to add a function that re-allocs | 14:43 |
| -!- blackburn [~blackburn@109.226.76.87] has quit [Ping timeout: 255 seconds] | 14:47 | |
| heiko | sonney2k, I would like to add a method display_string to CMath, is that ok? | 14:51 |
| @sonney2k | heiko, shouldn't that be in SGString too? | 14:51 |
| heiko | mmh | 14:51 |
| heiko | true | 14:51 |
| heiko | but same should then hold vor vector and matrix or? | 14:51 |
| heiko | btw currently there is no difference between SGVector and SGString | 14:52 |
| heiko | but will be if display methods are in these types | 14:52 |
| -!- alesis-novik [~alesis@188.74.87.206] has joined #shogun | 14:55 | |
| -!- f-x [~user@117.192.221.29] has joined #shogun | 15:00 | |
| alesis-novik | Hey sonney2k, sorry about missing the meeting yesterday. I read the log so I'm up to date on what's what | 15:00 |
| -!- blackburn [~blackburn@109.226.104.206] has joined #shogun | 15:02 | |
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 15:03 | |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Read error: Connection reset by peer] | 15:03 | |
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 15:04 | |
| -!- VojtechFranc [~quassel@gw-101.scnet.cz] has joined #shogun | 15:05 | |
| alesis-novik | Hello VojtechFranc | 15:05 |
| VojtechFranc | hi alesis-novik | 15:05 |
| VojtechFranc | what is the state? | 15:06 |
| alesis-novik | Well, I was mostly working on how to fix some of the potential memory leaks | 15:07 |
| alesis-novik | though I don't think there's a clear way of doing that, when using SG* stuff | 15:07 |
| VojtechFranc | ok, my plan for the following weeks is the following | 15:07 |
| VojtechFranc | first of all, Aug 16 is suggested pencils down date | 15:08 |
| VojtechFranc | 1. could you please prepare example scripts in python demonstrating use of SMEM | 15:09 |
| VojtechFranc | 2. We need document functions you implemented. | 15:09 |
| VojtechFranc | 3. We need to test/benchmark EM and SMEM and fix potential bugs | 15:10 |
| alesis-novik | VojtechFranc, as in more examples? There is a 2d smem example showing it's superiority over EM | 15:10 |
| VojtechFranc | regarding task 3, I will send you a text file describing the experiments I'd like you to implement | 15:11 |
| VojtechFranc | regarding examples, is the script included in shogun? | 15:11 |
| alesis-novik | yes, it's under undocumented/python_modular/graphical (I think that's the path) | 15:12 |
| VojtechFranc | ok then, I'll have a look at it | 15:12 |
| VojtechFranc | I will also send you a brief minutes of the yesterday meeting as Soeren suggested some tasks for all shogun developers | 15:13 |
| alesis-novik | look for smem_2d_gmm.py | 15:13 |
| VojtechFranc | ok | 15:13 |
| VojtechFranc | now, the most urgent is doign the experiments/benchmarks | 15:14 |
| alesis-novik | I've read through the logs, so I'm more or less aware of the plan | 15:14 |
| alesis-novik | ok, just send me the experiments/benchmarks you had in mind and I'll run them. | 15:14 |
| alesis-novik | are we benchmarking run time? | 15:15 |
| VojtechFranc | yes | 15:15 |
| VojtechFranc | runtime, likelihood, and if it makes sense application dependent statistics like classification error etc | 15:15 |
| alesis-novik | ok, that makes sense | 15:16 |
| VojtechFranc | I'll send you the experiment description + link to data today. | 15:16 |
| VojtechFranc | I'll try to do exactly the same experiments with my implementation in order to compare the results | 15:17 |
| VojtechFranc | One quation, do you have an experience with Open CV? | 15:17 |
| VojtechFranc | the thing is that OpenCV which is a major CV library has also an efficient EM implemenation | 15:18 |
| VojtechFranc | if we have time it would be great to do some benchmarking ... but it would be task 3 when the rest is finished | 15:19 |
| alesis-novik | benchmarking openCV? | 15:19 |
| VojtechFranc | no, only the EM implemenation from openCV | 15:19 |
| VojtechFranc | using the very same data we will use in our experiments | 15:20 |
| alesis-novik | I'd need to familiarize myself with openCV first | 15:20 |
| VojtechFranc | algorithm in openCV are typically state-of-the-art implemenations so it would be nice to know how we compare | 15:21 |
| VojtechFranc | ok, but as I said it just a bonus if we have time | 15:21 |
| VojtechFranc | another quation regarding your implementationof SMEM: what do you use a the stopping condition of the partial EM step? | 15:22 |
| VojtechFranc | I'm asking because it was not fully described in the paper | 15:22 |
| VojtechFranc | In my implementation I stop it based on minimal change in likelihood | 15:23 |
| alesis-novik | I used the same stopping conditions as for full EM: likelihood change and max iterations | 15:23 |
| VojtechFranc | perfect | 15:23 |
| alesis-novik | So what about the factor model EM? | 15:24 |
| VojtechFranc | it would be also good but experiments are more important. I'm not sure we would finish everything in time | 15:25 |
| VojtechFranc | I prefer less algorithms but careffuly implemented | 15:25 |
| VojtechFranc | have you read the paper ? | 15:26 |
| alesis-novik | I've skimmed it. It does seem to have an additional part to consider | 15:27 |
| VojtechFranc | which one? | 15:28 |
| VojtechFranc | another small issue: would you manage to translate the python examples to Matlab? | 15:30 |
| alesis-novik | I don't think there's a Matlab modular interface, so it would be problematic. I think octave modular works now, so that would be easier | 15:31 |
| VojtechFranc | isn't there option to use matlab static interface ? | 15:32 |
| blackburn | VojtechFranc: hi, have you any matlab code for kPCA? | 15:33 |
| VojtechFranc | blackburn, yes | 15:33 |
| blackburn | VojtechFranc: could you email it to me? blackburn91@gmail.com | 15:33 |
| VojtechFranc | it is in matlab toolbox http://cmp.felk.cvut.cz/cmp/software/stprtool/index.html function kpca | 15:34 |
| blackburn | hmm okay thanks ;) | 15:34 |
| alesis-novik | I'm not that familiar with how the static interfaces work | 15:34 |
| alesis-novik | I could look into it | 15:34 |
| VojtechFranc | ok, but only if it doesn't consume to much time otherwise octave is ok | 15:35 |
| VojtechFranc | that's it from my side. So, I'll prepare the experiments and mail it to you in the evening | 15:35 |
| alesis-novik | So I'll prioritize running the experiments and benchmarking them for now, is that fine? | 15:36 |
| VojtechFranc | yes please | 15:37 |
| VojtechFranc | you can also write the documentation in parallel | 15:37 |
| alesis-novik | ok, I probably should add more specifics to the current method documentation | 15:38 |
| VojtechFranc | ok, see you | 15:38 |
| alesis-novik | See you VojtechFranc | 15:39 |
| -!- VojtechFranc [~quassel@gw-101.scnet.cz] has quit [Remote host closed the connection] | 15:39 | |
| -!- sploving1 [~sploving@210.77.14.219] has joined #shogun | 15:48 | |
| sploving1 | I met a problem | 15:48 |
| sploving1 | in kernel_gaussian_modular.rb, | 15:48 |
| sploving1 | feats_train=Modshogun::RealFeatures.new(fm_train_real) it said: can't convert nil into String (TypeError) | 15:49 |
| sploving1 | but when I use feats_train=Modshogun::RealFeatures.new feats_train.set_feature_matrix fm_train_real | 15:49 |
| sploving1 | it works | 15:49 |
| sploving1 | I discussed with seriahex, he also have no idea~ | 15:51 |
| sploving1 | sonney2k, any idea? | 15:53 |
| sploving1 | any suggestion? | 15:53 |
| sploving1 | I discussed with serialhex, | 15:56 |
| heiko | sonney2k, are you there? | 16:07 |
| heiko | I found an inconsisty in get_feature_vector: | 16:07 |
| heiko | SimpleFeatures::get_feature_vector returns a pointer to an elements in its matrix | 16:07 |
| heiko | StringFeatures::get_feature_vector returns a copy of a string | 16:08 |
| heiko | which one is the desired behaviourr? | 16:08 |
| heiko | i will set the do_free flag to true in StringFeatures | 16:10 |
| heiko | should solve the problem | 16:10 |
| heiko | sonney2k, ohoh another problem | 16:14 |
| heiko | list_memory_allocs says 0 blocks | 16:14 |
| heiko | but valgrind sais memory leak | 16:15 |
| @sonney2k | sploving1, you need to implement typecheck typemaps | 16:27 |
| @sonney2k | that will fix the issue | 16:27 |
| @sonney2k | heiko, only ever return pointers if possible | 16:27 |
| @sonney2k | heiko, what kind of leaks? | 16:28 |
| heiko | currently checking | 16:28 |
| sploving1 | sonney2k, I added the typemap %typemap(typecheck, precedence=SWIG_TYPECHECK_POINTER) shogun::SGMatrix<SGTYPE> | 16:28 |
| sploving1 | typecheck | 16:28 |
| heiko | but why is feature vector copied in StringFeatures? simply a mistake? | 16:28 |
| heiko | sonney2k, mmh basic minimal memory leaks here. i will do a make clean and make again | 16:31 |
| @sonney2k | heiko, we mighta ctually leak the CSet object with the malloc traces or so ... but if you find leaks please fix them (if not too hard) | 16:32 |
| heiko | sonney2k, ok i am onto it | 16:33 |
| @sonney2k | heiko, well there are 2 kinds of get_feature_vector | 16:33 |
| @sonney2k | one is just returning the pointer | 16:33 |
| @sonney2k | and one is returning a preprocessed copy | 16:33 |
| @sonney2k | so it might need to be freed | 16:33 |
| heiko | SGVector<ST> get_feature_vector(int32_t num) | 16:34 |
| heiko | makes always a copy | 16:34 |
| @sonney2k | I know | 16:34 |
| heiko | so what about | 16:34 |
| heiko | return SGVector<ST>(dst, l, true); | 16:34 |
| @sonney2k | I was trying to change this behavior when I recognized that I need the SG_MALLOC transition for that | 16:34 |
| @sonney2k | no | 16:34 |
| @sonney2k | don't always copy | 16:34 |
| heiko | ok | 16:34 |
| heiko | then I just remove the copying | 16:35 |
| @sonney2k | heiko, that will crash if there is a string preproc attached | 16:35 |
| @sonney2k | removing the whole fucntion seems more appropriate | 16:35 |
| heiko | but a getter which returns an SGVector is nice | 16:36 |
| heiko | also the setter below that method does copy the input parameter | 16:36 |
| @sonney2k | then changing the other get-feature_vector function to return SGVector would be the best fix | 16:36 |
| heiko | but its entioned in the comments | 16:36 |
| heiko | ok, will do then | 16:37 |
| @sonney2k | hmmhh | 16:37 |
| @sonney2k | wait | 16:37 |
| @sonney2k | there is a catch | 16:37 |
| @sonney2k | features provide a get_feature_vector() function | 16:37 |
| @sonney2k | and they return a bool flag 'do_free' | 16:37 |
| @sonney2k | so whenever one does get_feature_vector() one has to call free_feature_vector(..., do_free) | 16:38 |
| @sonney2k | and then the respecitive string class can clean up | 16:38 |
| @sonney2k | I am tempted to totally drop the free_feature_vector() functions and instead use the SGVector v; v.free_vector() stuff | 16:39 |
| @sonney2k | however this assumes that no feature class will do anything in addtion to free_feature_vector | 16:39 |
| @sonney2k | and I am not sure about this | 16:39 |
| @sonney2k | I don't recall exactly but I think we had features that do something extra | 16:40 |
| @sonney2k | I think filefeatures | 16:40 |
| heiko | mmh | 16:40 |
| heiko | btw the memory block set is not deleted, that is the cause for mem leak | 16:40 |
| @sonney2k | so the only way to get this to work then would be to use the free_feature_vector(SGVector v) for the feature classes | 16:41 |
| @sonney2k | heiko, as I guessed... | 16:41 |
| heiko | sonney2k, but add a SG_UNREF(sg_mallocs) causes memory errors | 16:41 |
| heiko | sonney2k, i will be afk for some time, taking a break | 16:43 |
| @sonney2k | heiko, k, I am adding the malloc stuf to exit_shogun ... lets see what happens | 16:45 |
| @sonney2k | sploving1, did you commit that somewhere? | 16:45 |
| @sonney2k | heiko, I understand why it crashes - it is because it wants to store the de-allocation | 16:54 |
| @sonney2k | but the object is deleted under its feet | 16:54 |
| sploving1 | https://github.com/shogun-toolbox/shogun/commit/c4fc6c56b4039b949f0a939559a46ebad65c0662 | 16:58 |
| @sonney2k | sploving1, and the typecheck typemaps triggers when called in constructor or not? | 17:00 |
| sploving1 | yeap | 17:00 |
| @sonney2k | sploving1, I mean like printf("yes I am in typecheck typemap") and printf("yes this is a valid array\n") | 17:00 |
| sploving1 | I donot understand clearly, can you expain it more ? sonney2k | 17:03 |
| @sonney2k | sploving1, please add some printf's in the typecheck typemap like the ones above | 17:03 |
| @sonney2k | if these trigger on your example we know that the problem is sth else | 17:04 |
| sploving1 | okay. I know | 17:05 |
| @sonney2k | heiko, ok fixed | 17:07 |
| CIA-87 | shogun: Soeren Sonnenburg master * r5f296e7 / (src/shogun/base/DynArray.h src/shogun/base/init.cpp): | 17:07 |
| CIA-87 | shogun: print leaks on exit when configure with --enable-trace-mallocs and do | 17:07 |
| CIA-87 | shogun: proper cleanup - https://github.com/shogun-toolbox/shogun/commit/5f296e7885667071409c47300c54b67bb1f7991d | 17:07 |
| @sonney2k | heiko, I was thinking more about the string features get_function. | 17:07 |
| @sonney2k | and other feature access functions for that matter | 17:07 |
| @sonney2k | if everything is in one function then we have to rely on SGVector v.free_vector() support | 17:08 |
| @sonney2k | heiko, and since nothing in shogun uses this so far (just checked) I am very much in favour of doing it this way | 17:10 |
| @sonney2k | heiko, so removing free_feature_vector from all feature classes and only ever returning SGVector<xxx> with properly set free flag is the way to go | 17:10 |
| @sonney2k | then one would just call v.free_vector() at the end and all good | 17:11 |
| -!- sploving1 [~sploving@210.77.14.219] has left #shogun [] | 17:11 | |
| heiko | sonney2k, ok that sounds good | 17:22 |
| -!- sploving1 [~sploving@210.77.14.219] has joined #shogun | 17:26 | |
| sploving1 | sonney2k, not trigger the typecheck | 17:26 |
| @sonney2k | sploving1, in both cases not? | 17:28 |
| @sonney2k | heiko, the other thing is fixed now | 17:28 |
| heiko | sonney2k, ok | 17:29 |
| heiko | just checked out | 17:29 |
| heiko | currently compiling | 17:29 |
| sploving1 | no. in feats_train=Modshogun::RealFeatures.new | 17:29 |
| sploving1 | feats_train.set_feature_matrix fm_train_real it trigger typecheck and typemap | 17:29 |
| sploving1 | feats_test=Modshogun::RealFeatures.new(fm_test_real) this does not trigger | 17:29 |
| sploving1 | sonney2k, what do you suggest? | 17:29 |
| @sonney2k | sploving1, does that happen with labels too? | 17:30 |
| @sonney2k | I mean when you do Labels([1,2,3]) | 17:30 |
| sploving1 | I have not tried that | 17:30 |
| @sonney2k | vs. x=Labels() x.set_labels([1,2,3]) | 17:30 |
| @sonney2k | (not sure what the ruby syntax is but you get the idea) | 17:31 |
| sploving1 | x=Modshogun::Labels.new([1,2,3]) it works | 17:34 |
| sploving1 | sonney2k, Labels work! | 17:35 |
| @sonney2k | sploving1, hmmhh so then matrix should too | 17:35 |
| sploving1 | maybe the syntax erro | 17:36 |
| heiko | sonney2k, tracing works perfect now | 17:36 |
| sploving1 | but i do not know | 17:36 |
| sploving1 | sonney2, I gtg bye | 17:36 |
| @sonney2k | sploving1, can you show me the example? | 17:36 |
| sploving1 | sonney2k, it is in the example dir | 17:37 |
| @sonney2k | heiko, that memory tracing stuff is tricky/hacky - lots of unwanted side effects... | 17:37 |
| sploving1 | kernel_gaussian_modular | 17:37 |
| @sonney2k | heiko, but all good now -> great :) | 17:37 |
| @bettyboo | strange | 17:37 |
| heiko | everything ok now :) | 17:37 |
| sploving1 | ruby kernel_gaussian_modular.ry can work | 17:38 |
| sploving1 | but when you change it to be feats_test=Modshogun::RealFeatures.new(fm_test_real). it cannot work | 17:38 |
| sploving1 | bye | 17:38 |
| @sonney2k | sploving1, how do I call the example? | 17:38 |
| -!- sploving1 [~sploving@210.77.14.219] has left #shogun [] | 17:38 | |
| @sonney2k | hmmhh, so it has to wait until tomorrow | 17:39 |
| @sonney2k | or serialhex when you are around and can tell me how I can successfully run kernel_gaussian_modular.rb - please say so | 17:39 |
| @sonney2k | heiko, so you think it makes more sense with the get_feature_vector stuff right? | 17:40 |
| heiko | yes, | 17:40 |
| heiko | only problem i see: | 17:40 |
| heiko | feature cache | 17:40 |
| heiko | because now free_feature_vector takes an index | 17:40 |
| heiko | and unlocks the element from the cache | 17:40 |
| @sonney2k | heiko, argh | 17:40 |
| @sonney2k | I missed that | 17:40 |
| @sonney2k | big problem... | 17:41 |
| heiko | one could search | 17:42 |
| heiko | but that makes linear time in contrast to constant time for free | 17:42 |
| @sonney2k | heiko, the only other option I see is to attach some callback function to SGVector | 17:46 |
| @sonney2k | such that this can be called to do exactly such cleanup tasks later | 17:46 |
| @sonney2k | overhead would be one more ptr in SGVector | 17:47 |
| @sonney2k | ptr to some struct that contains a callback function and metadata | 17:48 |
| -!- f-x [~user@117.192.221.29] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] | 17:51 | |
| @sonney2k | heiko, any thoughts? | 17:54 |
| heiko | yes the callback is good | 17:55 |
| heiko | but adds more stuff | 17:55 |
| heiko | so using it will become more difficult | 17:55 |
| heiko | but ok | 17:55 |
| heiko | btw DynArray causes some problems | 17:56 |
| heiko | valgrind sais no leaks | 17:56 |
| heiko | but list_memory_allocs() shows allocated blocks | 17:57 |
| @sonney2k | actually we could even make it slightly better - derive a SGVectorWithCache class | 17:57 |
| heiko | yeah thats sounds better | 17:57 |
| @sonney2k | and overload the virtual free_vector() funciton | 17:57 |
| heiko | that i would like | 17:58 |
| heiko | sonney2k, btw string kernel grid-search now works | 18:00 |
| heiko | (besides list_memory_allocs complaining that there is allocated memory, which is not true) | 18:01 |
| heiko | sonney2k, when i change the name of SGString::length | 18:17 |
| heiko | python does not compile | 18:17 |
| heiko | are there any maps for the types if DataType.h? | 18:18 |
| -!- in3xes_ [~in3xes@180.149.49.227] has joined #shogun | 18:19 | |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 18:23 | |
| heiko | sonney2k, ok got it, swig_typemaps :) | 18:23 |
| @bettyboo | :*) | 18:23 |
| heiko | sonney2k, list_memory_allocs still broken (complains that blocks were reserved in DynArray.h) | 18:24 |
| heiko | pushing string kernel grid-search now | 18:24 |
| -!- in3xes_ is now known as in3xes | 18:28 | |
| -!- in3xes_ [~in3xes@180.149.49.227] has joined #shogun | 18:42 | |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 18:46 | |
| -!- heiko [~heiko@134.91.52.218] has left #shogun [] | 18:46 | |
| -!- blackburn [~blackburn@109.226.104.206] has quit [Ping timeout: 255 seconds] | 19:17 | |
| -!- in3xes_ [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 19:33 | |
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 20:13 | |
| -!- blackburn [~blackburn@109.226.104.206] has joined #shogun | 20:20 | |
| CIA-87 | shogun: Soeren Sonnenburg master * r72b9bef / (25 files in 12 dirs): | 20:25 |
| CIA-87 | shogun: Merge pull request #245 from karlnapf/master | 20:25 |
| CIA-87 | shogun: model selection for string kernels (+31 more commits...) - https://github.com/shogun-toolbox/shogun/commit/72b9bef392f25fd1f0971367b0d574359700d112 | 20:25 |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 20:35 | |
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 20:35 | |
| -!- in3xes_ [~in3xes@180.149.49.227] has joined #shogun | 20:50 | |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 20:54 | |
| -!- in3xes_ is now known as in3xes | 20:56 | |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 240 seconds] | 21:06 | |
| CIA-87 | shogun: Soeren Sonnenburg master * rc8fa327 / src/interfaces/python_static/PythonInterface.cpp : fix compile error in static python interface - https://github.com/shogun-toolbox/shogun/commit/c8fa3276755a73ff426dd10ecd7ddc3aeeb10dfc | 21:19 |
| CIA-87 | shogun: Soeren Sonnenburg master * r4172a45 / examples/undocumented/libshogun/modelselection_grid_search_linear.cpp : don't allocate objects on stack (this did evade the memory tracing) - https://github.com/shogun-toolbox/shogun/commit/4172a4540b588bb845764ab14c3b5f8868e6645d | 21:19 |
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 21:22 | |
| CIA-87 | shogun: Sergey Lisitsyn master * ra45b631 / src/shogun/preprocessor/LocallyLinearEmbedding.cpp : DSYEVR for LLE - https://github.com/shogun-toolbox/shogun/commit/a45b631cc43de354310f4d3ece5414b9fdd11399 | 21:26 |
| CIA-87 | shogun: Sergey Lisitsyn master * r4c5fc86 / (2 files in 2 dirs): Merge branch 'master' of github.com:shogun-toolbox/shogun - https://github.com/shogun-toolbox/shogun/commit/4c5fc86f761bd73f1c2423282da496d10de1f2f6 | 21:26 |
| CIA-87 | shogun: Soeren Sonnenburg master * r1c63169 / examples/undocumented/libshogun/features_copy_subset_string_features.cpp : fix compile error in string subset example - https://github.com/shogun-toolbox/shogun/commit/1c631698486d9708d10e14f91743d095fa99e01d | 21:30 |
| CIA-87 | shogun: Soeren Sonnenburg master * rb2464db / (4 files in 4 dirs): fix compile errors in static interfaces - https://github.com/shogun-toolbox/shogun/commit/b2464db95dfe09f80c0203452dbe1504f91bad74 | 21:30 |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Ping timeout: 258 seconds] | 21:33 | |
| -!- in3xes [~in3xes@180.149.49.227] has joined #shogun | 21:46 | |
| blackburn | sonney2k: is there any packed storage distance matrix routine? | 21:54 |
| blackburn | it seems no.. | 21:55 |
| blackburn | okay, will do later | 21:56 |
| @sonney2k | there is none indeed | 21:57 |
| blackburn | sonney2k: what do you prefer, make some transition to packed storage now or later? | 21:57 |
| @sonney2k | blackburn, ? | 21:57 |
| @sonney2k | for what | 21:58 |
| blackburn | mds, lle, .. | 21:58 |
| blackburn | well it is a big amount of work.. | 21:58 |
| blackburn | hmm and no dsyevr analogue.. | 21:59 |
| blackburn | so I think I should do it later | 21:59 |
| @sonney2k | blackburn, is this only for speed? | 21:59 |
| @sonney2k | or memory? | 21:59 |
| @sonney2k | or both? | 21:59 |
| blackburn | memory-wise | 21:59 |
| blackburn | no speed impact I guess | 21:59 |
| blackburn | it already uses all the things of symmetricity of matrices | 22:00 |
| blackburn | so just /2 memory | 22:00 |
| @sonney2k | you already use symmetry right? | 22:00 |
| @sonney2k | or no? | 22:00 |
| blackburn | I use it in means of some matrix-vector multiplications and so on | 22:01 |
| blackburn | but not memory wise | 22:01 |
| blackburn | I store the whole matrix | 22:01 |
| blackburn | in mds, isomap, lle | 22:01 |
| @sonney2k | blackburn, I don't know ... it is quite some work to change it .... IIRC I did this for custom kernel but no operations on top... | 22:02 |
| blackburn | let's make this change later | 22:02 |
| blackburn | after 1.0 | 22:02 |
| @sonney2k | yeah... | 22:02 |
| blackburn | I guess it is not only my algos - kernels too | 22:02 |
| blackburn | it would be a surprise: "Shogun now uses 1/2 of memory it used before" :D | 22:03 |
| @sonney2k | there are other things to optimize btw | 22:11 |
| @sonney2k | if one uses python, currently everything is copied | 22:11 |
| @sonney2k | and not just in python | 22:12 |
| @sonney2k | now that we use malloc & co we can do some clever hacks | 22:12 |
| @sonney2k | i.e. we can tell a python numpy matrix to no longer own the object | 22:12 |
| blackburn | I will change preprocs to use realloc | 22:12 |
| blackburn | some memory wise eifficiency | 22:13 |
| @sonney2k | and just own the memory | 22:13 |
| @sonney2k | this would work if a numpy array is allocated in fortran order | 22:13 |
| CIA-87 | shogun: Sergey Lisitsyn master * r5ce74be / src/NEWS : Some additions and fixes for NEWS - https://github.com/shogun-toolbox/shogun/commit/5ce74beed864066a3506f85c2a5a1d0251f63e6b | 22:14 |
| @sonney2k | blackburn, order='Fortran' argument | 22:14 |
| -!- in3xes [~in3xes@180.149.49.227] has quit [Quit: Leaving] | 22:14 | |
| blackburn | sonney2k: you forgot a half of algos I did ;) | 22:14 |
| @sonney2k | blackburn, your fault to not update NEWS | 22:15 |
| blackburn | you didn't say we should ;) | 22:15 |
| @sonney2k | blackburn, I didn't say that you should turn shogun upside down | 22:15 |
| @sonney2k | look what you did with all that machine, SGVector etc stuff! | 22:16 |
| blackburn | hey you did, not me :D | 22:16 |
| blackburn | I think I will focus on doc this night | 22:16 |
| @sonney2k | blackburn, but you complained like 100 times or so... | 22:16 |
| @sonney2k | so I had no choice | 22:16 |
| blackburn | you are the Lenin, I'm just Krupskaya ahaha | 22:16 |
| @sonney2k | much worse, I only say Stalingrad | 22:17 |
| blackburn | hey but things become much better in some ways | 22:17 |
| blackburn | e.g. no crazy typemaps we had before | 22:18 |
| @sonney2k | blackburn, yes it is the 1945 of shogun - I totally surrendered ;-) | 22:19 |
| @sonney2k | but more seriously - I agree | 22:19 |
| @sonney2k | the only problem we have is that the SGVector transition is not finished | 22:20 |
| blackburn | we did for interfaces | 22:20 |
| @sonney2k | we really need to change all the get/set functions | 22:20 |
| @sonney2k | blackburn, not for all... | 22:20 |
| blackburn | hmm | 22:20 |
| @sonney2k | and we need to do it for the internal storage to | 22:20 |
| @sonney2k | to | 22:21 |
| @sonney2k | too | 22:21 |
| blackburn | just recalled, fyi I finish work on algos on 6th of Aug or so | 22:21 |
| blackburn | *as planned | 22:21 |
| blackburn | after that we will try to do some bioinf stuff with chris | 22:21 |
| @sonney2k | blackburn, you are a machine | 22:21 |
| @sonney2k | you mean as example? | 22:21 |
| blackburn | if it successful - yes | 22:22 |
| blackburn | is* | 22:22 |
| blackburn | we'll try to do some manifold learning for promoters | 22:22 |
| blackburn | I'm not sure how it would work but we'll make a try hah | 22:22 |
| @sonney2k | blackburn, which distance? | 22:22 |
| blackburn | I don't know anything yet | 22:23 |
| @sonney2k | may I suggest you use the weighteddegreepositionkernel and create a distance from it | 22:23 |
| blackburn | don't we have it now? | 22:23 |
| @sonney2k | (promoter detection was my subject...) | 22:23 |
| @sonney2k | yes it is available | 22:23 |
| @sonney2k | if you want to be extra good/clever, you use a combination of 3 kernels | 22:24 |
| blackburn | the problem is LLE family algos work in euclidean space.. | 22:24 |
| @sonney2k | I can point you to a paper or my diss if you want to know which - but hey actually in applications/arts there is the code for this | 22:24 |
| @sonney2k | blackburn, so? | 22:24 |
| blackburn | I mean I can apply only distance-based preprocessors | 22:25 |
| blackburn | with kernels, etc | 22:25 |
| @sonney2k | kernel(x_i,x_j) = <Phi(x_i), Phi(x_j)> | 22:25 |
| @sonney2k | <.,.> is dot product | 22:26 |
| blackburn | so how to apply LLE with kernel? | 22:26 |
| @sonney2k | blackburn, use KernelDistance | 22:26 |
| blackburn | there is no dot product inside this algo | 22:26 |
| blackburn | it depends on feature vectors itself | 22:27 |
| blackburn | not only pairwise distances | 22:27 |
| @sonney2k | blackburn, then no chance | 22:27 |
| blackburn | only MDS, Isomap and Laplacian Eigenmaps involves distances | 22:27 |
| blackburn | bad thing to me :( | 22:27 |
| blackburn | well if I found some euclidean representation or so | 22:28 |
| blackburn | it would work | 22:28 |
| blackburn | sonney2k: btw your dissertation is awesome | 22:29 |
| @sonney2k | blackburn, well it is possible when you extract all n-grams before and after the promoter | 22:33 |
| @sonney2k | that works pretty well already | 22:33 |
| @sonney2k | Phi(x) for the WD kernel is just too big | 22:33 |
| @sonney2k | though you can use a WD kernel of very low degree, say 1-3 | 22:33 |
| @sonney2k | then it would work too | 22:33 |
| @sonney2k | blackburn, can you use dotfeatures? | 22:34 |
| blackburn | sonney2k: for what? | 22:34 |
| @sonney2k | for your distance stuff | 22:34 |
| @sonney2k | you won't have feature matrix access | 22:34 |
| @sonney2k | *argh* | 22:34 |
| blackburn | distances for MDS, Isomap and Laplacian Eigenmaps and simple dense features for LLE family | 22:35 |
| blackburn | I don't have to work with features itself only with MDS, Isomap and Lapl.eigmaps | 22:35 |
| blackburn | dotfeatures will work too I guess, if I can get some matrix from it ;) | 22:36 |
| -!- in3xes [~in3xes@180.149.49.230] has joined #shogun | 22:37 | |
| blackburn | sonney2k: you become activated as I said about bioinf :) | 22:38 |
| @sonney2k | adding a single virtual functions increases the size of an object to at least 16 bytes | 22:38 |
| @sonney2k | blackburn, not really | 22:39 |
| @sonney2k | blackburn, I am still much more interested in the algorithms than the application | 22:39 |
| @sonney2k | but of course this varies over time | 22:39 |
| * blackburn just looked over work he done - it seems he is interested in eigenvalues computation | 22:41 | |
| blackburn | :D | 22:41 |
| @sonney2k | :) | 22:43 |
| @sonney2k | virtual functions are actually not *that* bad | 22:43 |
| @sonney2k | blackburn, I think of deriving from SGVector | 22:43 |
| blackburn | sonney2k: what to derive? | 22:44 |
| @sonney2k | some vector class that can have additional functions that are called when the vector is freed | 22:44 |
| blackburn | what is the example of such funcs? | 22:45 |
| @sonney2k | blackburn, when we currently do get_feature_vector in e.g. SimpleFeatures we have to call free_feature_vector later on to free it (potentially) | 22:48 |
| @sonney2k | now there is a case where the feature matrix is not in memory | 22:48 |
| @sonney2k | then just one vector is computed and *cached* | 22:48 |
| blackburn | I see | 22:48 |
| @sonney2k | on free_feature_vector cache is updated | 22:49 |
| @sonney2k | now when we instead of the orginal free_feature_vector function want to call SGVector::free_vector() we need to do sth about it | 22:49 |
| @sonney2k | that is we need to overload the free* function | 22:49 |
| @sonney2k | and also recall the index of the vector | 22:50 |
| @sonney2k | the reationale here is that one only ever calls SGVector based methods when later manipulating the vector | 22:50 |
| blackburn | I see | 22:51 |
| @sonney2k | that would indeed work - the problem is now that SGVector is a templated function... | 22:53 |
| @sonney2k | class | 22:53 |
| blackburn | just ran ltsa with 6000 examples | 22:56 |
| blackburn | it took 874mb of ram | 22:56 |
| blackburn | ho-ho | 22:56 |
| @sonney2k | compiling shogun takes 1.5G - so that is nothing :D | 22:58 |
| blackburn | will try 12000 | 22:58 |
| blackburn | 127s taken | 22:59 |
| blackburn | hmm | 22:59 |
| @sonney2k | isn't it growing n^2 or worse? | 22:59 |
| blackburn | memory or speed? | 22:59 |
| @sonney2k | memory | 22:59 |
| blackburn | oh yes, n^2 | 22:59 |
| blackburn | I shouldn't run 12000 :D | 22:59 |
| blackburn | may be 10000 is possible on my laptop | 22:59 |
| @sonney2k | blackburn, better compute how much mem it reuqired | 23:00 |
| @sonney2k | s | 23:00 |
| @sonney2k | requires | 23:00 |
| blackburn | 2.1g for 10000 | 23:01 |
| blackburn | took a little swap for computations | 23:01 |
| @sonney2k | I don't have that much mem here | 23:02 |
| @sonney2k | and I disabled linux' overcommit | 23:02 |
| blackburn | didn't you have macbook with >4? | 23:03 |
| @sonney2k | blackburn, how bad do you think it is to grow SGVector by 8 bytes? | 23:03 |
| @sonney2k | 8G | 23:03 |
| blackburn | why don't you have 2.1? ;) | 23:03 |
| @sonney2k | yes el-cheapo memory | 23:03 |
| blackburn | I think it is not bad at all | 23:03 |
| @sonney2k | because there are no modules of size 21G :D | 23:04 |
| blackburn | 2.1 | 23:04 |
| blackburn | not 21 | 23:04 |
| @sonney2k | blackburn, I am only concerned about short vecotrs | 23:04 |
| @sonney2k | but probably rare - you are right | 23:04 |
| blackburn | aren't we already have redundant vector len? | 23:04 |
| blackburn | IIRC we do badass large-scale things so a little overhead is nothing hehe | 23:06 |
| @sonney2k | blackburn, redundant? | 23:08 |
| @sonney2k | I mean we need ptr & length... | 23:08 |
| blackburn | yes but we store length both in some internals | 23:08 |
| blackburn | and in sgvectors | 23:08 |
| blackburn | as much length's as much sgvectors we have | 23:09 |
| blackburn | right? | 23:09 |
| @sonney2k | that is differnent though - I mean we have to pass the length anyway | 23:09 |
| blackburn | hmm | 23:11 |
| blackburn | failed with shogunexception | 23:11 |
| blackburn | hehe | 23:11 |
| @bettyboo | 8) | 23:12 |
| blackburn | I guess no memory to store new features | 23:12 |
| blackburn | sonney2k: http://www.youtube.com/watch?v=FhWtJ2OwZ4A&feature=player_embedded seen this? :) | 23:14 |
| @sonney2k | blackburn, didn't it say so 'no new memory' ? | 23:14 |
| blackburn | sonney2k: no, just shogun exception | 23:15 |
| @sonney2k | I hope they have taken out the battery... | 23:16 |
| blackburn | will it explode? | 23:16 |
| @sonney2k | blackburn, btw I discovered some issue when the new trace malloc stuff won't work | 23:34 |
| blackburn | which one? | 23:34 |
| @sonney2k | as soon as an object is allocated on stack - we have means to discover that it gets destroyed | 23:34 |
| --- Log closed Fri Jul 29 00:00:46 2011 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!