| --- Log opened Sat Feb 23 00:00:49 2013 | ||
| shogun-notifier- | shogun: Sergey Lisitsyn :master * 7421ea5 / src/shogun/lib/tapkee/ (3 files): https://github.com/shogun-toolbox/shogun/commit/7421ea58a264f33fd8b271477f3548b19147e498 | 00:05 |
|---|---|---|
| shogun-notifier- | shogun: Updates for tapkee | 00:05 |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * d91f97e / src/shogun/lib/tapkee/routines/locally_linear.hpp: https://github.com/shogun-toolbox/shogun/commit/d91f97eafc85281a638bdd8a67f9fbd79588f018 | 00:07 |
| shogun-notifier- | shogun: Changed eigen old define to tapkee internal define | 00:07 |
| shogun-buildbot_ | build #867 of deb1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/867 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 00:08 |
| -!- wiking [~wiking@info2k1.hu] has quit [Quit: leaving] | 00:11 | |
| shogun-buildbot_ | build #868 of deb1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/868 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 00:12 |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * 28c5f41 / src/shogun/lib/tapkee/routines/methods_traits.hpp: https://github.com/shogun-toolbox/shogun/commit/28c5f412fbae754d2a827264af96cf3170e3b263 | 01:02 |
| shogun-notifier- | shogun: Added missed method traits | 01:02 |
| shogun-buildbot_ | build #869 of deb1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/869 | 01:15 |
| -!- travis-ci [~travis-ci@ec2-54-242-202-157.compute-1.amazonaws.com] has joined #shogun | 01:18 | |
| travis-ci | [travis-ci] it's Sergey Lisitsyn'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/4993934 | 01:18 |
| -!- travis-ci [~travis-ci@ec2-54-242-202-157.compute-1.amazonaws.com] has left #shogun [] | 01:18 | |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * 2ba8bb6 / src/shogun/lib/tapkee/ (7 files): https://github.com/shogun-toolbox/shogun/commit/2ba8bb6338b172145ccacb501c57be2dbc70aa39 | 01:19 |
| shogun-notifier- | shogun: Added projecting functions capabilities in tapkee | 01:19 |
| blackburn | oh gosh 5 hours of that stuff | 01:20 |
| shogun-buildbot_ | build #227 of ubu1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/227 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 01:21 |
| -!- travis-ci [~travis-ci@ec2-54-242-202-157.compute-1.amazonaws.com] has joined #shogun | 01:28 | |
| travis-ci | [travis-ci] it's Sergey Lisitsyn'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/4994111 | 01:29 |
| -!- travis-ci [~travis-ci@ec2-54-242-202-157.compute-1.amazonaws.com] has left #shogun [] | 01:29 | |
| shogun-buildbot_ | build #228 of ubu1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/228 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 01:30 |
| shogun-buildbot_ | build #556 of cyg1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/556 | 01:31 |
| -!- n4nd0 [53b32c87@gateway/web/freenode/ip.83.179.44.135] has quit [Quit: Page closed] | 01:46 | |
| shogun-buildbot_ | build #826 of deb3 - modular_interfaces is complete: Failure [failed test ruby_modular] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb3%20-%20modular_interfaces/builds/826 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 01:53 |
| -!- FSCV [~FSCV@187.210.54.166] has quit [Quit: Leaving] | 04:00 | |
| shogun-buildbot_ | build #291 of nightly_default is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/291 | 04:04 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 04:19 | |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has joined #shogun | 08:18 | |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has quit [Ping timeout: 260 seconds] | 10:12 | |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 10:19 | |
| n4nd0 | blackburn: good morning | 10:29 |
| n4nd0 | I have just profiled isomap | 10:30 |
| blackburn | n4nd0: hey | 10:30 |
| n4nd0 | checking the output now with kcachegrind | 10:30 |
| n4nd0 | do you want to take a look to the file? | 10:30 |
| blackburn | oh cool, tell me what is the bottleneck | 10:30 |
| blackburn | :) | 10:30 |
| blackburn | callgrind you mean? | 10:30 |
| blackburn | not really I can make it too - just let me know what is slow | 10:30 |
| n4nd0 | I cehck it with kcachegrind | 10:31 |
| n4nd0 | let me some time to analyze then :) | 10:31 |
| n4nd0 | blackburn: compute_shortest_distances_matrix is where the program spends the most time | 10:34 |
| n4nd0 | but that is sort of obvious I think | 10:34 |
| blackburn | n4nd0: better surprise me | 10:34 |
| blackburn | :D | 10:34 |
| blackburn | n4nd0: actually sklearn implements that via cython | 10:34 |
| blackburn | so no matter what we do it would be sort of similar | 10:35 |
| n4nd0 | blackburn: do you think we can do something smart there to make it faster? | 10:35 |
| blackburn | n4nd0: some quantum computing | 10:35 |
| n4nd0 | ?? | 10:35 |
| blackburn | n4nd0: but to be serious no, it seems we can't | 10:36 |
| blackburn | may be some microoptimizations | 10:36 |
| n4nd0 | Eigen::redux_impl is the other part where the time is spent | 10:37 |
| blackburn | n4nd0: not sure what it is | 10:39 |
| n4nd0 | blackburn: something that is called most of the times from compute_shortest_distances | 10:39 |
| blackburn | n4nd0: may be that's a distance callback | 10:39 |
| n4nd0 | almost 10 million times for 1000 data point swissroll | 10:40 |
| n4nd0 | it is sth from Eigen::internal so I am not sure what it is either | 10:40 |
| n4nd0 | brb | 10:40 |
| -!- trtr3434 [~trtr3434@sta-104-34.tm.net.my] has joined #shogun | 10:41 | |
| -!- trtr3434 [~trtr3434@sta-104-34.tm.net.my] has left #shogun [] | 10:41 | |
| blackburn | almost 10 million times is surely distance | 10:42 |
| n4nd0 | blackburn: so it should be probably something called from Eigen to compute the distance | 10:45 |
| blackburn | n4nd0: yes as distances are compute using eigen | 10:45 |
| blackburn | n4nd0: ah btw | 11:01 |
| blackburn | will you have time next friday? | 11:02 |
| blackburn | friday's night to be more precise | 11:02 |
| n4nd0 | i think so | 11:03 |
| n4nd0 | why? | 11:03 |
| n4nd0 | blackburn: ^ | 11:05 |
| blackburn | n4nd0: chris will have some time and we planned to hack paper | 11:05 |
| n4nd0 | blackburn: cool | 11:06 |
| n4nd0 | I will be available then | 11:06 |
| blackburn | n4nd0: nice | 11:06 |
| blackburn | n4nd0: I think a few hours should be enough once everything software related is ready | 11:07 |
| n4nd0 | ok | 11:07 |
| blackburn | n4nd0: we should release tapkee 0.1 I think | 11:10 |
| n4nd0 | blackburn: it sounds good | 11:10 |
| blackburn | n4nd0: may be friday too | 11:10 |
| n4nd0 | blackburn: what do we need to have ready before release? | 11:11 |
| blackburn | n4nd0: I don't know - it is pretty ok alread | 11:11 |
| n4nd0 | cool | 11:11 |
| blackburn | n4nd0: I wanted to attempt to fix gpu | 11:11 |
| blackburn | n4nd0: we aalso should get shogun released too :) | 11:15 |
| n4nd0 | blackburn: it is GPUDenseMatrixOperation and GPUDenseImplicitSquareMatrixOperation the parts that use GPU right? | 11:15 |
| n4nd0 | blackburn: hehe yeah | 11:15 |
| blackburn | n4nd0: exactly | 11:15 |
| n4nd0 | blackburn: the results were normally the same, weren't they? | 11:26 |
| n4nd0 | it was only a matter of speedup? | 11:26 |
| blackburn | n4nd0: I thought they weren't the same | 11:26 |
| n4nd0 | I remember I tested it | 11:26 |
| blackburn | and it was just slower? | 11:27 |
| n4nd0 | I don't remember if the results were always the same | 11:27 |
| blackburn | hmm okay | 11:27 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 13:00 | |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * 064b53c / examples/undocumented/libshogun/library_hdf5.cpp: https://github.com/shogun-toolbox/shogun/commit/064b53cd4ac01a8438efb7abb4268d87b359c1bf | 13:00 |
| shogun-notifier- | shogun: Added missed free in library hdf5 example | 13:00 |
| -!- travis-ci [~travis-ci@ec2-107-22-88-191.compute-1.amazonaws.com] has joined #shogun | 13:05 | |
| travis-ci | [travis-ci] it's Sergey Lisitsyn'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/5000219 | 13:05 |
| -!- travis-ci [~travis-ci@ec2-107-22-88-191.compute-1.amazonaws.com] has left #shogun [] | 13:05 | |
| shogun-buildbot_ | build #229 of ubu1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/229 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 13:11 |
| shogun-buildbot_ | build #827 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/827 | 13:47 |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 14:11 | |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * de82da5 / examples/undocumented/libshogun/library_serialization.cpp: https://github.com/shogun-toolbox/shogun/commit/de82da565a84e6a9fac01b7ba1ee2924fde772ed | 14:28 |
| shogun-notifier- | shogun: Fixed leaks in library serialization | 14:28 |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * 5fcbf7b / src/shogun/lib/tapkee/ (3 files): https://github.com/shogun-toolbox/shogun/commit/5fcbf7b7f0df8492e99e21847dee86a876eb2d01 | 14:28 |
| shogun-notifier- | shogun: Old eigen support in tapkee and laplacian eigenmaps fix | 14:28 |
| -!- travis-ci [~travis-ci@ec2-107-22-88-191.compute-1.amazonaws.com] has joined #shogun | 14:32 | |
| travis-ci | [travis-ci] it's Sergey Lisitsyn'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/5001158 | 14:32 |
| -!- travis-ci [~travis-ci@ec2-107-22-88-191.compute-1.amazonaws.com] has left #shogun [] | 14:32 | |
| shogun-buildbot_ | build #230 of ubu1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/230 | 14:54 |
| shogun-buildbot_ | build #231 of ubu1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/231 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 15:01 |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * 77b9c8e / applications/ (32 files): https://github.com/shogun-toolbox/shogun/commit/77b9c8e936ab5258165f22b44e8800e7b501a5fe | 15:26 |
| shogun-notifier- | shogun: Updated old edrt folder in applications | 15:26 |
| shogun-buildbot_ | build #232 of ubu1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/232 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 15:31 |
| -!- travis-ci [~travis-ci@ec2-107-22-88-191.compute-1.amazonaws.com] has joined #shogun | 15:33 | |
| travis-ci | [travis-ci] it's Sergey Lisitsyn'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/5001926 | 15:33 |
| -!- travis-ci [~travis-ci@ec2-107-22-88-191.compute-1.amazonaws.com] has left #shogun [] | 15:33 | |
| blackburn | ubu1 is not being updated | 15:34 |
| blackburn | argh | 15:34 |
| shogun-buildbot_ | build #233 of ubu1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/ubu1%20-%20libshogun/builds/233 | 15:52 |
| blackburn | finally | 15:52 |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has joined #shogun | 17:00 | |
| shogun-notifier- | shogun: Sergey Lisitsyn :master * 9554dab / src/shogun/structure/StructuredModel.h,src/shogun/structure/libbmrm.h: https://github.com/shogun-toolbox/shogun/commit/9554dab08344a46be07757dfb2ab0a9f8d8f50a3 | 17:26 |
| shogun-notifier- | shogun: Added some doc | 17:26 |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has joined #shogun | 17:37 | |
| shogun-buildbot_ | build #831 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/831 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 18:11 |
| -!- n4nd0 [~nando@s83-179-44-135.cust.tele2.se] has quit [Quit: leaving] | 18:22 | |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has quit [Ping timeout: 252 seconds] | 18:38 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 19:10 | |
| wiking | hu | 19:10 |
| blackburn | hu! | 19:10 |
| -!- zxtx [~zv@c-24-18-130-24.hsd1.wa.comcast.net] has quit [Ping timeout: 255 seconds] | 19:10 | |
| -!- zxtx [~zv@c-24-18-130-24.hsd1.wa.comcast.net] has joined #shogun | 19:22 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 20:26 | |
| -!- hoijui [~hoijui@141.23.95.39] has joined #shogun | 20:32 | |
| -!- hoijui [~hoijui@141.23.95.39] has quit [Ping timeout: 264 seconds] | 20:44 | |
| @sonney2k | wiking, please bring bsd1 buildbot back to live | 21:06 |
| wiking | sonney2k: shit it's again down | 21:19 |
| wiking | up and runnnin | 21:19 |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has joined #shogun | 21:55 | |
| @sonney2k | wiking, thx | 22:03 |
| @sonney2k | wiking, can we get rid of this warning: | 22:03 |
| @sonney2k | http://shogun-toolbox.org/buildbot/builders/bsd1%20-%20libshogun/builds/691/steps/test/logs/warnings%20%281%29 | 22:03 |
| -!- alexlovesdata [~binder@e178001222.adsl.alicedsl.de] has joined #shogun | 22:20 | |
| alexlovesdata | anybody still out there? | 22:20 |
| alexlovesdata | I want to make CRandomFourierGaussPreproc applicable to CDotfeatures | 22:21 |
| alexlovesdata | it seems that I have to derive a base class from CPreproc to define an interface for that | 22:21 |
| alexlovesdata | my question is: what apply() interface that base class (I call it CDotPreproc) derived from Cpreproc should have? | 22:23 |
| blackburn | alexlovesdata: hey there | 22:28 |
| alexlovesdata | hey blackburn :) | 22:28 |
| blackburn | alexlovesdata: let me check | 22:28 |
| alexlovesdata | I will derive it from CPreprocessor ... | 22:28 |
| blackburn | alexlovesdata: do you need out of sample for that preprocessor? | 22:30 |
| blackburn | I guess so.. | 22:30 |
| alexlovesdata | what do you mean by out of sample? | 22:31 |
| alexlovesdata | until now it is derived only from CDensePreprocessor<float64_t> | 22:32 |
| blackburn | alexlovesdata: you need to 'learn' it on training data and then apply for test, right? | 22:32 |
| alexlovesdata | no ... | 22:32 |
| alexlovesdata | you initialize it once | 22:32 |
| alexlovesdata | for testing you need to save the init parameters | 22:32 |
| alexlovesdata | but the init parameters do not depend on the data | 22:33 |
| alexlovesdata | however one needs to obtain a kernel width estimate prior to using that .. | 22:33 |
| blackburn | alexlovesdata: so you need to apply it to features only? | 22:35 |
| alexlovesdata | yep | 22:35 |
| blackburn | alexlovesdata: I am afraid no generic interface is here.. | 22:35 |
| alexlovesdata | but for application to test settings I need to save the settings via get_randomcoefficients ;) | 22:35 |
| alexlovesdata | I think the same ... | 22:35 |
| blackburn | whoops | 22:35 |
| alexlovesdata | no problem ... | 22:35 |
| blackburn | these functions are pretty wrong | 22:36 |
| alexlovesdata | for me it is not clear how to apply this to sparse features other than mistreating them as dense ones | 22:36 |
| blackburn | alexlovesdata: what is the output of applying it to sparse features? | 22:36 |
| alexlovesdata | same ... for string features I would need a gaussian distribution in string space | 22:36 |
| alexlovesdata | the output is a dense feature with a changed dimensionality | 22:37 |
| blackburn | alexlovesdata: preprocessor part is heavily broken in some means :D | 22:37 |
| blackburn | okay lets see | 22:37 |
| blackburn | I do not mind to change that I just need to realize how | 22:37 |
| alexlovesdata | ye ... to me it seems from the interface part also somewhat strange | 22:37 |
| alexlovesdata | typically it would make sense to use it with streamingfeatures or any features over a numeric type | 22:38 |
| alexlovesdata | a preprocessor gets one feature type as input but returns another feature type as output | 22:39 |
| blackburn | alexlovesdata: it is actually 'converter' | 22:39 |
| alexlovesdata | it should work on a feature matrix and on a single feature | 22:39 |
| blackburn | alexlovesdata: all dimension reduction is in 'converter' folder | 22:39 |
| alexlovesdata | for preprocessor we need a routine for checking the input and the output type | 22:39 |
| alexlovesdata | of the feature | 22:40 |
| blackburn | alexlovesdata: okay what about inheriting it from embeddingconverter | 22:40 |
| alexlovesdata | eg RF preproc has as input type a set of allowed features ... | 22:40 |
| blackburn | shogun/converter/EmbeddingConverter.h | 22:40 |
| alexlovesdata | i look it up | 22:40 |
| blackburn | alexlovesdata: it fits your requirement | 22:41 |
| blackburn | input is any features | 22:41 |
| blackburn | object | 22:41 |
| blackburn | output is dense | 22:41 |
| alexlovesdata | ye ... except that it lacks a check for allowed input feature type | 22:42 |
| alexlovesdata | however that can be done during runtime | 22:42 |
| blackburn | alexlovesdata: yeah just check it in embed method | 22:42 |
| blackburn | alexlovesdata: I can help you with first step | 22:42 |
| alexlovesdata | I need to check about conflicts with double inheritance w.r.t. to apply | 22:42 |
| blackburn | I can move it to converter and then you will fix things you'd like to fix | 22:43 |
| blackburn | alexlovesdata: double inheritance? | 22:43 |
| alexlovesdata | ye, from CDensePreprocessor<float64_t> | 22:43 |
| blackburn | alexlovesdata: no, it won't be inherited from dense preprocessor then | 22:44 |
| alexlovesdata | and from Embeddingconverter | 22:44 |
| blackburn | no, no double inheritance :) | 22:44 |
| alexlovesdata | does it make sense to move it from the preprocessors to converters? | 22:44 |
| alexlovesdata | any gain in usability? | 22:44 |
| blackburn | alexlovesdata: well more generic interface (that embed method) | 22:45 |
| blackburn | and apply | 22:45 |
| -!- hoijui [~hoijui@dslb-092-078-043-220.pools.arcor-ip.net] has quit [Ping timeout: 252 seconds] | 22:45 | |
| blackburn | alexlovesdata: so just cleaner interface | 22:47 |
| blackburn | I do not know what to do with preprocessor yet | 22:47 |
| blackburn | alexlovesdata: you don't use it as on-the-fly thing, right? | 22:48 |
| alexlovesdata | with Cstreamingfeatures it would make pretty sende | 22:49 |
| alexlovesdata | sense | 22:49 |
| alexlovesdata | but for that i need an interface which converts one feature vector into another | 22:49 |
| blackburn | hmm then I'd keep it in preprocessor | 22:49 |
| @sonney2k | alexlovesdata, err err | 22:49 |
| alexlovesdata | ie x -> R(x) | 22:49 |
| blackburn | you already have it here | 22:49 |
| alexlovesdata | err err = ? thinking error? | 22:49 |
| blackburn | master here | 22:49 |
| @sonney2k | alexlovesdata, you should implement your gaussianfourierfeatures form scratch | 22:50 |
| blackburn | haha I'd say something about shogun from scratch | 22:50 |
| @sonney2k | don't even think about wasting brain & cpu cycles! | 22:50 |
| alexlovesdata | with what goal/ direction Sonne? | 22:50 |
| @sonney2k | alexlovesdata, speed! | 22:50 |
| alexlovesdata | huh | 22:50 |
| @sonney2k | there is almost no use for the stuff you did in the preprocessor! | 22:50 |
| blackburn | I see nothing terribly wrong here | 22:50 |
| blackburn | sonney2k: what is wrong? | 22:51 |
| alexlovesdata | i have no experience w.r.t. to speed optimizations | 22:51 |
| @sonney2k | the difference is that dotfeatures only iterate over non-zero features | 22:51 |
| @sonney2k | for speed | 22:51 |
| alexlovesdata | but if you tell me what you have in mind I can understand hopefully | 22:51 |
| blackburn | but don't say anything about std::copy :D | 22:51 |
| @sonney2k | so doing a transformation x-> Phi(x) is not helpful | 22:51 |
| @sonney2k | (which is what preprocessors do) | 22:51 |
| blackburn | alexlovesdata: he probably means you need to emulate dot and add | 22:52 |
| blackburn | not to compute it explicitly | 22:52 |
| alexlovesdata | or he means that I use the dot from it | 22:52 |
| blackburn | sonney2k: I wish it was possible with HKM but it would be wrong | 22:54 |
| alexlovesdata | in principle it can be done IF I can embed the vector as a dot feature itself ... | 22:54 |
| alexlovesdata | that depends on the type of the dot feature | 22:54 |
| blackburn | alexlovesdata: are these random features still relevenat? | 22:54 |
| blackburn | relevant* | 22:55 |
| alexlovesdata | if you like to approximate a gaussian kernel by transforming features | 22:55 |
| alexlovesdata | so that the scalarproduct of the feature transform approx a gaussian, ye | 22:55 |
| @sonney2k | alexlovesdata, did you ask andrea about the post workshop stuff? | 22:55 |
| blackburn | alexlovesdata: I mean HKM seems to be pretty cool enough | 22:55 |
| alexlovesdata | not yet, Sonne | 22:55 |
| alexlovesdata | HKM = hierarchical k-means? | 22:56 |
| @sonney2k | alexlovesdata, please do next week... | 22:56 |
| alexlovesdata | ye, Sonne | 22:56 |
| blackburn | alexlovesdata: homo gay map | 22:56 |
| @sonney2k | thx | 22:56 |
| blackburn | alexlovesdata: err | 22:56 |
| blackburn | homogeneous kernel map | 22:56 |
| alexlovesdata | in principle it is the same | 22:56 |
| alexlovesdata | for gaussian kernel | 22:56 |
| blackburn | alexlovesdata: yeah but HKM can't approximate gaussian | 22:57 |
| alexlovesdata | some of the HKM kernels are not useful in practice | 22:57 |
| alexlovesdata | i would say gaussian is a special case of HKM approximations | 22:57 |
| blackburn | alexlovesdata: which ones? I had good experience with any kernel with HKM.. | 22:57 |
| blackburn | alexlovesdata: ah I wanted to ask you some things about my stupid kind of research | 22:58 |
| @sonney2k | alexlovesdata, regarding dotfeatures - just implement sparse_dot and add_to_dense vec as fast as possible | 22:58 |
| @sonney2k | so no copying around etc | 22:58 |
| alexlovesdata | RF is just another case of homogeneous kernel map | 22:58 |
| @sonney2k | and e.g. for sparse features it helps a lot to not first create a dense feature vector :) | 22:59 |
| @sonney2k | but just operate on the non-zero components (if possible) | 22:59 |
| @sonney2k | only then the DotFeatures framework is fast | 22:59 |
| @sonney2k | gtg | 22:59 |
| alexlovesdata | Sonne ... I would say: it should suffice to embed the stuff in a dotfeature itself | 23:00 |
| alexlovesdata | then I could use its dot | 23:00 |
| alexlovesdata | if you say: implement sparse_dot ... you mean for the preprocessor? | 23:00 |
| alexlovesdata | as far as I see it Sonne ... I would need to define for each dot feature type a way to define the gaussian in the space of the dot feature | 23:02 |
| alexlovesdata | thats not generic | 23:02 |
| alexlovesdata | like gaussian in string space | 23:02 |
| alexlovesdata | i would need to do that for each derived class (!) | 23:03 |
| alexlovesdata | I have to think about that ... | 23:05 |
| alexlovesdata | I see no fast ad hoc solution right now | 23:05 |
| alexlovesdata | ok I think I have an idea ... for Dotfeatures and for creating of streamingfeatures from existing ones ... | 23:21 |
| -!- alexlovesdata [~binder@e178001222.adsl.alicedsl.de] has left #shogun [] | 23:55 | |
| --- Log closed Sun Feb 24 00:00:49 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!