| --- Log opened Sat Sep 15 00:00:17 2012 | ||
| -!- vikram360 [~vikram360@117.192.179.58] has joined #shogun | 03:39 | |
| -!- vikram360 [~vikram360@117.192.179.58] has quit [Ping timeout: 245 seconds] | 04:11 | |
| -!- vikram360 [~vikram360@117.192.177.213] has joined #shogun | 04:12 | |
| -!- vikram360 [~vikram360@117.192.177.213] has quit [Ping timeout: 272 seconds] | 04:51 | |
| -!- vikram360 [~vikram360@117.192.175.124] has joined #shogun | 04:52 | |
| -!- vikram360 [~vikram360@117.192.175.124] has quit [Read error: No route to host] | 05:06 | |
| -!- vikram360 [~vikram360@117.192.183.112] has joined #shogun | 05:06 | |
| -!- vikram360 [~vikram360@117.192.183.112] has quit [Ping timeout: 272 seconds] | 05:15 | |
| -!- vikram360 [~vikram360@117.192.183.112] has joined #shogun | 05:15 | |
| -!- vikram360 [~vikram360@117.192.183.112] has quit [Ping timeout: 268 seconds] | 06:10 | |
| -!- vikram360 [~vikram360@117.192.178.128] has joined #shogun | 06:47 | |
| -!- vikram360 [~vikram360@117.192.178.128] has quit [Ping timeout: 252 seconds] | 07:50 | |
| -!- vikram360 [~vikram360@117.192.187.113] has joined #shogun | 08:01 | |
| -!- vikram360 [~vikram360@117.192.187.113] has quit [Ping timeout: 252 seconds] | 08:30 | |
| -!- vikram360 [~vikram360@117.192.163.23] has joined #shogun | 08:31 | |
| -!- vikram360 [~vikram360@117.192.163.23] has quit [Ping timeout: 246 seconds] | 08:36 | |
| -!- vikram360 [~vikram360@117.192.170.160] has joined #shogun | 08:37 | |
| -!- vikram360 [~vikram360@117.192.170.160] has quit [Ping timeout: 255 seconds] | 10:00 | |
| -!- vikram360 [~vikram360@117.192.166.143] has joined #shogun | 10:00 | |
| -!- vikram360 [~vikram360@117.192.166.143] has quit [Ping timeout: 240 seconds] | 11:17 | |
| -!- vikram360 [~vikram360@117.192.174.67] has joined #shogun | 11:17 | |
| -!- vikram360 [~vikram360@117.192.174.67] has quit [Ping timeout: 260 seconds] | 11:23 | |
| -!- vikram360 [~vikram360@117.192.177.69] has joined #shogun | 11:24 | |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 12:22 | |
| -!- vikram360 [~vikram360@117.192.177.69] has quit [Ping timeout: 272 seconds] | 12:37 | |
| -!- vikram360 [~vikram360@117.192.177.69] has joined #shogun | 12:41 | |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 13:08 | |
| -!- blackburn [~blackburn@37.61.181.173] has joined #shogun | 14:12 | |
| -!- vikram360 [~vikram360@117.192.177.69] has quit [Ping timeout: 272 seconds] | 14:19 | |
| -!- vikram360 [~vikram360@117.216.146.194] has joined #shogun | 16:19 | |
| CIA-36 | shogun: Sergey Lisitsyn master * r6697048 / (4 files in 4 dirs): Turned SGStringList into the object derived from the SGReferencedData. Closes #772 - http://git.io/iAGHlw | 16:25 |
|---|---|---|
| -!- vikram360 [~vikram360@117.216.146.194] has quit [Ping timeout: 252 seconds] | 16:38 | |
| -!- vikram360 [~vikram360@117.192.164.60] has joined #shogun | 16:39 | |
| -!- vikram360 [~vikram360@117.192.164.60] has quit [Ping timeout: 252 seconds] | 16:53 | |
| -!- vikram360 [~vikram360@117.192.175.32] has joined #shogun | 16:53 | |
| -!- vikram360 [~vikram360@117.192.175.32] has quit [Ping timeout: 244 seconds] | 17:17 | |
| -!- vikram360 [~vikram360@117.192.173.160] has joined #shogun | 17:17 | |
| shogun-buildbot_ | build #533 of deb3 - modular_interfaces is complete: Failure [failed test python_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/533 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 17:27 |
| -!- vikram360 [~vikram360@117.192.173.160] has quit [Ping timeout: 244 seconds] | 17:42 | |
| -!- vikram360 [~vikram360@117.216.149.198] has joined #shogun | 17:43 | |
| CIA-36 | shogun: Sergey Lisitsyn master * r4217b41 / src/shogun/features/StringFeatures.cpp : Fix for changes in #772 - memory-wise correct get_features in StringFeatures - http://git.io/daCy6w | 18:08 |
| CIA-36 | shogun: Sergey Lisitsyn master * re8ea95e / (8 files in 3 dirs): Made TRON independent of BLAS. Closes #783. - http://git.io/j6nM8g | 18:09 |
| shogun-buildbot_ | build #419 of bsd1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/419 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 18:14 |
| shogun-buildbot_ | build #420 of bsd1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/420 | 18:28 |
| CIA-36 | shogun: Sergey Lisitsyn master * rfabddb3 / src/shogun/transfer/multitask/MultitaskKernelMaskPairNormalizer.h : Added missed includes in multitask mask pair normalizer - http://git.io/LjK32Q | 18:34 |
| shogun-buildbot_ | build #534 of deb3 - modular_interfaces is complete: Failure [failed test lua_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/534 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 18:37 |
| shogun-buildbot_ | build #535 of deb3 - modular_interfaces is complete: Failure [failed test lua_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/535 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 18:57 |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 19:09 | |
| shogun-buildbot_ | build #536 of deb3 - modular_interfaces is complete: Failure [failed test lua_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/536 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 19:28 |
| -!- heiko1 [~heiko@host86-180-223-130.range86-180.btcentralplus.com] has joined #shogun | 19:57 | |
| -!- blackburn1 [~blackburn@188.168.2.61] has joined #shogun | 20:03 | |
| -!- blackburn [~blackburn@37.61.181.173] has quit [Ping timeout: 272 seconds] | 20:05 | |
| blackburn1 | heiko1: hey, did you solve that problem | 20:18 |
| blackburn1 | ? | 20:18 |
| heiko1 | blackburn, hi I am actually just working on it | 20:18 |
| blackburn1 | heiko1: the reason is temp(); instead of temp; | 20:18 |
| heiko1 | SHOGUN is missing a datastructure for SGReferenced btw | 20:18 |
| blackburn1 | if you didn't read my msg | 20:18 |
| blackburn1 | what do you mean? | 20:18 |
| heiko1 | something which is easy to serialise | 20:18 |
| heiko1 | e.g. a list of vectors | 20:19 |
| blackburn1 | collection of sgreferenceddata? | 20:19 |
| heiko1 | yeah | 20:19 |
| heiko1 | map for example | 20:19 |
| heiko1 | why did we not inherit from CSGObject ? | 20:19 |
| blackburn1 | different kind of reference counting | 20:19 |
| heiko1 | yeah | 20:19 |
| heiko1 | but its adding difficulkties | 20:20 |
| blackburn1 | it is kind of proxy for object like sgobject | 20:20 |
| heiko1 | since all data structures with reference counting do not work for vector/matrix | 20:20 |
| heiko1 | also serialisation does not work | 20:20 |
| heiko1 | (I mean when in CMap for example) | 20:20 |
| heiko1 | anyway | 20:21 |
| heiko1 | Ill continue on the label stuff now | 20:21 |
| blackburn1 | heiko1: I have no idea how can we generalize that | 20:22 |
| heiko1 | for example via a global base class | 20:22 |
| blackburn1 | what is the interface? | 20:22 |
| heiko1 | one single interface for referenced data might be good | 20:23 |
| heiko1 | and for serialisation | 20:23 |
| heiko1 | is there any reason why the SGReferenced structures do not inherit from sgobject? except for the different reference counting? | 20:24 |
| blackburn1 | I see no way actually - refcounting works in totally different way | 20:24 |
| blackburn1 | isn't that enough? :) | 20:24 |
| blackburn1 | we never destroy sgobject during passing it around | 20:24 |
| heiko1 | true | 20:24 |
| blackburn1 | sgreferenceddata is destroyed all the time | 20:24 |
| heiko1 | but if we use these smart pointers .... | 20:25 |
| heiko1 | that are planned for sgobjects? | 20:25 |
| heiko1 | anyway thats not for now, I was just wondering | 20:25 |
| blackburn1 | yeah that would work then probably | 20:25 |
| blackburn1 | btw how smart pointer -> works | 20:25 |
| blackburn1 | do you know? | 20:25 |
| heiko1 | no :) | 20:25 |
| blackburn1 | it is overloaded to provide method from proxy class? | 20:25 |
| blackburn1 | argh s/proxy/main | 20:26 |
| heiko1 | I guess I find it just a bit irritating to have two systems | 20:26 |
| heiko1 | since all structures do not work anymore | 20:26 |
| heiko1 | and serial also doesnt | 20:26 |
| heiko1 | well, I will do this label stuff first :) | 20:26 |
| blackburn1 | sg ref / unref removing sounds like a huge work | 20:27 |
| heiko1 | indeed | 20:28 |
| blackburn1 | heiko1: okay I have kind of plan | 20:29 |
| blackburn1 | probably it won't be such a huge change | 20:30 |
| blackburn1 | well can be done automatically partially | 20:30 |
| blackburn1 | we could separate two classes | 20:30 |
| blackburn1 | SGObject -> SGObject, SGObjectImpl | 20:30 |
| blackburn1 | bad thing is that we double number of classes | 20:31 |
| blackburn1 | SGObject just transparently provides same interface objectimpl provides | 20:31 |
| heiko1 | dont know .... | 20:31 |
| heiko1 | I will continue on the labels first | 20:32 |
| blackburn1 | heiko1: did you get my idea? | 20:32 |
| heiko1 | actually there might be some problems with that already, which should be solved before anything new is done | 20:32 |
| heiko1 | I get the idea yes | 20:32 |
| blackburn1 | SGObject is a smart pointer actually | 20:32 |
| blackburn1 | I want to try that | 20:32 |
| heiko1 | hey blackburn | 20:33 |
| heiko1 | how would you solve this label thing, it gives me a bit of a headache | 20:33 |
| blackburn1 | hello, it's been a while | 20:33 |
| blackburn1 | :D | 20:33 |
| heiko1 | lol :D | 20:33 |
| blackburn1 | how are you? | 20:33 |
| blackburn1 | okay okay | 20:33 |
| heiko1 | I want to have a map of SGVectors | 20:33 |
| blackburn1 | what is the problem? | 20:33 |
| heiko1 | and a "current" SGVector | 20:33 |
| heiko1 | this current one has to be a pointer | 20:33 |
| blackburn1 | vectors are keys or vectors are values? | 20:33 |
| heiko1 | otherwise changes are not made in the vectors in the map | 20:34 |
| heiko1 | vectors are values | 20:34 |
| heiko1 | keys are strings | 20:34 |
| blackburn1 | vector-values works already I think | 20:34 |
| blackburn1 | what is the problem? | 20:34 |
| heiko1 | pointers on SGVectors | 20:34 |
| heiko1 | I would like to avoid these | 20:34 |
| blackburn1 | ehh why? | 20:34 |
| heiko1 | they cannot be handled by shogun | 20:34 |
| heiko1 | we cannot even register them as parameters | 20:35 |
| blackburn1 | yes, we register pointers to contents | 20:35 |
| heiko1 | If we use them inside implementations, its fine but if they are class members things get hairy | 20:35 |
| heiko1 | yes we register these pointers | 20:35 |
| heiko1 | but this is not the same thing | 20:35 |
| heiko1 | since not the vector should be stored but the pointer | 20:35 |
| blackburn1 | what is the problem with CMap<const char*, SGVector<float64_t> >? | 20:36 |
| heiko1 | thats cool | 20:36 |
| heiko1 | but how to store the "current" vector | 20:36 |
| heiko1 | ? | 20:36 |
| blackburn1 | why do you need that "current" vector? | 20:36 |
| heiko1 | in order to access | 20:36 |
| heiko1 | by set_value /confidence method | 20:36 |
| blackburn1 | we don't care much about concrete instance | 20:36 |
| blackburn1 | pointer to data stays the same anyway | 20:36 |
| heiko1 | ok | 20:36 |
| heiko1 | so if I store the current under SGVector | 20:37 |
| heiko1 | without pointer | 20:37 |
| blackburn1 | well even if it is a different instance | 20:37 |
| blackburn1 | if there is no memory leak or anything | 20:37 |
| blackburn1 | you will have the same data underlying | 20:37 |
| heiko1 | I do this, but it doesnt work, let me check my implementation | 20:37 |
| blackburn1 | in general we should just never use pointers to vectors | 20:38 |
| blackburn1 | because sgvector is a smart pointer to pointer | 20:38 |
| blackburn1 | to data pointer I mean | 20:38 |
| blackburn1 | sgvector1 -> data <- sgvector2 | 20:39 |
| blackburn1 | heiko1: if you change any of them ^ you change both | 20:39 |
| heiko1 | ah | 20:39 |
| heiko1 | ok | 20:39 |
| heiko1 | here is the problem | 20:39 |
| heiko1 | there is a method set_values | 20:39 |
| heiko1 | set_values(SGVector) | 20:40 |
| heiko1 | which replaces the current vector by the given one | 20:40 |
| heiko1 | but if I put this in the "current" vector, the vector in the map does not get the array | 20:40 |
| blackburn1 | what is the class that method is of? | 20:40 |
| heiko1 | CLabels | 20:40 |
| blackburn1 | aahh | 20:40 |
| heiko1 | set_confidences .. I change the name | 20:40 |
| blackburn1 | I've got the problem you met | 20:41 |
| heiko1 | I guess I just have to change in the map also .... | 20:41 |
| heiko1 | let me try | 20:41 |
| blackburn1 | yes but that's not so cool now | 20:41 |
| heiko1 | the vector data is initialised with NULL in the beginning | 20:41 |
| blackburn1 | we would have to handle everything twice | 20:42 |
| heiko1 | so how to replace this null pointer by actual data | 20:42 |
| heiko1 | I know | 20:42 |
| heiko1 | this is the problem | 20:42 |
| heiko1 | whenever the current vector is changed (by means of data array is replaced by another one) this problem appeats | 20:42 |
| heiko1 | appears | 20:42 |
| blackburn1 | yeah.. | 20:43 |
| heiko1 | using pointers would avoid this, but thats ugly | 20:43 |
| blackburn1 | yeah pointers are transparent | 20:43 |
| blackburn1 | you are happy anyway - no need to handle that | 20:43 |
| blackburn1 | but now we are not happy :D | 20:43 |
| heiko1 | yeah I mean, this pointers to SGVector screws a lot of things | 20:44 |
| heiko1 | and btw also, CMap with SGVector as value is not serialisable | 20:45 |
| heiko1 | so adding this would break CLabels being serializable, which sucks | 20:45 |
| heiko1 | man, maybe its better to just add another vector | 20:46 |
| heiko1 | and having two - fixed | 20:46 |
| blackburn1 | heh | 20:46 |
| heiko1 | or three | 20:46 |
| heiko1 | scores, confidences, binary | 20:46 |
| blackburn1 | well I've added a vector of vectors to multiclass labels | 20:47 |
| heiko1 | vector of vectors? | 20:47 |
| heiko1 | thats not serialisable | 20:47 |
| heiko1 | perse | 20:47 |
| blackburn1 | yeah to store scores | 20:47 |
| heiko1 | :( | 20:47 |
| blackburn1 | yeah I know | 20:47 |
| heiko1 | having one superclass would avoid all this | 20:47 |
| heiko1 | having data-structures for all objects we use in shogun | 20:48 |
| heiko1 | that would simplify everything so much | 20:48 |
| heiko1 | just another CSGObject derived class for vectors and matrices | 20:48 |
| heiko1 | then we could just store CDynamicObjectArrays of vectors | 20:48 |
| heiko1 | and done | 20:48 |
| heiko1 | and SGVector would just be for numerical data | 20:49 |
| blackburn1 | we would need to change pretty much for that | 20:50 |
| heiko1 | yeah | 20:50 |
| heiko1 | :( | 20:50 |
| heiko1 | but the Labels system as we want it wont work with the current approach | 20:50 |
| heiko1 | also, this non-serialisation is not good | 20:51 |
| heiko1 | and having no data-structures for SGReferenced also sucks | 20:51 |
| heiko1 | maybe we should talk with the others about that. | 20:52 |
| heiko1 | Ill wait with the labels until this is sorted | 20:52 |
| blackburn1 | well I could try to make sgobject a smart pointer | 20:53 |
| blackburn1 | however - can you explain how that would work? | 20:53 |
| heiko1 | no :D | 20:53 |
| blackburn1 | I mean why that would make serialization work | 20:53 |
| heiko1 | these two classes also are a bit strange | 20:54 |
| heiko1 | serialisation just requires everything to be registered | 20:54 |
| heiko1 | and that datastructures either get SGObjects or numerical data | 20:54 |
| heiko1 | anything else wont work | 20:54 |
| heiko1 | also I think for reasons of simplicity we should have one base class for everything | 20:54 |
| heiko1 | and not two kinds of objects | 20:55 |
| blackburn1 | now they are conceptually different | 20:55 |
| blackburn1 | so nothing to do with it yet | 20:55 |
| heiko1 | nothing to do with it yet? what does that mean? | 20:55 |
| blackburn1 | argh I forgot it is kind of phrase | 20:56 |
| blackburn1 | I mean we can't do nothing :) | 20:56 |
| blackburn1 | can do nothing! | 20:56 |
| blackburn1 | argh! | 20:56 |
| heiko1 | yes | 20:57 |
| heiko1 | would 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 |
| blackburn1 | yes | 20:58 |
| blackburn1 | way too bad, current way is so cool | 20:58 |
| heiko1 | indeed | 20:59 |
| heiko1 | ok, lets say things stay like this | 20:59 |
| heiko1 | what about data structures? | 20:59 |
| heiko1 | and what about these pointers? | 20:59 |
| heiko1 | maybe I should try to do that for Labels and then see | 21:00 |
| heiko1 | I mean use a SGVector pointer for the current one and just add that to the parameter framework | 21:00 |
| -!- vikram360 [~vikram360@117.216.149.198] has quit [Ping timeout: 255 seconds] | 21:00 | |
| blackburn1 | one way I see | 21:02 |
| blackburn1 | is to add a method | 21:02 |
| blackburn1 | that pick ups updated value from class to the map | 21:02 |
| blackburn1 | so each time you change labels or confidences | 21:02 |
| -!- vikram360 [~vikram360@117.192.170.32] has joined #shogun | 21:02 | |
| blackburn1 | you call some method that does update | 21:03 |
| heiko1 | this would have to be added to every change | 21:05 |
| heiko1 | what about the pointer? | 21:05 |
| heiko1 | the map would break serialisation anyway :) | 21:05 |
| heiko1 | CMap <char*, SGVector> I mean | 21:05 |
| blackburn1 | why? | 21:06 |
| blackburn1 | if you forgot to fire that 'changed' event you will serialize old vector | 21:07 |
| blackburn1 | nothing really bad | 21:07 |
| heiko1 | CMap does not support serialisation | 21:07 |
| heiko1 | ok I mean I could just two lists instead | 21:08 |
| heiko1 | these are serialisable | 21:08 |
| heiko1 | but not if type is SGVector | 21:08 |
| heiko1 | also, if one forget to fire change, then changing the "current" vector breaks things | 21:08 |
| blackburn1 | oh well | 21:13 |
| heiko1 | maybe pointer solution is best | 21:16 |
| heiko1 | and having two lists instead of a map | 21:16 |
| heiko1 | access to current values changes everywhere but tihhs is easy to sport since compile errors on change | 21:17 |
| heiko1 | I gotta go now, lets discuss later | 21:18 |
| -!- heiko1 [~heiko@host86-180-223-130.range86-180.btcentralplus.com] has left #shogun [] | 21:18 | |
| blackburn1 | okay | 21:19 |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 22:32 | |
| --- Log closed Sun Sep 16 00:00:17 2012 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!