Open in new window / Try shogun cloud
--- Log opened Sat Sep 15 00:00:17 2012
-!- vikram360 [~vikram360@] has joined #shogun03:39
-!- vikram360 [~vikram360@] has quit [Ping timeout: 245 seconds]04:11
-!- vikram360 [~vikram360@] has joined #shogun04:12
-!- vikram360 [~vikram360@] has quit [Ping timeout: 272 seconds]04:51
-!- vikram360 [~vikram360@] has joined #shogun04:52
-!- vikram360 [~vikram360@] has quit [Read error: No route to host]05:06
-!- vikram360 [~vikram360@] has joined #shogun05:06
-!- vikram360 [~vikram360@] has quit [Ping timeout: 272 seconds]05:15
-!- vikram360 [~vikram360@] has joined #shogun05:15
-!- vikram360 [~vikram360@] has quit [Ping timeout: 268 seconds]06:10
-!- vikram360 [~vikram360@] has joined #shogun06:47
-!- vikram360 [~vikram360@] has quit [Ping timeout: 252 seconds]07:50
-!- vikram360 [~vikram360@] has joined #shogun08:01
-!- vikram360 [~vikram360@] has quit [Ping timeout: 252 seconds]08:30
-!- vikram360 [~vikram360@] has joined #shogun08:31
-!- vikram360 [~vikram360@] has quit [Ping timeout: 246 seconds]08:36
-!- vikram360 [~vikram360@] has joined #shogun08:37
-!- vikram360 [~vikram360@] has quit [Ping timeout: 255 seconds]10:00
-!- vikram360 [~vikram360@] has joined #shogun10:00
-!- vikram360 [~vikram360@] has quit [Ping timeout: 240 seconds]11:17
-!- vikram360 [~vikram360@] has joined #shogun11:17
-!- vikram360 [~vikram360@] has quit [Ping timeout: 260 seconds]11:23
-!- vikram360 [~vikram360@] has joined #shogun11:24
-!- n4nd0 [] has joined #shogun12:22
-!- vikram360 [~vikram360@] has quit [Ping timeout: 272 seconds]12:37
-!- vikram360 [~vikram360@] has joined #shogun12:41
-!- n4nd0 [] has quit [Quit: leaving]13:08
-!- blackburn [~blackburn@] has joined #shogun14:12
-!- vikram360 [~vikram360@] has quit [Ping timeout: 272 seconds]14:19
-!- vikram360 [~vikram360@] has joined #shogun16:19
CIA-36shogun: Sergey Lisitsyn master * r6697048 / (4 files in 4 dirs): Turned SGStringList into the object derived from the SGReferencedData. Closes #772 -
-!- vikram360 [~vikram360@] has quit [Ping timeout: 252 seconds]16:38
-!- vikram360 [~vikram360@] has joined #shogun16:39
-!- vikram360 [~vikram360@] has quit [Ping timeout: 252 seconds]16:53
-!- vikram360 [~vikram360@] has joined #shogun16:53
-!- vikram360 [~vikram360@] has quit [Ping timeout: 244 seconds]17:17
-!- vikram360 [~vikram360@] has joined #shogun17:17
shogun-buildbot_build #533 of deb3 - modular_interfaces is complete: Failure [failed test python_modular]  Build details are at  blamelist: Sergey Lisitsyn <>17:27
-!- vikram360 [~vikram360@] has quit [Ping timeout: 244 seconds]17:42
-!- vikram360 [~vikram360@] has joined #shogun17:43
CIA-36shogun: Sergey Lisitsyn master * r4217b41 / src/shogun/features/StringFeatures.cpp : Fix for changes in #772 - memory-wise correct get_features in StringFeatures -
CIA-36shogun: Sergey Lisitsyn master * re8ea95e / (8 files in 3 dirs): Made TRON independent of BLAS. Closes #783. -
shogun-buildbot_build #419 of bsd1 - libshogun is complete: Failure [failed compile]  Build details are at  blamelist: Sergey Lisitsyn <>18:14
shogun-buildbot_build #420 of bsd1 - libshogun is complete: Success [build successful]  Build details are at
CIA-36shogun: Sergey Lisitsyn master * rfabddb3 / src/shogun/transfer/multitask/MultitaskKernelMaskPairNormalizer.h : Added missed includes in multitask mask pair normalizer -
shogun-buildbot_build #534 of deb3 - modular_interfaces is complete: Failure [failed test lua_modular]  Build details are at  blamelist: Sergey Lisitsyn <>18:37
shogun-buildbot_build #535 of deb3 - modular_interfaces is complete: Failure [failed test lua_modular]  Build details are at  blamelist: Sergey Lisitsyn <>18:57
-!- n4nd0 [] has joined #shogun19:09
shogun-buildbot_build #536 of deb3 - modular_interfaces is complete: Failure [failed test lua_modular]  Build details are at  blamelist: Sergey Lisitsyn <>19:28
-!- heiko1 [] has joined #shogun19:57
-!- blackburn1 [~blackburn@] has joined #shogun20:03
-!- blackburn [~blackburn@] has quit [Ping timeout: 272 seconds]20:05
blackburn1heiko1: hey, did you solve that problem20:18
heiko1blackburn, hi I am actually just working on it20:18
blackburn1heiko1: the reason is temp(); instead of temp;20:18
heiko1SHOGUN is missing a datastructure for SGReferenced btw20:18
blackburn1if you didn't read my msg20:18
blackburn1what do you mean?20:18
heiko1something which is easy to serialise20:18
heiko1e.g. a list of vectors20:19
blackburn1collection of sgreferenceddata?20:19
heiko1map for example20:19
heiko1why did we not inherit from CSGObject ?20:19
blackburn1different kind of reference counting20:19
heiko1but its adding difficulkties20:20
blackburn1it is kind of proxy for object like sgobject20:20
heiko1since all data structures with reference counting do not work for vector/matrix20:20
heiko1also serialisation does not work20:20
heiko1(I mean when in CMap for example)20:20
heiko1Ill continue on the label stuff now20:21
blackburn1heiko1: I have no idea how can we generalize that20:22
heiko1for example via a global base class20:22
blackburn1what is the interface?20:22
heiko1one single interface for referenced data might be good20:23
heiko1and for serialisation20:23
heiko1is there any reason why the SGReferenced structures do not inherit from sgobject? except for the different reference counting?20:24
blackburn1I see no way actually - refcounting works in totally different way20:24
blackburn1isn't that enough? :)20:24
blackburn1we never destroy sgobject during passing it around20:24
blackburn1sgreferenceddata is destroyed all the time20:24
heiko1but if we use these smart pointers ....20:25
heiko1that are planned for sgobjects?20:25
heiko1anyway thats not for now, I was just wondering20:25
blackburn1yeah that would work then probably20:25
blackburn1btw how smart pointer -> works20:25
blackburn1do you know?20:25
heiko1no :)20:25
blackburn1it is overloaded to provide method from proxy class?20:25
blackburn1argh s/proxy/main20:26
heiko1I guess I find it just a bit irritating to have two systems20:26
heiko1since all structures do not work anymore20:26
heiko1and serial also doesnt20:26
heiko1well, I will do this label stuff first :)20:26
blackburn1sg ref / unref removing sounds like a huge work20:27
blackburn1heiko1: okay I have kind of plan20:29
blackburn1probably it won't be such a huge change20:30
blackburn1well can be done automatically partially20:30
blackburn1we could separate two classes20:30
blackburn1SGObject -> SGObject, SGObjectImpl20:30
blackburn1bad thing is that we double number of classes20:31
blackburn1SGObject just transparently provides same interface objectimpl provides20:31
heiko1dont know ....20:31
heiko1I will continue on the labels first20:32
blackburn1heiko1: did you get my idea?20:32
heiko1actually there might be some problems with that already, which should be solved before anything new is done20:32
heiko1I get the idea yes20:32
blackburn1SGObject is a smart pointer actually20:32
blackburn1I want to try that20:32
heiko1hey blackburn20:33
heiko1how would you solve this label thing, it gives me a bit of a headache20:33
blackburn1hello, it's been a while20:33
heiko1lol :D20:33
blackburn1how are you?20:33
blackburn1okay okay20:33
heiko1I want to have a map of SGVectors20:33
blackburn1what is the problem?20:33
heiko1and a "current" SGVector20:33
heiko1this current one has to be a pointer20:33
blackburn1vectors are keys or vectors are values?20:33
heiko1otherwise changes are not made in the vectors in the map20:34
heiko1vectors are values20:34
heiko1keys are strings20:34
blackburn1vector-values works already I think20:34
blackburn1what is the problem?20:34
heiko1pointers on SGVectors20:34
heiko1I would like to avoid these20:34
blackburn1ehh why?20:34
heiko1they cannot be handled by shogun20:34
heiko1we cannot even register them as parameters20:35
blackburn1yes, we register pointers to contents20:35
heiko1If we use them inside implementations, its fine but if they are class members things get hairy20:35
heiko1yes we register these pointers20:35
heiko1but this is not the same thing20:35
heiko1since not the vector should be stored but the pointer20:35
blackburn1what is the problem with CMap<const char*, SGVector<float64_t> >?20:36
heiko1thats cool20:36
heiko1but how to store the "current" vector20:36
blackburn1why do you need that "current" vector?20:36
heiko1in order to access20:36
heiko1by set_value /confidence method20:36
blackburn1we don't care much about concrete instance20:36
blackburn1pointer to data stays the same anyway20:36
heiko1so if I store the current under SGVector20:37
heiko1without pointer20:37
blackburn1well even if it is a different instance20:37
blackburn1if there is no memory leak or anything20:37
blackburn1you will have the same data underlying20:37
heiko1I do this, but it doesnt work, let me check my implementation20:37
blackburn1in general we should just never use pointers to vectors20:38
blackburn1because sgvector is a smart pointer to pointer20:38
blackburn1to data pointer I mean20:38
blackburn1sgvector1 -> data <- sgvector220:39
blackburn1heiko1: if you change any of them ^ you change both20:39
heiko1here is the problem20:39
heiko1there is a method set_values20:39
heiko1which replaces the current vector by the given one20:40
heiko1but if I put this in the "current" vector, the vector in the map does not get the array20:40
blackburn1what is the class that method is of?20:40
heiko1set_confidences .. I change the name20:40
blackburn1I've got the problem you met20:41
heiko1I guess I just have to change in the map also ....20:41
heiko1let me try20:41
blackburn1yes but that's not so cool now20:41
heiko1the vector data is initialised with NULL in the beginning20:41
blackburn1we would have to handle everything twice20:42
heiko1so how to replace this null pointer by actual data20:42
heiko1I know20:42
heiko1this is the problem20:42
heiko1whenever the current vector is changed (by means of data array is replaced by another one) this problem appeats20:42
heiko1using pointers would avoid this, but thats ugly20:43
blackburn1yeah pointers are transparent20:43
blackburn1you are happy anyway - no need to handle that20:43
blackburn1but now we are not happy :D20:43
heiko1yeah I mean, this pointers to SGVector screws a lot of things20:44
heiko1and btw also, CMap with SGVector as value is not serialisable20:45
heiko1so adding this would break CLabels being serializable, which sucks20:45
heiko1man, maybe its better to just add another vector20:46
heiko1and having two - fixed20:46
heiko1or three20:46
heiko1scores, confidences, binary20:46
blackburn1well I've added a vector of vectors to multiclass labels20:47
heiko1vector of vectors?20:47
heiko1thats not serialisable20:47
blackburn1yeah to store scores20:47
blackburn1yeah I know20:47
heiko1having one superclass would avoid all this20:47
heiko1having data-structures for all objects we use in shogun20:48
heiko1that would simplify everything so much20:48
heiko1just another CSGObject derived class for vectors and matrices20:48
heiko1then we could just store CDynamicObjectArrays of vectors20:48
heiko1and done20:48
heiko1and SGVector would just be for numerical data20:49
blackburn1we would need to change pretty much for that20:50
heiko1but the Labels system as we want it wont work with the current approach20:50
heiko1also, this non-serialisation is not good20:51
heiko1and having no data-structures for SGReferenced also sucks20:51
heiko1maybe we should talk with the others about that.20:52
heiko1Ill wait with the labels until this is sorted20:52
blackburn1well I could try to make sgobject a smart pointer20:53
blackburn1however - can you explain how that would work?20:53
heiko1no :D20:53
blackburn1I mean why that would make serialization work20:53
heiko1these two classes also are a bit strange20:54
heiko1serialisation just requires everything to be registered20:54
heiko1and that datastructures either get SGObjects or numerical data20:54
heiko1anything else wont work20:54
heiko1also I think for reasons of simplicity we should have one base class for everything20:54
heiko1and not two kinds of objects20:55
blackburn1now they are conceptually different20:55
blackburn1so nothing to do with it yet20:55
heiko1nothing to do with it yet? what does that mean?20:55
blackburn1argh I forgot it is kind of phrase20:56
blackburn1I mean we can't do nothing :)20:56
blackburn1can do nothing!20:56
heiko1would it be so bad to treat vectors/matrices as the rest of shogun objects? We would have to use SG_REF all the time right?20:57
blackburn1way too bad, current way is so cool20:58
heiko1ok, lets say things stay like this20:59
heiko1what about data structures?20:59
heiko1and what about these pointers?20:59
heiko1maybe I should try to do that for Labels and then see21:00
heiko1I mean use a SGVector pointer for the current one and just add that to the parameter framework21:00
-!- vikram360 [~vikram360@] has quit [Ping timeout: 255 seconds]21:00
blackburn1one way I see21:02
blackburn1is to add a method21:02
blackburn1that pick ups updated value from class to the map21:02
blackburn1so each time you change labels or confidences21:02
-!- vikram360 [~vikram360@] has joined #shogun21:02
blackburn1you call some method that does update21:03
heiko1this would have to be added to every change21:05
heiko1what about the pointer?21:05
heiko1the map would break serialisation anyway :)21:05
heiko1CMap <char*, SGVector> I mean21:05
blackburn1if you forgot to fire that 'changed' event you will serialize old vector21:07
blackburn1nothing really bad21:07
heiko1CMap does not support serialisation21:07
heiko1ok I mean I could just two lists instead21:08
heiko1these are serialisable21:08
heiko1but not if type is SGVector21:08
heiko1also, if one forget to fire change, then changing the "current" vector breaks things21:08
blackburn1oh well21:13
heiko1maybe pointer solution is best21:16
heiko1and having two lists instead of a map21:16
heiko1access to current values changes everywhere but tihhs is easy to sport since compile errors on change21:17
heiko1I gotta go now, lets discuss later21:18
-!- heiko1 [] has left #shogun []21:18
-!- n4nd0 [] has quit [Quit: leaving]22:32
--- Log closed Sun Sep 16 00:00:17 2012