--- Log opened Mon Jun 10 00:00:38 2013 | ||
gsomix | this is not funny, but now I know one more term in German - "eich-invarianz". | 00:07 |
---|---|---|
gsomix | thanks to my book of classical electrodynamics. | 00:07 |
gsomix | procrastination time! | 00:08 |
-!- gsomix [~gsomix@83.234.54.9] has quit [Ping timeout: 245 seconds] | 00:22 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has left #shogun ["QUIT :Leaving."] | 00:39 | |
-!- FSCV [~FSCV@189.139.252.135] has quit [Quit: Leaving] | 03:04 | |
-!- pickle27 [~kevin@70-36-138-146.dsl.dynamic.sonic.net] has joined #shogun | 03:43 | |
-!- nube [~rho@49.244.41.114] has quit [Quit: Leaving.] | 03:44 | |
shogun-buildbot | build #423 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/423 | 04:06 |
-!- pickle27 [~kevin@70-36-138-146.dsl.dynamic.sonic.net] has quit [Quit: Leaving] | 04:46 | |
-!- lisitsyn [~lisitsyn@109-226-114-235.clients.tlt.100megabit.ru] has quit [Quit: Leaving.] | 05:01 | |
-!- gsomix [~gsomix@83.234.169.56] has joined #shogun | 05:01 | |
gsomix | good morning | 05:01 |
-!- foulwall [~foulwall@2001:da8:215:c252:aced:801f:4a14:f26c] has joined #shogun | 05:10 | |
-!- foulwall [~foulwall@2001:da8:215:c252:aced:801f:4a14:f26c] has quit [Remote host closed the connection] | 05:55 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 08:28 | |
-!- mode/#shogun [+o lisitsyn] by ChanServ | 08:28 | |
gsomix | not interesting | 08:34 |
gsomix | exam is automagically passed | 08:34 |
-!- gsomix [~gsomix@83.234.169.56] has quit [Quit: Leaving] | 08:45 | |
-!- gsomix [~Miranda@83.234.169.56] has joined #shogun | 08:48 | |
-!- sonne|work [~sonnenbu@sams-office-nat.tomtomgroup.com] has joined #shogun | 09:18 | |
gsomix | sonne|work: hey | 09:21 |
sonne|work | ho | 09:21 |
sonne|work | gsomix: not in exam? | 09:21 |
gsomix | sonne|work: passed | 09:22 |
sonne|work | hah very good :) | 09:22 |
-!- gsomix [~Miranda@83.234.169.56] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] | 09:50 | |
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Ping timeout: 256 seconds] | 10:16 | |
-!- gsomix [~Miranda@r206-10.smr.ru] has joined #shogun | 10:44 | |
-!- lambday [67157d36@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.125.54] has joined #shogun | 11:11 | |
lambday | sonney2k: moin :) | 11:11 |
sonne|work | hey lambday! | 11:11 |
lambday | sonne|work: hi :) | 11:11 |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has joined #shogun | 11:24 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 11:24 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 12:02 | |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * 97bfa44 / / (4 files): https://github.com/shogun-toolbox/shogun/commit/97bfa445963e70b2ac008cd6ea8cbe24b4553f72 | 12:02 |
shogun-notifier- | shogun: Fix backporting of package finders from 2.8.8 | 12:02 |
-!- travis-ci [~travis-ci@ec2-50-17-17-135.compute-1.amazonaws.com] has joined #shogun | 12:11 | |
travis-ci | [travis-ci] it's Viktor Gal'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/7944576 | 12:11 |
-!- travis-ci [~travis-ci@ec2-50-17-17-135.compute-1.amazonaws.com] has left #shogun [] | 12:11 | |
-!- HeikoS1 [~heiko@nat-189-35.internal.eduroam.ucl.ac.uk] has joined #shogun | 12:14 | |
HeikoS1 | lambday: around? | 12:18 |
lambday | HeikoS1: yes | 12:18 |
HeikoS1 | good, hi :) | 12:18 |
lambday | checked the log, works fine :) | 12:18 |
lambday | hi | 12:18 |
HeikoS1 | nice | 12:19 |
HeikoS1 | okay | 12:19 |
lambday | how about | 12:19 |
HeikoS1 | so what I would suggest for the dense exact matrix logs is | 12:19 |
lambday | okay | 12:19 |
HeikoS1 | to have in instance of the linear operator function class that does exact matrix log | 12:19 |
HeikoS1 | and the linear operator is just a dense matrix (which is stored and can be accessed) | 12:19 |
lambday | yes... CLogOperatorFunction | 12:20 |
HeikoS1 | then the linear operator function class just accesses the matrix and creates a task | 12:20 |
HeikoS1 | which simply uses eigen to computet the log | 12:20 |
HeikoS1 | this way, we would already use the full framework | 12:20 |
HeikoS1 | CExactMatrixLog | 12:20 |
HeikoS1 | or even CMatrixLog | 12:20 |
HeikoS1 | or CDenseMatrixLog | 12:20 |
lambday | HeikoS1: perfect! | 12:20 |
HeikoS1 | because it will only work for CDenseMatrix liena roperators | 12:21 |
lambday | yes | 12:21 |
HeikoS1 | do you think this will be useful? | 12:21 |
lambday | and, what should be a good name for the subclass of tasks (jobs) that does that | 12:21 |
HeikoS1 | in terms of testing the framework ? | 12:21 |
lambday | I was thinking of CTraceLogComputationJob or something | 12:21 |
HeikoS1 | since you had doubts :) | 12:21 |
lambday | HeikoS1: of course!! the thing that you said about focusing more on the framework is just perfect! | 12:21 |
HeikoS1 | okay then, note that you can really go for the full things | 12:22 |
lambday | we'll already have a working thing.. and we'll iteratively integrate things | 12:22 |
HeikoS1 | you can do the trace with normal vectors | 12:22 |
HeikoS1 | so all classes are used | 12:22 |
HeikoS1 | CExactLogTask | 12:22 |
HeikoS1 | or similar | 12:22 |
HeikoS1 | is a good name | 12:22 |
lambday | hmmm.. I suck at choosing names! :( | 12:23 |
HeikoS1 | lambday: haha, me too :) | 12:23 |
lambday | no, its a really good name | 12:23 |
lambday | :D | 12:23 |
HeikoS1 | always good to ask some people | 12:23 |
HeikoS1 | lisitsyn: around? | 12:23 |
HeikoS1 | wiking: around? | 12:23 |
HeikoS1 | lisitsyn: any updates on the removal of "clone" ? | 12:23 |
HeikoS1 | wiking: any updates on the automagic generated set of unit-tests? | 12:24 |
lambday | HeikoS1: I'll send the class diagram soon | 12:26 |
HeikoS1 | lambday: do we really need a new diagram for this? | 12:26 |
HeikoS1 | its just a few instances added right? | 12:26 |
lambday | HeikoS1: yes.. | 12:26 |
HeikoS1 | I would rather not put those into the diagram | 12:26 |
HeikoS1 | since it gets too large then | 12:26 |
HeikoS1 | (we can use it later for documentation, so lets keep it clean= | 12:27 |
HeikoS1 | maybe rather start implementing the abstract bases | 12:27 |
HeikoS1 | and then our first easy implementation | 12:27 |
HeikoS1 | that already will be a huge patch | 12:27 |
lambday | HeikoS1: yup! :-/ | 12:27 |
lambday | where should I put the classes? | 12:28 |
lambday | mathematics? statistics? | 12:28 |
HeikoS1 | lambday: good point | 12:30 |
HeikoS1 | thinkink | 12:30 |
* lambday too thinks | 12:31 | |
HeikoS1 | I suggest this: | 12:31 |
HeikoS1 | statistics/logdet | 12:31 |
HeikoS1 | should have a seperate folder | 12:31 |
HeikoS1 | since its so many classes | 12:31 |
HeikoS1 | but the computation class should be somewhere else | 12:31 |
lambday | base? | 12:32 |
lambday | no that's bad | 12:32 |
HeikoS1 | lib | 12:32 |
HeikoS1 | but it should also have a seperate subfolder | 12:32 |
HeikoS1 | call it computation for now | 12:33 |
HeikoS1 | and then in there we can define the base, the serial one, and maybe even the tasks | 12:33 |
HeikoS1 | no the tasks go into statistics/logdet | 12:33 |
lambday | the base class of CIndependentTask, should be in the lib, right? | 12:34 |
lambday | or Job | 12:34 |
HeikoS1 | job | 12:34 |
HeikoS1 | yeah put it into lib for now | 12:34 |
lambday | and the CIndependentJobResult | 12:34 |
lambday | this one too | 12:34 |
HeikoS1 | and the computation class also | 12:34 |
HeikoS1 | yes | 12:34 |
HeikoS1 | so there are 3 base classes | 12:34 |
HeikoS1 | and 1 implementation (serial) | 12:34 |
lambday | serial? | 12:35 |
HeikoS1 | lambday: btw we now have clone() for all CSGObjects, so that might be useful when creating computation jobs / parallel computation | 12:35 |
HeikoS1 | lambday: yes, first implementation is serial | 12:35 |
HeikoS1 | one job after another | 12:35 |
lambday | oh you mean that | 12:35 |
lambday | and clone, ya saw the mail | 12:35 |
lambday | deep copy.. | 12:35 |
lambday | but we have shared things among the jobs | 12:36 |
HeikoS1 | lambday: yes, lets worry about this later, was just a comment | 12:36 |
HeikoS1 | first is serial | 12:36 |
HeikoS1 | the job stuff might eat some time once we start extending it, so lets start again simple | 12:37 |
lambday | the CExactLogJob would have this m_log_operator (for the log(C)) and m_vector (samples), and the compute then simply applies the log_operator on the sample vec, and then compute the dot product of the result vec and the original vec | 12:39 |
lambday | and gives a list fo computation results | 12:39 |
lambday | aggregate then just sums them up | 12:39 |
lambday | log_operator is shared among all jobs | 12:40 |
HeikoS1 | lambday: wait ... | 12:40 |
lambday | okay | 12:41 |
HeikoS1 | lambday: so things should be exactly as discussed before | 12:41 |
HeikoS1 | let me find the mail | 12:41 |
lambday | yes.. I'm trying to fit this in terms of previously discussed things.. | 12:42 |
HeikoS1 | the main class is this CLogDetEstimator | 12:44 |
lambday | yes | 12:44 |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has quit [Ping timeout: 250 seconds] | 12:45 | |
HeikoS1 | why do you have the samples in the job? | 12:45 |
lambday | in the existing diagram you mean? | 12:46 |
HeikoS1 | no you just wrote this | 12:46 |
HeikoS1 | in my memory, the trace samples are only only in the CLogDetEstimator class | 12:46 |
HeikoS1 | and the dot products are computed there | 12:46 |
HeikoS1 | or did we change this? | 12:46 |
HeikoS1 | ah | 12:46 |
HeikoS1 | sorry | 12:46 |
HeikoS1 | lambday: sorry it has been a while | 12:47 |
HeikoS1 | you are totally right | 12:47 |
HeikoS1 | the task compute log(M)*s | 12:47 |
HeikoS1 | so it needs s | 12:47 |
lambday | hmmm... yes... no problem, even I'm forgetting things :( | 12:47 |
lambday | okay, so for exact log | 12:47 |
lambday | we do the same | 12:48 |
HeikoS1 | yes | 12:48 |
lambday | compute log(M)*s | 12:48 |
HeikoS1 | thats the point | 12:48 |
lambday | and then the dot product? | 12:48 |
HeikoS1 | so the main class CLogDetEstimator | 12:48 |
HeikoS1 | uses exactly the same code | 12:48 |
HeikoS1 | to compute exact log and approximate log | 12:48 |
lambday | yes | 12:48 |
HeikoS1 | I would maybe start with this class | 12:48 |
HeikoS1 | and all its abstract dependencies | 12:49 |
HeikoS1 | then you can push and we can discuss | 12:49 |
HeikoS1 | please work in a seperate feature branch for this | 12:49 |
lambday | HeikoS1: as in? | 12:49 |
HeikoS1 | we can then push into shogun source in this different branch and develop in the usual way | 12:49 |
HeikoS1 | while we dont touch the develop branch yet | 12:49 |
lambday | git flow? | 12:49 |
HeikoS1 | use gitflow to create a new branch | 12:50 |
lambday | okay | 12:50 |
HeikoS1 | yeah or do it by hand | 12:50 |
HeikoS1 | and when you push, push into the same branch | 12:50 |
HeikoS1 | and the PR is then also against the same branch in shogun | 12:50 |
HeikoS1 | once things work, we merge , then continue extending | 12:50 |
lambday | okay.. | 12:50 |
lambday | and before pushing, rebase against develop | 12:51 |
HeikoS1 | but if the exact log works, many things to test already | 12:51 |
lambday | ? | 12:51 |
HeikoS1 | yeah do this from time to time to avoid it getting out of synch | 12:51 |
HeikoS1 | make sure not to do many changes to existing code to avoid conflicts | 12:51 |
lambday | HeikoS1: ya.. mostly it will be just addition | 12:52 |
HeikoS1 | whenever you change something existing, do it in develop and push there, then rebase your feature branch | 12:52 |
HeikoS1 | lambday: exactly | 12:52 |
lambday | okay | 12:52 |
@lisitsyn | HeikoS1: not yet sorry | 12:56 |
-!- vgorbati [c3ee5cb1@gateway/web/freenode/ip.195.238.92.177] has joined #shogun | 13:05 | |
HeikoS1 | lisitsyn: not that you could use the deep copy clone if you wanted | 13:13 |
HeikoS1 | lisitsyn: we could also add a list of parameters to ignore when cloning | 13:13 |
-!- thoralf [~thoralf@enki.zib.de] has joined #shogun | 13:17 | |
thoralf | Hey. | 13:18 |
HeikoS1 | thoralf: hi! | 13:18 |
thoralf | Hey Mr. S1 | 13:18 |
@wiking | HeikoS1: pong | 13:18 |
HeikoS1 | S1? :) | 13:18 |
HeikoS1 | haha | 13:18 |
HeikoS1 | irc madness | 13:18 |
HeikoS1 | wiking: hey! | 13:19 |
HeikoS1 | how is this test stuff going? | 13:19 |
thoralf | HeikoS1: IRC still feels like nineties :) | 13:19 |
@wiking | thoralf: why u want google wave? :) | 13:19 |
HeikoS1 | thoralf: indeed | 13:19 |
HeikoS1 | thoralf: most people I tell: If you have problems, join us in IRC say " what does IRC mean?" :) | 13:19 |
HeikoS1 | but is there an alternative? | 13:19 |
@lisitsyn | skype :D | 13:19 |
HeikoS1 | lisitsyn: haha :) | 13:20 |
@lisitsyn | no I like irc | 13:20 |
@lisitsyn | what is wrong with irc? | 13:20 |
@wiking | HeikoS1: so the only question remains: do you want the examples to be generated in the approriate file, or we dont care about that. i.e. GaussianKernel->clone() test should be in GaussianKernel_unittest.cc, or should we just have one base/clone_unittest.cc? | 13:20 |
HeikoS1 | wiking: nono, just one sepearte file for all those tests | 13:20 |
HeikoS1 | otherwise its horror | 13:20 |
@lisitsyn | >700 files | 13:21 |
HeikoS1 | the file should be in base | 13:21 |
@lisitsyn | instantly | 13:21 |
@wiking | lisitsyn: well then we can claim that we have a loooot of unit tests :) | 13:21 |
HeikoS1 | and be called comething as SGObject_equals_clone_unittest or so | 13:21 |
@lisitsyn | wiking: yeah more than 700 :D | 13:21 |
HeikoS1 | lisitsyn, wiking this file will be very useful | 13:21 |
@lisitsyn | just count # of classes | 13:21 |
@wiking | HeikoS1: so basically you would do a ->clone() + equals() call in that test /:) | 13:21 |
@lisitsyn | and say we have > # of classes tests | 13:21 |
HeikoS1 | since if you run it with valgrind, it will detect whether parameters have not been properly initialised | 13:21 |
HeikoS1 | wiking: yes, the code would look as the one I sent you | 13:22 |
HeikoS1 | yesterday | 13:22 |
@wiking | HeikoS1: plz send it in an email :) | 13:22 |
HeikoS1 | ok | 13:22 |
@wiking | HeikoS1: i dont wanna dig in irc logs | 13:22 |
@wiking | btw: can i push it in if it's ready and put it on skip? and then when u push your final code then we can active the unit test? | 13:23 |
HeikoS1 | wiking: thats fine! | 13:24 |
@wiking | hahaha btw my name is neither in CONTRIBUTIONS nor in AUTHORS :) | 13:24 |
HeikoS1 | wiking: sent the mail, just replace the GaussianKernel with any non-abstract class | 13:24 |
@wiking | yep got it | 13:24 |
HeikoS1 | wiking: add it then :) | 13:24 |
HeikoS1 | wiking: cool, many thanks! | 13:24 |
HeikoS1 | lisitsyn: how long will the clone removing take? | 13:24 |
@wiking | HeikoS1: we have already one SGObject_unittest.cc | 13:25 |
@wiking | HeikoS1: i'm tempted to keep that file | 13:25 |
@wiking | just make it a template ;P | 13:25 |
HeikoS1 | wiking: I know | 13:25 |
HeikoS1 | wiking: no, please make a new file | 13:26 |
HeikoS1 | with different name | 13:26 |
HeikoS1 | since people will edit the existing one | 13:26 |
HeikoS1 | and put something as "autogenerated file - do not edit" on tup | 13:26 |
HeikoS1 | oh, and you can add your name in there in the GPL copyright :D | 13:26 |
HeikoS1 | only include is class_list.h btw | 13:27 |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has joined #shogun | 13:43 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 13:43 | |
@lisitsyn | HeikoS1: I don't kno | 13:46 |
HeikoS1 | lisitsyn: thing is I dont want to touch those things since I did not write the code and dont really know whats going on - since its not tested I won't notice if I break stuff ;) | 13:46 |
@lisitsyn | HeikoS1: let me dig into that tonight and then I'll let you know | 13:47 |
HeikoS1 | lisitsyn: cool thanks! :) | 13:47 |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 13:48 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has quit [Read error: Connection reset by peer] | 13:57 | |
thoralf | HeikoS1: I closed issue #1164, because I was wrong. | 13:59 |
HeikoS1 | thoralf: what was the problem then? | 13:59 |
HeikoS1 | I saw | 13:59 |
HeikoS1 | please add a comment on how to use it, so others dont make this mistake again :) | 14:00 |
thoralf | HeikoS1: I don't know how to use it. For inc=1 it works like I expected. inc>1 is something used for multiclass settings. | 14:01 |
HeikoS1 | thoralf: okay, Ill push the others then to document it | 14:02 |
-!- lambday [67157d36@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.125.54] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 14:04 | |
thoralf | "A hand crafted IRC client"? So they don't use compilers? :) | 14:05 |
-!- HeikoS2 [9052bd23@gateway/web/cgi-irc/kiwiirc.com/ip.144.82.189.35] has joined #shogun | 14:08 | |
HeikoS2 | thoralf:this client is actually very nice! | 14:08 |
HeikoS2 | all web-base but with comfort | 14:08 |
HeikoS2 | even has autocompletition | 14:08 |
-!- HeikoS2 [9052bd23@gateway/web/cgi-irc/kiwiirc.com/ip.144.82.189.35] has left #shogun [] | 14:08 | |
@iglesiasg | thoralf: hey | 14:08 |
thoralf | iglesiasg: Hey. | 14:09 |
@iglesiasg | thoralf: do you think it can be right for inc>1? | 14:09 |
@iglesiasg | thoralf: it does not really make sense for me then | 14:09 |
thoralf | iglesiasg: I think you should ask soeren. I suppose, this method does take something like a vector of length (num_classes*num_examples) and then only taking every inc-th element to compute the arg_max of a specific subset of decision values? | 14:12 |
@iglesiasg | thoralf: let's see if we get an answer from him today | 14:14 |
thoralf | So "len" is actually not the length of the vector, as I was thinking, but the number of examples or sth like that. | 14:14 |
@iglesiasg | thoralf: in the case you are saying the argument len should be equal to num_examples | 14:14 |
@iglesiasg | yeah | 14:14 |
thoralf | Yes, for inc=1 it should hold that len=length(vector). | 14:15 |
-!- vgorbati [c3ee5cb1@gateway/web/freenode/ip.195.238.92.177] has quit [Ping timeout: 250 seconds] | 14:47 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 15:02 | |
-!- gsomix [~Miranda@r206-10.smr.ru] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] | 15:12 | |
-!- lambday [67157d36@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.125.54] has joined #shogun | 15:32 | |
-!- nube [~rho@49.244.57.131] has joined #shogun | 15:43 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has joined #shogun | 15:53 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 16:18 | |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * ea7afd6 / src/shogun/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/ea7afd6e224fd825cf7f6daaf7bcd5b3ffe5faef | 16:18 |
shogun-notifier- | shogun: Add 'make install' target for libshogun | 16:18 |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has quit [Quit: Page closed] | 16:26 | |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * 3c19faa / CMakeLists.txt,src/shogun/CMakeLists.txt: https://github.com/shogun-toolbox/shogun/commit/3c19faac1aa95aaaad1f0e00e02e75f54d6da7f6 | 16:31 |
shogun-notifier- | shogun: Fix LZO linking flags and class_list.cpp compilation | 16:31 |
-!- FSCV [~FSCV@187.210.54.166] has joined #shogun | 16:37 | |
-!- travis-ci [~travis-ci@ec2-107-22-45-75.compute-1.amazonaws.com] has joined #shogun | 16:40 | |
travis-ci | [travis-ci] it's Viktor Gal'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/7951371 | 16:40 |
-!- travis-ci [~travis-ci@ec2-107-22-45-75.compute-1.amazonaws.com] has left #shogun [] | 16:40 | |
shogun-notifier- | shogun: Viktor Gal :feature/CMake * 0917a31 / cmake/FindLZO.cmake: https://github.com/shogun-toolbox/shogun/commit/0917a31acbc7b598374570d95c74a780f93c40a7 | 17:25 |
shogun-notifier- | shogun: Fix FindLZO.cmake | 17:25 |
shogun-notifier- | shogun: Detecting liblzo on darwin was not working and the linking flags | 17:25 |
shogun-notifier- | shogun: were not exported properly | 17:25 |
-!- travis-ci [~travis-ci@ec2-107-22-45-75.compute-1.amazonaws.com] has joined #shogun | 17:37 | |
travis-ci | [travis-ci] it's Viktor Gal'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/7953114 | 17:37 |
-!- travis-ci [~travis-ci@ec2-107-22-45-75.compute-1.amazonaws.com] has left #shogun [] | 17:37 | |
@wiking | woohoooo 2 successful build out of 9 \o/ | 17:43 |
-!- naywhaya1e is now known as naywhayare | 17:43 | |
lambday | template declaration has to be in single line to make it pass the PT_NOT_GENERIC thing in class_list.cpp :| | 17:52 |
-!- cwidmer [5fd02c64@gateway/web/freenode/ip.95.208.44.100] has joined #shogun | 18:27 | |
-!- sonney2k [~shogun@7nn.de] has quit [Excess Flood] | 18:31 | |
-!- sonney2k [~shogun@7nn.de] has joined #shogun | 18:31 | |
-!- cwidmer [5fd02c64@gateway/web/freenode/ip.95.208.44.100] has quit [Quit: Page closed] | 18:43 | |
-!- van51 [~van51@athedsl-408350.home.otenet.gr] has left #shogun ["PING 1370882948"] | 18:49 | |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 252 seconds] | 19:24 | |
-!- mode/#shogun [+o sonney2k] by ChanServ | 19:40 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 19:45 | |
-!- nube [~rho@49.244.57.131] has quit [Ping timeout: 246 seconds] | 20:23 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 20:25 | |
-!- vgorbati [~vgorbati@212.2.159.34] has joined #shogun | 20:25 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 20:30 | |
shogun-notifier- | shogun: Soeren Sonnenburg :feature/sparse_matrix * afeb303 / / (7 files): https://github.com/shogun-toolbox/shogun/commit/afeb3034f0a7190864a35adc271faa3b5e44147d | 20:30 |
shogun-notifier- | shogun: make sparse features use SGSparseMatrix underneath | 20:30 |
-!- nube [~rho@49.244.74.29] has joined #shogun | 20:38 | |
@sonney2k | HeikoS, you said you don't get why we have SGVector? | 20:41 |
@sonney2k | HeikoS, could you explain that? | 20:41 |
@sonney2k | HeikoS, and you did complain the structure of the sparse features. What's wrong with it? | 20:41 |
HeikoS1 | sonney2k: so about the vector | 20:42 |
HeikoS1 | sometimes it would be useful if SGVector and SGMatrix had a common bas | 20:42 |
HeikoS1 | i.e. Vector is a matrix with num_cols=1 | 20:43 |
HeikoS1 | then methods could either return vectors or matrices | 20:43 |
HeikoS1 | changing their behaviour at implementation time | 20:43 |
HeikoS1 | also, all methods that we call on these objects are the same | 20:43 |
HeikoS1 | like set_const, math operations etc | 20:43 |
HeikoS1 | and about the sparse, I actually meant string | 20:44 |
HeikoS1 | why do we have that? | 20:44 |
HeikoS1 | why not just use vector for string? | 20:44 |
HeikoS1 | memory is pre-allocated anyways | 20:44 |
HeikoS1 | sonney2k: sorry, I meant runtime, not implementation time | 20:46 |
-!- travis-ci [~travis-ci@ec2-54-224-160-16.compute-1.amazonaws.com] has joined #shogun | 20:47 | |
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/7958602 | 20:47 |
-!- travis-ci [~travis-ci@ec2-54-224-160-16.compute-1.amazonaws.com] has left #shogun [] | 20:47 | |
-!- lisitsyn [~lisitsyn@83.234.54.170] has joined #shogun | 20:47 | |
@sonney2k | HeikoS, dropping SGString is already decided | 20:47 |
@sonney2k | HeikoS, about SGVector - the same argument holds for nd-arrays then | 20:48 |
@sonney2k | HeikoS, SGVector got introduced to be minimal. back then a ptr to data and length | 20:49 |
HeikoS1 | sonney2k: but you want to replace it with the variable length right? | 20:49 |
@sonney2k | to be efficient when you just have very few dims | 20:49 |
@sonney2k | it was never meant to be derived from some baseclass (overhead!) | 20:49 |
HeikoS1 | sonney2k: I wonder whether this would hurt us, treating vectors as 2d arrays? | 20:49 |
HeikoS1 | sonney2k: ok, maybe the solution is to have this eigen factory for math stuff | 20:50 |
shogun-notifier- | shogun: Soeren Sonnenburg :feature/sparse_matrix * 3902963 / src/shogun/features/SparseFeatures.cpp,src/shogun/features/SparseFeatures.h: https://github.com/shogun-toolbox/shogun/commit/3902963981e337a8f808916702ab43a14680dc45 | 20:50 |
shogun-notifier- | shogun: don't change the api return sparse transposed features | 20:50 |
HeikoS1 | then all these problems disappear | 20:50 |
HeikoS1 | since eigen does have this base class for both vector and matrix | 20:50 |
HeikoS1 | ah but still for interfacves its sometimes annoying | 20:50 |
@sonney2k | HeikoS, but then we have to rely on eigen3 completely | 20:51 |
@sonney2k | and that is not an option | 20:51 |
HeikoS1 | sonney2k: no as you said, have a factory | 20:51 |
HeikoS1 | that is seperate and then one can use eigen's math functions on matrices/vectors | 20:51 |
@sonney2k | shogun started with no vectors/matrices at all | 20:51 |
@sonney2k | it was all about strings | 20:51 |
HeikoS1 | well thats different now isnt it? | 20:52 |
@sonney2k | lots and lots of code are still about strings | 20:52 |
@sonney2k | but yes | 20:52 |
lisitsyn | eigen is easy peasy dependency | 20:53 |
lisitsyn | just my 2 cents :D | 20:53 |
HeikoS1 | I think sonney2k suggestion with the factory is nice | 20:53 |
HeikoS1 | then one can decide whether to rely on eigen or not | 20:53 |
HeikoS1 | but re-implementing all matrix functions (mean/cov/bla) is a little annoying and we even have to do it twice since SGMatrix/SGVector | 20:54 |
@sonney2k | HeikoS, well we certainly could implement it just once but that is not the point here I guess | 20:55 |
lisitsyn | I am still not a fan of having math in sgmatrix | 20:55 |
-!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has joined #shogun | 20:56 | |
@sonney2k | lisitsyn, you want it back in CMath? | 20:56 |
lisitsyn | sonney2k: I don't know - I'd prefer to treat them as eigen matrices | 20:56 |
HeikoS1 | sonney2k: why dont you want to rely on eigen? | 20:57 |
HeikoS1 | we could remove all this ugly stuff ... and have a well tested version of it instead | 20:57 |
lisitsyn | in the end we'd have to rely on something | 20:57 |
lisitsyn | either blas or eigen3 or armadillo or anything | 20:57 |
HeikoS1 | I gotta go now, see you tomorrow! | 20:58 |
HeikoS1 | lisitsyn: could you check the clone stuff at some point? Id like to merge before it gets out of synch with the dev branch :) | 20:58 |
lisitsyn | HeikoS1: yeah let me recover a bit from job thing and then I'll check | 20:59 |
@sonney2k | lisitsyn, only for complex stuff. for lot of shogun stuff all you need is a dot product | 20:59 |
@sonney2k | no cov/mean whatever | 20:59 |
HeikoS1 | lisitsyn: no worries, going home anyway | 20:59 |
HeikoS1 | sonney2k: dot can be in shogun | 20:59 |
HeikoS1 | thats easy | 20:59 |
HeikoS1 | but we have much more right? | 20:59 |
@sonney2k | it is of course | 20:59 |
HeikoS1 | dot should be in shogun | 20:59 |
HeikoS1 | since its fast then | 21:00 |
@sonney2k | I guess we have to define classes of algorithms that we want to work w/o eigen | 21:01 |
@sonney2k | and I am totally fine that GPs/dimred etc require eigen | 21:01 |
HeikoS1 | sonney2k: again, what do you have against it? | 21:01 |
@sonney2k | I don't think any svm needs it | 21:01 |
lisitsyn | sonney2k: it is not a library I mean | 21:01 |
HeikoS1 | sonney2k: sure, svms dont need it | 21:01 |
lisitsyn | just headers | 21:01 |
@sonney2k | HeikoS, the usual issue people don't install it | 21:01 |
HeikoS1 | but svms also dont need any matrix/vector functions apart from dot | 21:01 |
@sonney2k | all questions we get on the mailinglist related to install problems are due to dependencies | 21:02 |
HeikoS1 | sonney2k: yes thats true | 21:02 |
lisitsyn | it is easier to install than blas | 21:02 |
HeikoS1 | that is also true | 21:02 |
@sonney2k | lisitsyn, so lets get rid of blas/lapack and use eigen for all this stuff | 21:03 |
@sonney2k | but lets keep the stuff working that doesn't need eigen | 21:03 |
HeikoS1 | me personally, I wont develop any ML code that uses matrices without eigen, its just so nice | 21:03 |
HeikoS1 | sonney2k: yep agreed, I think roman will add the factory btw | 21:03 |
@sonney2k | I more or less didn't use any matrix based libs for real | 21:04 |
HeikoS1 | also their tools are very nice: linear systems, factorizations | 21:04 |
HeikoS1 | how do you do linear solves? | 21:04 |
HeikoS1 | we have to depend on something for that | 21:04 |
@sonney2k | I don't... sure we do. | 21:04 |
HeikoS1 | but I agree for the svms | 21:05 |
HeikoS1 | should work straight away | 21:05 |
@sonney2k | eigen3 is totally fine if you need it. just no hard dependency. | 21:05 |
HeikoS1 | sonney2k: have you seen the serialistaion tests of lamday? | 21:06 |
@sonney2k | HeikoS, partially yes | 21:06 |
HeikoS1 | almost everything is tested now so feel free to start destroying things :) | 21:06 |
HeikoS1 | btw the equals/clone tests will serve some additional nice things | 21:06 |
@sonney2k | HeikoS, sparse stuff is building ... https://travis-ci.org/shogun-toolbox/shogun/builds/7959204 | 21:06 |
HeikoS1 | very often errors arise due to non-initialised class variables | 21:06 |
HeikoS1 | but now the tests will fail if one forgets that | 21:07 |
HeikoS1 | sonney2k: cool! | 21:07 |
@sonney2k | HeikoS, cool! | 21:07 |
@sonney2k | but you need valgrind to check that no? | 21:07 |
HeikoS1 | sonney2k: they might pass if not used | 21:07 |
HeikoS1 | but they usually should not | 21:07 |
HeikoS1 | since twice uninitialized memory should not be equal | 21:07 |
@sonney2k | HeikoS, any idea how to serialize SGSparseMatrix? | 21:08 |
@sonney2k | things fail now https://travis-ci.org/shogun-toolbox/shogun/jobs/7959208 | 21:08 |
@sonney2k | I currently just set it to override the vector pointers etc | 21:08 |
HeikoS1 | whats the problem currently? | 21:08 |
HeikoS1 | cant we just write the entries to the file one by one? | 21:09 |
@sonney2k | I am currently doing m_parameters->add(&sparse_feature_matrix.num_features, "sparse_feature_matrix.num_features",...) | 21:09 |
@sonney2k | HeikoS, we had support for this SGSparseVector<>* stuff | 21:10 |
@sonney2k | but not the referenced data type | 21:10 |
@sonney2k | HeikoS, so we have the same problem we had with SGVector now | 21:10 |
@sonney2k | I don't remember how you solved it | 21:10 |
@sonney2k | if there was no migration framework I would say we need to read in the data and then assign the object with foo=SGSparseMatrix(...) | 21:11 |
-!- travis-ci [~travis-ci@ec2-50-19-67-126.compute-1.amazonaws.com] has joined #shogun | 21:15 | |
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/7959204 | 21:15 |
-!- travis-ci [~travis-ci@ec2-50-19-67-126.compute-1.amazonaws.com] has left #shogun [] | 21:15 | |
@sonney2k | HeikoS, my particular concern is how can we serialize SGReferenced data or any future smart pointer enabled data at all?! | 21:17 |
@sonney2k | I mean we have to get references right | 21:17 |
@sonney2k | refcounts I mean | 21:18 |
@sonney2k | otherwise we will have crashes or memory leaks | 21:18 |
@sonney2k | lambday, maybe you have any idea? | 21:19 |
HeikoS1 | sonney2k: why? | 21:21 |
HeikoS1 | one can just recursively follow the references from within the file | 21:22 |
HeikoS1 | and then increment | 21:22 |
HeikoS1 | why would one store the refcount? | 21:22 |
HeikoS1 | when data is loaded, it is not references from anywhere | 21:22 |
HeikoS1 | at least thats how I would do it | 21:22 |
HeikoS1 | so just dont allow an SGMatrix using data of a class which is then de-serialised | 21:23 |
HeikoS1 | just have a new instance for loading | 21:23 |
HeikoS1 | ok really going now, talk to you tomorro | 21:23 |
HeikoS1 | w | 21:23 |
-!- HeikoS1 [~heiko@nat-189-35.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 21:23 | |
@sonney2k | ok tomorrow I will give you an example | 21:24 |
-!- vgorbati [~vgorbati@212.2.159.34] has quit [Quit: vgorbati] | 21:54 | |
lisitsyn | sonney2k: we are now using deprecated numpy api | 22:17 |
lisitsyn | according to warnings I see | 22:17 |
@wiking | :) | 22:18 |
@wiking | depreeeeeeeeeeeeeeeeecaaaateeeeeeeeeeeeeeee IT | 22:18 |
shogun-notifier- | shogun: Sergey Lisitsyn :develop * 13616ed / src/ (9 files): https://github.com/shogun-toolbox/shogun/commit/13616ede4921bc33cd5a5ac965cf0d6bbb56f7fd | 23:28 |
shogun-notifier- | shogun: Remove redundant clone, drop MT composite machine | 23:28 |
lisitsyn | wiking: just drop any class in case of doubts | 23:29 |
lisitsyn | :D | 23:29 |
lisitsyn | like did I | 23:29 |
-!- lambday [67157d36@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.125.54] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 23:30 | |
@wiking | :> | 23:30 |
shogun-buildbot | build #933 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/933 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 23:33 |
lisitsyn | ah compilers are for dummies | 23:34 |
@wiking | heheh that cygwin bot is down for a while | 23:34 |
-!- lisitsyn [~lisitsyn@83.234.54.170] has quit [Ping timeout: 255 seconds] | 23:59 | |
--- Log closed Tue Jun 11 00:00:40 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!