--- Log opened Fri Nov 30 00:00:15 2012 | ||
wiking | doh | 00:48 |
---|---|---|
wiking | why can't i sgvector<float64_t> -> numpy.array? | 00:49 |
-!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 02:13 | |
shogun-buildbot | build #159 of nightly_all is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/159 | 03:26 |
shogun-buildbot | build #190 of nightly_default is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/190 | 03:27 |
-!- ptizoom [~christian@79-71-89-182.dynamic.dsl.as9105.com] has quit [Quit: Ex-Chat] | 04:28 | |
-!- ptizoom [~christian@79-71-89-182.dynamic.dsl.as9105.com] has joined #shogun | 04:28 | |
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Remote host closed the connection] | 06:00 | |
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 06:00 | |
shogun-buildbot | build #191 of nightly_default is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/191 | 06:09 |
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Remote host closed the connection] | 06:12 | |
--- Log opened Fri Nov 30 06:13:47 2012 | ||
-!- shogun-toolbox [~shogun@7nn.de] has joined #shogun | 06:13 | |
-!- Irssi: #shogun: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal] | 06:13 | |
-!- Irssi: Join to #shogun was synced in 6 secs | 06:13 | |
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 06:13 | |
-!- sonney2k [~shogun@7nn.de] has joined #shogun | 06:14 | |
-!- mode/#shogun [+o sonney2k] by ChanServ | 06:14 | |
@sonney2k | force build "deb3 - modular_interfaces" | 06:15 |
@sonney2k | shogun-buildbot, force build "deb3 - modular_interfaces" | 06:15 |
shogun-buildbot | build #703 forced | 06:15 |
shogun-buildbot | I'll give a shout when the build finishes | 06:15 |
@sonney2k | shogun-buildbot, force build "nightly_default" | 06:19 |
shogun-buildbot | build #192 forced | 06:19 |
shogun-buildbot | I'll give a shout when the build finishes | 06:19 |
shogun-buildbot | build #192 of nightly_default is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/192 | 06:25 |
shogun-buildbot | Hey! build deb3 - modular_interfaces #703 is complete: Success [build successful] | 06:56 |
shogun-buildbot | Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/703 | 06:56 |
-!- ptizoom_ [~christian@79-71-89-182.dynamic.dsl.as9105.com] has joined #shogun | 08:17 | |
-!- ptizoom [~christian@79-71-89-182.dynamic.dsl.as9105.com] has quit [Read error: Connection reset by peer] | 08:17 | |
shogun-buildbot | build #193 of nightly_default is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/193 | 08:22 |
@sonney2k | shogun-buildbot, force build "nightly_default" | 08:24 |
shogun-buildbot | build #194 forced | 08:24 |
shogun-buildbot | I'll give a shout when the build finishes | 08:24 |
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/b2aa0873566ba5bca1285bd6dee2c0b62fb97951 | 08:29 | |
-shogungit:#shogun- shogun/master b2aa087 Soeren Sonnenburg: don't use memset in DynArray or zero unused memory | 08:29 | |
shogun-buildbot | build #194 of nightly_default is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/194 | 08:31 |
@sonney2k | wiking, please try again - I potentially fixed the dynarray issue | 08:33 |
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/6ccd8005716581e70cfececef4cd96a5f8e977df | 08:34 | |
-shogungit:#shogun- shogun/master 6ccd800 Soeren Sonnenburg: add forgotten example and fix minor typo | 08:34 | |
-!- blackburn [5bdfb203@gateway/web/freenode/ip.91.223.178.3] has joined #shogun | 09:04 | |
shogun-buildbot | build #704 of deb3 - modular_interfaces is complete: Failure [failed compile octave_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/704 blamelist: Soeren Sonnenburg <sonne@debian.org> | 09:11 |
shogun-buildbot | build #705 of deb3 - modular_interfaces is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/705 | 09:38 |
wiking | sonney2k: ok | 10:32 |
wiking | sonney2k: how do i dot product two SGVector in python/ | 10:32 |
wiking | ? | 10:32 |
wiking | as numpy.dot cannot work over RealVectors | 10:33 |
sonne|work | wiking: errm how did you end up with RealVectors? | 10:33 |
wiking | hehhe that's a good question | 10:34 |
wiking | so i'm trying to put together this toy example in python for latent svm | 10:34 |
wiking | i have a LatentFeatures that stores a vector of structures where each structure has an SGVector in it | 10:38 |
wiking | and when i try to access the SGVector<float64_t> in that structure | 10:38 |
wiking | i end up getting RealVectors | 10:38 |
wiking | sonne|work: i've thought there's a mapping between np.array <-> and SGVector | 10:41 |
wiking | but for some reason it doesn't kick in | 10:41 |
sonne|work | wiking: no there is none | 10:41 |
sonne|work | an SGVector will be translated to a numpy array | 10:41 |
sonne|work | so that is why I wonder how you manage to create and SGVector (if not manuallly) | 10:42 |
wiking | yeah that's what i wonder | 10:42 |
wiking | why the translation does not kick in | 10:42 |
sonne|work | wiking: how do you create it? | 10:43 |
wiking | so i have a simple struct | 10:43 |
wiking | struct CWhatever { CWhatever(SGVector<float64_t> x) : feature(x) {} SGVector<float64_t> feature; }; | 10:43 |
sonne|work | yeah if you access feature you will get it | 10:44 |
wiking | and in numpy i do this: Whatever(np.array([1.0,1.0]) | 10:44 |
sonne|work | if you do CWhatever(numpy.array(..)) you get the vector | 10:44 |
sonne|work | inited | 10:44 |
wiking | x = Whatever(np.array([1.0,1.0]) | 10:44 |
wiking | x.feature | 10:44 |
sonne|work | lost | 10:44 |
wiking | is not np.array | 10:44 |
sonne|work | wiking: add a method get_vector() | 10:45 |
sonne|work | then you will get the translated numpy.array | 10:45 |
wiking | let's see | 10:45 |
wiking | recompiling... | 10:47 |
wiking | ok cool now it works | 10:51 |
wiking | sonne|work: do u know why doesn't it kick in before? | 10:51 |
wiking | sonne|work: ok another problem | 10:52 |
blackburn | because typemaps work for return and input types | 10:52 |
wiking | blackburn: mmm seems it doesn't work in case of this type of func arg | 10:52 |
wiking | Whatever(np.array([1.0,1.0]) | 10:53 |
wiking | blackburn: virtual CData* infer_latent_variable(const SGVector<float64_t>& w, index_t idx)=0; | 10:53 |
wiking | so when a reference to the sgvector is passed | 10:53 |
wiking | then the translation doesn't kick in i guess | 10:53 |
wiking | right | 10:53 |
wiking | ? | 10:53 |
wiking | dot = np.dot(x, w) | 10:54 |
wiking | TypeError: unsupported operand type(s) for *: 'float' and 'RealVector' | 10:54 |
blackburn | wiking: you mean if you overload it in python? yes | 10:54 |
wiking | w is const SGVector<float64_t>& w | 10:54 |
wiking | and i overload this func in python with the director | 10:55 |
wiking | and w is RealVector | 10:55 |
wiking | and not an np.array | 10:55 |
wiking | so the definition of that function should be virtual CData* infer_latent_variable(const SGVector<float64_t> w, index_t idx); | 10:56 |
wiking | i guess | 10:56 |
wiking | but then it's really stupid | 10:57 |
wiking | i mean passing the whole vector instead of a reference :S | 10:57 |
wiking | blackburn: ? | 11:02 |
blackburn | wiking: why not to pass whole vector? | 11:03 |
wiking | that's a rather awkward question | 11:03 |
wiking | why would i pass the whole thing on the stack | 11:03 |
wiking | instead of it's reference? | 11:03 |
blackburn | which whole thing? two pointers and length? | 11:03 |
sonne|work | wiking: why do you use &w ? | 11:04 |
wiking | sonne|work: as sizeof(int32_t) < sizeof(SGVector) | 11:04 |
wiking | and that the copy ctor doesn't kick in | 11:04 |
wiking | on the stack | 11:04 |
blackburn | so you want microoptimization which makes things impossible? ;) | 11:05 |
sonne|work | wiking: it is all lightweight - it increases refcount & copies ptr to data / size | 11:05 |
-!- hoijui [~hoijui@dslb-088-075-034-093.pools.arcor-ip.net] has joined #shogun | 11:05 | |
wiking | sonne|work: still i believe that especially when one just reads the object, there's really no need for passing the whole object | 11:06 |
sonne|work | wiking: &w might be dangerous - no refcount increase - vector might be gone ... | 11:06 |
wiking | i mean this is my common c++ coding style | 11:06 |
blackburn | but you write python + C++ interaction now right? | 11:06 |
wiking | blackburn: well i thought it'd be niceer to make | 11:06 |
wiking | the example in python | 11:07 |
blackburn | will that work with python? | 11:07 |
wiking | seems i'm wrong :D | 11:07 |
blackburn | I don't know anything about references in python | 11:07 |
wiking | blackburn: well i guess it could if one does the typemapping | 11:07 |
blackburn | hard references I mean, like in C++ | 11:07 |
wiking | blackburn: i've just read vaguely the reference manual for swig | 11:07 |
blackburn | no as it wraps another object on top of it | 11:07 |
blackburn | I think so | 11:07 |
wiking | seems to be possible somehow | 11:07 |
blackburn | it is not the issue to be solved I think - sizeof(SGVector) is just 3 ints | 11:08 |
blackburn | I don't know internals of python but I am sure the overhead is much better and you will not gain anything here | 11:09 |
blackburn | argh | 11:09 |
blackburn | much worse :D | 11:09 |
blackburn | python should wrap more things and if you gain 8 bytes | 11:09 |
wiking | no i meant that why to waste resources when u dont really have to | 11:09 |
wiking | not only 8 bytes | 11:10 |
wiking | but ctor + dtor invocation | 11:10 |
blackburn | again - if you have a way to use C++ references in swig feel free | 11:10 |
wiking | blackburn: yeah trying to figure out :D | 11:10 |
blackburn | but it is not worth to change anything if you have no way around it | 11:10 |
wiking | blackburn: u should have been here the other day with k0stia | 11:11 |
wiking | telling him this line: "blackburn> again - if you have a way to use C++ references in swig feel free" | 11:11 |
wiking | :D | 11:11 |
blackburn | yeah he thinks C++ and python interaction is just | 11:11 |
blackburn | oneliner | 11:11 |
wiking | i think the attitude got a bit weird there | 11:12 |
wiking | when he was demanding a fix for his problem | 11:12 |
wiking | and that starting to say that it's not proper how it is done now | 11:12 |
sonne|work | wiking: don't use SGVector & if you don't have a compelling reason to do so | 11:13 |
wiking | blackburn: ok i'm stripping off & | 11:13 |
wiking | const would not be a problem, right? sonne|work ? | 11:13 |
wiking | const SGVector<float64_t> would be still a numpy.array? | 11:13 |
sonne|work | wiking: you could still modify vector.vec | 11:14 |
blackburn | should be but what you are going to const here? | 11:14 |
wiking | blackburn: sgvector itself | 11:14 |
wiking | sonne|work: u mean SGVector.vector? | 11:14 |
wiking | sonne|work: it's still a weird SWIG type thingy | 11:14 |
blackburn | I see nothing more safe in case of SWIG | 11:15 |
wiking | compiling .... let's see | 11:15 |
sonne|work | wiking: look - if you use multiple threads | 11:15 |
sonne|work | your reference might have become invalid | 11:16 |
sonne|work | so don't use it if you can avoid it | 11:16 |
wiking | look at us, discussing true geeky stuff :D | 11:16 |
wiking | how adoreable we are ;) | 11:16 |
wiking | sonne|work: alright | 11:16 |
wiking | sonne|work: anyways this example took more time than i thought in the first place and i want it to see it working | 11:17 |
wiking | blackburn: so i have this struct name now: MILFeature | 11:17 |
blackburn | hahaha OKAY | 11:18 |
wiking | i'm tempted to keep it like this :) | 11:18 |
sonne|work | MissinInLaFace? | 11:19 |
wiking | sonne|work: fyi: http://en.wikipedia.org/wiki/MILF | 11:19 |
wiking | ah ok sorry: http://en.wikipedia.org/wiki/MILF_%28slang%29 | 11:19 |
wiking | but yeah it's MIL = multiple instance learning | 11:19 |
sonne|work | Moro Islamic Liberation Front, | 11:20 |
wiking | sonne|work: hahahah pure guys really took a bad name | 11:20 |
blackburn | oh good boy sonne|work doesn't know such bad words | 11:20 |
wiking | blackburn: :D | 11:20 |
sonne|work | ahh stiflers mom | 11:21 |
wiking | lol face!!! | 11:21 |
wiking | i still get RealVector | 11:21 |
wiking | y u NO WORK! | 11:21 |
blackburn | u can haz realvector | 11:21 |
wiking | r no want realvector | 11:22 |
wiking | ok i stripped of const-nes as well | 11:22 |
wiking | better be working now! | 11:23 |
wiking | mmm | 11:25 |
wiking | why is there this shogun/features/DenseSubsetFeatures.cpp when it is completely empty!? | 11:25 |
wiking | pluskid made there some funky stuff | 11:26 |
wiking | ok | 11:27 |
wiking | there's seomthing wrong :( | 11:27 |
wiking | CData* CDirectorLatentModel::infer_latent_variable(SGVector<float64_t> w, index_t idx) | 11:28 |
wiking | and when i override this in python | 11:28 |
wiking | w is <Swig Object of type 'shogun::SGVector< double > *' at 0x10a514030> | 11:28 |
wiking | :S | 11:28 |
wiking | ideas? | 11:29 |
-!- sonne|work [~sonnenbu@194.78.35.195] has quit [Quit: Leaving.] | 11:29 | |
-!- sonne|work [~sonnenbu@194.78.35.195] has joined #shogun | 11:29 | |
blackburn | wiking: what do you want to get? | 11:30 |
sonne|work | ahh ok with directors yes | 11:30 |
wiking | i want numpy.array | 11:30 |
wiking | :D | 11:31 |
wiking | i cannot? | 11:31 |
blackburn | no, I don't think so | 11:35 |
sonne|work | wiking: ohh that can become difficult... there are director in/out typemaps | 11:35 |
sonne|work | but I would rather deal with SGVector directly here | 11:35 |
wiking | ookey | 11:35 |
sonne|work | for performance sanity | 11:35 |
blackburn | there is no such thing like magic | 11:35 |
sonne|work | otherwise your SGVector -> numpy -> SGVector | 11:35 |
-!- hoijui [~hoijui@dslb-088-075-034-093.pools.arcor-ip.net] has quit [Quit: Leaving] | 11:35 | |
-!- blackburn [5bdfb203@gateway/web/freenode/ip.91.223.178.3] has quit [Quit: Page closed] | 12:27 | |
wiking | sonne|work: here? | 13:41 |
sonne|work | ? | 13:50 |
wiking | sonne|work: am i wrong when i think that svmocas should be able to find a w that can classify a toy dataset where -1.0 labelled ones are points from a gaussian with mean 5.0 and variance 1.0 while +1.0 labelled ones are from a mean of 100.0 and variance 1.0 | 13:57 |
wiking | and yeah it's only 1 dim | 13:57 |
sonne|work | sure yes | 13:59 |
wiking | you mean it should be able? | 13:59 |
wiking | because i've just tried with svmocas | 13:59 |
wiking | and no good :( | 13:59 |
wiking | same with liblinear | 13:59 |
wiking | i mean esseintially in this very stupid toy example | 14:00 |
wiking | w*100 should be positive | 14:00 |
wiking | and w*5.0 'should' be negative | 14:01 |
wiking | but that's not possible of course :P | 14:01 |
sonne|work | wiking: did you disable the bias term? | 14:01 |
sonne|work | bias is regularized but still | 14:01 |
sonne|work | w=0 and b sth like -30 :) | 14:02 |
wiking | sonne|work: but how would it be possible to find a number (w) that gives negative values for numbers around 5.0 | 14:03 |
wiking | but positive ones for ~100.0 | 14:03 |
sonne|work | not possible - you need a bias term | 14:04 |
sonne|work | center the data (zero mean) and try again otherwise | 14:05 |
wiking | i've enabled now bias | 14:05 |
-!- sonne|work [~sonnenbu@194.78.35.195] has quit [Quit: Leaving.] | 16:43 | |
@sonney2k | wiking, and? | 17:07 |
@sonney2k | w/ bias all good? | 17:07 |
@sonney2k | wiking, btw how about introducing SGVector<T> SGVector<T>::get() | 17:10 |
wiking | sonney2k: yeah that'd be a nice helper for pythno | 17:16 |
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/0372dd02f75d03be23b7d03a1d1ce1829617282a | 17:17 | |
-shogungit:#shogun- shogun/master 0372dd0 Soeren Sonnenburg: add getters for SG data types to enable further typemap converted... | 17:17 | |
@sonney2k | ok then | 17:17 |
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/57d201ef0d2e85bd21c9a85302d308bb1d4461b3 | 17:21 | |
-shogungit:#shogun- shogun/master 57d201e Soeren Sonnenburg: use malloc instead of calloc in dynarray | 17:21 | |
-!- travis-ci [~travis-ci@ec2-23-22-85-244.compute-1.amazonaws.com] has joined #shogun | 17:26 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/3437261 | 17:26 |
-!- travis-ci [~travis-ci@ec2-23-22-85-244.compute-1.amazonaws.com] has left #shogun [] | 17:26 | |
-!- travis-ci [~travis-ci@ec2-23-22-85-244.compute-1.amazonaws.com] has joined #shogun | 17:34 | |
travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/3437336 | 17:34 |
-!- travis-ci [~travis-ci@ec2-23-22-85-244.compute-1.amazonaws.com] has left #shogun [] | 17:34 | |
shogun-buildbot | build #706 of deb3 - modular_interfaces is complete: Failure [failed compile octave_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/706 blamelist: Soeren Sonnenburg <sonne@debian.org> | 17:49 |
shogun-buildbot | build #596 of deb2 - static_interfaces is complete: Failure [failed test libshogun] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb2%20-%20static_interfaces/builds/596 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:00 |
shogun-buildbot | build #133 of ubu1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/133 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:13 |
shogun-buildbot | build #707 of deb3 - modular_interfaces is complete: Failure [failed compile octave_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/707 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:18 |
shogun-buildbot | build #128 of rpm1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/128 blamelist: Soeren Sonnenburg <sonne@debian.org> | 18:19 |
wiking | mmm it failed :( | 18:48 |
@sonney2k | wiking, that is my malloc instead of calloc stuff | 19:39 |
wiking | mmmm | 22:15 |
wiking | githuuuuub | 22:15 |
wiking | y u no work | 22:15 |
--- Log closed Sat Dec 01 00:00:38 2012 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!