IRC logs of #shogun for Friday, 2012-11-30

--- Log opened Fri Nov 30 00:00:15 2012
wikingdoh00:48
wikingwhy 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-buildbotbuild #159 of nightly_all is complete: Success [build successful]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/15903:26
shogun-buildbotbuild #190 of nightly_default is complete: Failure [failed compile]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/19003: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 #shogun04:28
-!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Remote host closed the connection]06:00
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun06:00
shogun-buildbotbuild #191 of nightly_default is complete: Failure [failed compile]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/19106: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 #shogun06: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 secs06:13
-!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun06:13
-!- sonney2k [~shogun@7nn.de] has joined #shogun06:14
-!- mode/#shogun [+o sonney2k] by ChanServ06:14
@sonney2kforce build "deb3 - modular_interfaces"06:15
@sonney2kshogun-buildbot, force build "deb3 - modular_interfaces"06:15
shogun-buildbotbuild #703 forced06:15
shogun-buildbotI'll give a shout when the build finishes06:15
@sonney2kshogun-buildbot, force build "nightly_default"06:19
shogun-buildbotbuild #192 forced06:19
shogun-buildbotI'll give a shout when the build finishes06:19
shogun-buildbotbuild #192 of nightly_default is complete: Failure [failed compile]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/19206:25
shogun-buildbotHey! build deb3 - modular_interfaces #703 is complete: Success [build successful]06:56
shogun-buildbotBuild details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/70306:56
-!- ptizoom_ [~christian@79-71-89-182.dynamic.dsl.as9105.com] has joined #shogun08:17
-!- ptizoom [~christian@79-71-89-182.dynamic.dsl.as9105.com] has quit [Read error: Connection reset by peer]08:17
shogun-buildbotbuild #193 of nightly_default is complete: Failure [failed compile]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/19308:22
@sonney2kshogun-buildbot, force build "nightly_default"08:24
shogun-buildbotbuild #194 forced08:24
shogun-buildbotI'll give a shout when the build finishes08:24
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/b2aa0873566ba5bca1285bd6dee2c0b62fb9795108:29
-shogungit:#shogun- shogun/master b2aa087 Soeren Sonnenburg: don't use memset in DynArray or zero unused memory08:29
shogun-buildbotbuild #194 of nightly_default is complete: Failure [failed compile]  Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/19408:31
@sonney2kwiking, please try again - I potentially fixed the dynarray issue08:33
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/6ccd8005716581e70cfececef4cd96a5f8e977df08:34
-shogungit:#shogun- shogun/master 6ccd800 Soeren Sonnenburg: add forgotten example and fix minor typo08:34
-!- blackburn [5bdfb203@gateway/web/freenode/ip.91.223.178.3] has joined #shogun09:04
shogun-buildbotbuild #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-buildbotbuild #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/70509:38
wikingsonney2k: ok10:32
wikingsonney2k: how do i dot product two SGVector in python/10:32
wiking?10:32
wikingas numpy.dot cannot work over RealVectors10:33
sonne|workwiking: errm how did you end up with RealVectors?10:33
wikinghehhe that's a good question10:34
wikingso i'm trying to put together this toy example in python for latent svm10:34
wikingi have a LatentFeatures that stores a vector of structures where each structure has an SGVector in it10:38
wikingand when i try to access the SGVector<float64_t> in that structure10:38
wikingi end up getting RealVectors10:38
wikingsonne|work: i've thought there's a mapping between np.array <-> and SGVector10:41
wikingbut for some reason it doesn't kick in10:41
sonne|workwiking: no there is none10:41
sonne|workan SGVector will be translated to a numpy array10:41
sonne|workso that is why I wonder how you manage to create and SGVector (if not manuallly)10:42
wikingyeah that's what i wonder10:42
wikingwhy the translation does not kick in10:42
sonne|workwiking: how do you create it?10:43
wikingso i have a simple struct10:43
wikingstruct CWhatever { CWhatever(SGVector<float64_t> x) : feature(x) {}  SGVector<float64_t> feature; };10:43
sonne|workyeah if you access feature you will get it10:44
wikingand in numpy i do this: Whatever(np.array([1.0,1.0])10:44
sonne|workif you do CWhatever(numpy.array(..)) you get the vector10:44
sonne|workinited10:44
wikingx = Whatever(np.array([1.0,1.0])10:44
wikingx.feature10:44
sonne|worklost10:44
wikingis not np.array10:44
sonne|workwiking: add a method get_vector()10:45
sonne|workthen you will get the translated numpy.array10:45
wikinglet's see10:45
wikingrecompiling...10:47
wikingok cool now it works10:51
wikingsonne|work: do u know why doesn't it kick in before?10:51
wikingsonne|work: ok another problem10:52
blackburnbecause typemaps work for return and input types10:52
wikingblackburn: mmm seems it doesn't work in case of this type of func arg10:52
wikingWhatever(np.array([1.0,1.0])10:53
wikingblackburn: virtual CData* infer_latent_variable(const SGVector<float64_t>& w, index_t idx)=0;10:53
wikingso when a reference to the sgvector is passed10:53
wikingthen the translation doesn't kick in i guess10:53
wikingright10:53
wiking?10:53
wiking    dot = np.dot(x, w)10:54
wikingTypeError: unsupported operand type(s) for *: 'float' and 'RealVector'10:54
blackburnwiking: you mean if you overload it in python? yes10:54
wikingw is const SGVector<float64_t>& w10:54
wikingand i overload this func in python with the director10:55
wikingand w is RealVector10:55
wikingand not an np.array10:55
wikingso the definition of that function should be virtual CData* infer_latent_variable(const SGVector<float64_t> w, index_t idx);10:56
wikingi guess10:56
wikingbut then it's really stupid10:57
wikingi mean passing the whole vector instead of a reference :S10:57
wikingblackburn: ?11:02
blackburnwiking: why not to pass whole vector?11:03
wikingthat's a rather awkward question11:03
wikingwhy would i pass the whole thing on the stack11:03
wikinginstead of it's reference?11:03
blackburnwhich whole thing? two pointers and length?11:03
sonne|workwiking: why do you use &w ?11:04
wikingsonne|work: as sizeof(int32_t) < sizeof(SGVector)11:04
wikingand that the copy ctor doesn't kick in11:04
wikingon the stack11:04
blackburnso you want microoptimization which makes things impossible? ;)11:05
sonne|workwiking: it is all lightweight - it increases refcount & copies ptr to data / size11:05
-!- hoijui [~hoijui@dslb-088-075-034-093.pools.arcor-ip.net] has joined #shogun11:05
wikingsonne|work: still i believe that especially when one just reads the object, there's really no need for passing the whole object11:06
sonne|workwiking: &w might be dangerous - no refcount increase - vector might be gone ...11:06
wikingi mean this is my common c++ coding style11:06
blackburnbut you write python + C++ interaction now right?11:06
wikingblackburn: well i thought it'd be niceer to make11:06
wikingthe example in python11:07
blackburnwill that work with python?11:07
wikingseems i'm wrong :D11:07
blackburnI don't know anything about references in python11:07
wikingblackburn: well i guess it could if one does the typemapping11:07
blackburnhard references I mean, like in C++11:07
wikingblackburn: i've just read vaguely the reference manual for swig11:07
blackburnno as it wraps another object on top of it11:07
blackburnI think so11:07
wikingseems to be possible somehow11:07
blackburnit is not the issue to be solved I think - sizeof(SGVector) is just 3 ints11:08
blackburnI don't know internals of python but I am sure the overhead is much better and you will not gain anything here11:09
blackburnargh11:09
blackburnmuch worse :D11:09
blackburnpython should wrap more things and if you gain 8 bytes11:09
wikingno i meant that why to waste resources when u dont really have to11:09
wikingnot only 8 bytes11:10
wikingbut ctor + dtor invocation11:10
blackburnagain - if you have a way to use C++ references in swig feel free11:10
wikingblackburn: yeah trying to figure out :D11:10
blackburnbut it is not worth to change anything if you have no way around it11:10
wikingblackburn: u should have been here the other day with k0stia11:11
wikingtelling him this line: "blackburn> again - if you have a way to use C++ references in swig feel free"11:11
wiking:D11:11
blackburnyeah he thinks C++ and python interaction is just11:11
blackburnoneliner11:11
wikingi think the attitude got a bit weird there11:12
wikingwhen he was demanding a fix for his problem11:12
wikingand that starting to say that it's not proper how it is done now11:12
sonne|workwiking: don't use SGVector & if you don't have a compelling reason to do so11:13
wikingblackburn: ok i'm stripping off &11:13
wikingconst would not be a problem, right? sonne|work ?11:13
wikingconst SGVector<float64_t> would be still a numpy.array?11:13
sonne|workwiking: you could still modify vector.vec11:14
blackburnshould be but what you are going to const here?11:14
wikingblackburn: sgvector itself11:14
wikingsonne|work: u mean SGVector.vector?11:14
wikingsonne|work: it's still a weird SWIG type thingy11:14
blackburnI see nothing more safe in case of SWIG11:15
wikingcompiling .... let's see11:15
sonne|workwiking: look - if you use multiple threads11:15
sonne|workyour reference might have become invalid11:16
sonne|workso don't use it if you can avoid it11:16
wikinglook at us, discussing true geeky stuff :D11:16
wikinghow adoreable we are ;)11:16
wikingsonne|work: alright11:16
wikingsonne|work: anyways this example took more time than i thought in the first place and i want it to see it working11:17
wikingblackburn: so i have this struct name now: MILFeature11:17
blackburnhahaha OKAY11:18
wikingi'm tempted to keep it like this :)11:18
sonne|workMissinInLaFace?11:19
wikingsonne|work: fyi: http://en.wikipedia.org/wiki/MILF11:19
wikingah ok sorry: http://en.wikipedia.org/wiki/MILF_%28slang%2911:19
wikingbut yeah it's MIL = multiple instance learning11:19
sonne|workMoro Islamic Liberation Front,11:20
wikingsonne|work: hahahah pure guys really took a bad name11:20
blackburnoh good boy sonne|work doesn't know such bad words11:20
wikingblackburn: :D11:20
sonne|workahh stiflers mom11:21
wikinglol face!!!11:21
wikingi still get RealVector11:21
wikingy u NO WORK!11:21
blackburnu can haz realvector11:21
wikingr no want realvector11:22
wikingok i stripped of const-nes as well11:22
wikingbetter be working now!11:23
wikingmmm11:25
wikingwhy is there this shogun/features/DenseSubsetFeatures.cpp when it is completely empty!?11:25
wikingpluskid made there some funky stuff11:26
wikingok11:27
wikingthere's seomthing wrong :(11:27
wikingCData* CDirectorLatentModel::infer_latent_variable(SGVector<float64_t> w, index_t idx)11:28
wikingand when i override this in python11:28
wikingw is <Swig Object of type 'shogun::SGVector< double > *' at 0x10a514030>11:28
wiking:S11:28
wikingideas?11:29
-!- sonne|work [~sonnenbu@194.78.35.195] has quit [Quit: Leaving.]11:29
-!- sonne|work [~sonnenbu@194.78.35.195] has joined #shogun11:29
blackburnwiking: what do you want to get?11:30
sonne|workahh ok with directors yes11:30
wikingi want numpy.array11:30
wiking:D11:31
wikingi cannot?11:31
blackburnno, I don't think so11:35
sonne|workwiking: ohh that can become difficult... there are director in/out typemaps11:35
sonne|workbut I would rather deal with SGVector directly here11:35
wikingookey11:35
sonne|workfor performance sanity11:35
blackburnthere is no such thing like magic11:35
sonne|workotherwise your SGVector -> numpy -> SGVector11: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
wikingsonne|work: here?13:41
sonne|work?13:50
wikingsonne|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.013:57
wikingand yeah it's only 1 dim13:57
sonne|worksure yes13:59
wikingyou mean it should be able?13:59
wikingbecause i've just tried with svmocas13:59
wikingand no good :(13:59
wikingsame with liblinear13:59
wikingi mean esseintially in this very stupid toy example14:00
wikingw*100 should be positive14:00
wikingand w*5.0 'should' be negative14:01
wikingbut that's not possible of course :P14:01
sonne|workwiking: did you disable the bias term?14:01
sonne|workbias is regularized but still14:01
sonne|workw=0 and b sth like -30 :)14:02
wikingsonne|work: but how would it be possible to find a number (w) that gives negative values for numbers around 5.014:03
wikingbut positive ones for ~100.014:03
sonne|worknot possible - you need a bias term14:04
sonne|workcenter the data (zero mean) and try again otherwise14:05
wikingi've enabled now bias14:05
-!- sonne|work [~sonnenbu@194.78.35.195] has quit [Quit: Leaving.]16:43
@sonney2kwiking, and?17:07
@sonney2kw/ bias all good?17:07
@sonney2kwiking, btw how about introducing SGVector<T> SGVector<T>::get()17:10
wikingsonney2k: yeah that'd be a nice helper for pythno17:16
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/0372dd02f75d03be23b7d03a1d1ce1829617282a17:17
-shogungit:#shogun- shogun/master 0372dd0 Soeren Sonnenburg: add getters for SG data types to enable further typemap converted...17:17
@sonney2kok then17:17
-shogungit:#shogun- [shogun] sonney2k pushed 1 new commit to master: https://github.com/shogun-toolbox/shogun/commit/57d201ef0d2e85bd21c9a85302d308bb1d4461b317:21
-shogungit:#shogun- shogun/master 57d201e Soeren Sonnenburg: use malloc instead of calloc in dynarray17:21
-!- travis-ci [~travis-ci@ec2-23-22-85-244.compute-1.amazonaws.com] has joined #shogun17: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/343726117: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 #shogun17: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/343733617:34
-!- travis-ci [~travis-ci@ec2-23-22-85-244.compute-1.amazonaws.com] has left #shogun []17:34
shogun-buildbotbuild #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-buildbotbuild #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-buildbotbuild #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-buildbotbuild #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-buildbotbuild #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
wikingmmm it failed :(18:48
@sonney2kwiking, that is my malloc instead of calloc stuff19:39
wikingmmmm22:15
wikinggithuuuuub22:15
wikingy u no work22: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!