| --- Log opened Thu May 03 00:00:37 2012 | ||
| CIA-113 | shogun: Soeren Sonnenburg master * r52b1bf0 / (34 files in 13 dirs): | 00:08 |
|---|---|---|
| CIA-113 | shogun: split up SG* datatypes into separate files | 00:08 |
| CIA-113 | shogun: - fix includes accordingly | 00:08 |
| CIA-113 | shogun: - drop direct access to do_free component of sgvector | 00:08 |
| CIA-113 | shogun: - add some ref counting to sgvector - http://git.io/r5cjJw | 00:08 |
| @sonney2k | gsomix, could be | 00:08 |
| @sonney2k | ignore the class for now | 00:08 |
| @sonney2k | gsomix, you can do that by putting a IGNORE_IN_CLASSLIST in front of class | 00:09 |
| @sonney2k | half way through sgvector again - yay! | 00:19 |
| gsomix | sonney2k, I'm testing new CSet. | 00:33 |
| gsomix | I am amazed at own slow speed of work. :( | 00:33 |
| -!- sonney2k [~shogun@7nn.de] has quit [Ping timeout: 276 seconds] | 00:40 | |
| -!- sonney2k [~shogun@7nn.de] has joined #shogun | 00:40 | |
| gsomix | sonney2k, it seems, that new CSet works right. | 00:54 |
| gsomix | tomorrow I'll replace old by new. | 00:57 |
| gsomix | time to sleep, 3am at my clock | 00:58 |
| gsomix | I have the physical culture classes at 8am, oh | 00:58 |
| gsomix | good night guys | 00:58 |
| gsomix | sonney2k, do not forget about sleep. :) | 00:59 |
| -!- av3ngr [av3ngr@nat/redhat/x-csnenpsdsbtyljfc] has joined #shogun | 01:19 | |
| -!- vikram360 [~vikram360@117.192.167.99] has quit [Ping timeout: 246 seconds] | 01:26 | |
| -!- vikram360 [~vikram360@117.192.161.225] has joined #shogun | 01:27 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 02:57 | |
| -!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has left #shogun ["Leaving"] | 02:59 | |
| wiking | http://9gag.com/gag/4055786 | 03:29 |
| wiking | :D | 03:30 |
| -!- vikram360 [~vikram360@117.192.161.225] has quit [Ping timeout: 246 seconds] | 06:36 | |
| -!- mode/#shogun [+o sonney2k] by ChanServ | 07:47 | |
| @sonney2k | gsomix, yeah... with kids you hardly get any | 07:48 |
| * sonney2k continues with sgvector | 07:48 | |
| CIA-113 | shogun: Soeren Sonnenburg master * r9d458c8 / (29 files in 10 dirs): remove destroy / free vectro functions - http://git.io/M73D9w | 08:07 |
| shogun-buildbot | build #809 of libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/libshogun/builds/809 blamelist: sonne@debian.org | 08:12 |
| -!- gsomix [~gsomix@188.168.5.30] has quit [Ping timeout: 244 seconds] | 08:18 | |
| -!- vikram360 [~vikram360@117.192.161.225] has joined #shogun | 08:24 | |
| -!- sonne|work [~sonnenbu@194.78.35.195] has joined #shogun | 08:51 | |
| sonne|work | wiking: btw you can of course use float based features w/ shogun pretty efficiently | 08:51 |
| -!- av3ngr [av3ngr@nat/redhat/x-csnenpsdsbtyljfc] has quit [Quit: That's all folks!] | 09:17 | |
| wiking | sonne|work: who said that not? | 09:59 |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 10:05 | |
| -!- vojtech [9320543b@gateway/web/freenode/ip.147.32.84.59] has joined #shogun | 10:07 | |
| sonne|work | vojtech: hi | 10:07 |
| sonne|work | I have a question about libqp ... | 10:07 |
| sonne|work | shouldn't we integrate pr_loqo into it? | 10:07 |
| sonne|work | and also liblinear's tron? | 10:08 |
| sonne|work | could uricamic do this? | 10:08 |
| -!- vikram360 [~vikram360@117.192.161.225] has quit [Ping timeout: 256 seconds] | 10:10 | |
| -!- vikram360 [~vikram360@117.192.190.128] has joined #shogun | 10:11 | |
| -!- Marty28 [~marty@cable-158-181-78-199.cust.telecolumbus.net] has joined #shogun | 10:13 | |
| vojtech | sonne: hi | 10:17 |
| vojtech | what is the point of integrating pr_loqo to libqp? | 10:18 |
| vojtech | I guess you already have pr_loqo in Shogun | 10:18 |
| vojtech | I don't know what is tron | 10:19 |
| vojtech | I want to say, integrating pr_loqo to libqp is good for libqp to become more comprehensive but the benefit for Shogun is not so big | 10:23 |
| sonne|work | vojtech: well it is | 10:24 |
| vojtech | to save time it may be more efficient to implement things which are not in none of the packages | 10:24 |
| sonne|work | we can have the very same interface for pr_loqo and other solvers | 10:24 |
| sonne|work | so one could choose in shogun which solver from libqp to choose | 10:24 |
| -!- Marty28 [~marty@cable-158-181-78-199.cust.telecolumbus.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] | 10:25 | |
| sonne|work | I mean with some standard interface it is easy | 10:25 |
| sonne|work | now it is not really nice due to a completely different interface | 10:25 |
| vojtech | I think the problem is that the user will need to decide which specific solver he/she wants anyway because each of the solver is design fo a specific QP problem | 10:25 |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 10:26 | |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 10:26 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 10:26 | |
| vojtech | ok, but to have a similar interface in all these solvers is reasonable | 10:26 |
| sonne|work | vojtech: yes but having a similar interface makes it easy to switch solvers | 10:27 |
| sonne|work | otherwise it is a lot of work | 10:27 |
| vojtech | ok, will look at pr_loqo and think if it is reasonable to integrate it and if yes me or Michal will do it | 10:30 |
| sonne|work | cool! | 10:30 |
| sonne|work | vojtech: ahh tron is this here http://shogun-toolbox.org/doc/en/current/Tron_8h_source.html - http://shogun-toolbox.org/doc/en/current/Tron_8cpp_source.html | 10:32 |
| sonne|work | they use it to solve L2 regularized L2 loss svm or L2R logist loss problems | 10:33 |
| sonne|work | it is based on truncated newton I think | 10:33 |
| sonne|work | so I think this could also be in libqp | 10:34 |
| vojtech | wait a second, it seems that TRON stands for trust region Newton method but this method is for minimization of a generic smooth functions, i.e. it is not Quadratic Programming | 10:36 |
| vojtech | am I right? | 10:36 |
| sonne|work | yes | 10:37 |
| sonne|work | but if you have an unconstrained qp problem - one could use it | 10:37 |
| sonne|work | with some smooth loss | 10:37 |
| sonne|work | finally there is one more solver in shogun which I think would be nice to have in libqp | 10:38 |
| sonne|work | the one in gpdtsolve.cpp | 10:39 |
| vojtech | hmm, but if libqp should be library for quadratic programming I'm not sure that integrating general problem solvers is a good idea. | 10:39 |
| vojtech | whta is gpdtsolve.cpp ? | 10:39 |
| sonne|work | vojtech: one could use it for qp problems with smooth loss function inside libqp | 10:40 |
| sonne|work | so it makes sense | 10:40 |
| sonne|work | of course it can do more but we would not provide more interfaces than that | 10:41 |
| sonne|work | GPDT - Gradient Projection Decomposition Technique | 10:41 |
| vojtech | aha, you mean to write an instance of TRON for optimizing QP | 10:41 |
| sonne|work | yes | 10:41 |
| vojtech | ok, this may be a good idea | 10:41 |
| sonne|work | gpdt is from here http://dm.unife.it/gpdt/ | 10:42 |
| sonne|work | and also in shogun | 10:42 |
| vojtech | I need to read about the algorithm to figure out if its is useful for unconstrained QP | 10:42 |
| sonne|work | it is used to solve subproblem of chunking svm training | 10:42 |
| sonne|work | so should be similar to pr loqo | 10:42 |
| sonne|work | in the way which problems it can solve | 10:42 |
| sonne|work | but I heard the talk from these guys and they claimed that it was a lot faster | 10:43 |
| sonne|work | it is from 2005 or so ... | 10:43 |
| sonne|work | in the file gpdtsolve.cpp | 10:43 |
| sonne|work | they have a class QPproblem | 10:43 |
| sonne|work | which you give alphas and stuff and then call problem.gpdtsolve() to get the solution | 10:44 |
| sonne|work | s/alphas/kernel | 10:44 |
| sonne|work | so that might also be a nice addition | 10:44 |
| sonne|work | vojtech: I am saying that because wiking and others all need qp solvers | 10:45 |
| sonne|work | and if we can come up with some nice class interface that itself can use libqp on the lower level things become a lot easier for everyone | 10:45 |
| vojtech | I'll put it to my todo list. | 10:45 |
| vojtech | but we need to decide priorities | 10:45 |
| sonne|work | and it is actually very cool to have | 10:46 |
| sonne|work | yes | 10:46 |
| wiking | eeey vojtech is here!!! | 10:46 |
| sonne|work | in any case this should not be too much work | 10:46 |
| sonne|work | maybe 1-2 weeks for all the solvers I mentioned | 10:46 |
| vojtech | I think Michal should first finish hist work on bundle methods | 10:46 |
| vojtech | in the remaining time he can work on libqp extension | 10:47 |
| vojtech | is it ok? | 10:47 |
| sonne|work | yes - but we will need to come up with some interface even for that | 10:47 |
| sonne|work | I mean there is fernando doing general SO problems | 10:48 |
| sonne|work | so defining a general framework where one can define the argmax function etc | 10:48 |
| sonne|work | so michaels bmrm should fit in there | 10:48 |
| sonne|work | so we have to communicate a bit | 10:48 |
| vojtech | I think the interface for SO and bundle method is more less clear | 10:49 |
| sonne|work | and I really hope we can continue with libqp afterwards | 10:49 |
| sonne|work | vojtech: did you discuss with nico goernitz (mentor for SO stuff - he is a PhD student in Klaus' group) about it? | 10:49 |
| vojtech | these methods need two functions, one evaluating the objective and one computing the subgradient | 10:50 |
| vojtech | I did not | 10:50 |
| sonne|work | not sure if michael / you will have time to continue after gsoc :) | 10:50 |
| vojtech | why not | 10:50 |
| sonne|work | maybe you should be in the loop then | 10:50 |
| sonne|work | basically fernando, nico, michael, you | 10:51 |
| vojtech | I'll be on holidays the next week. otherwise I'm online | 10:52 |
| sonne|work | ok | 10:52 |
| sonne|work | vojtech: alright nice talking to you | 10:55 |
| sonne|work | vojtech: ahh btw any news from ICML/ | 10:55 |
| sonne|work | ? | 10:55 |
| vojtech | yes, unfortunately bad news from ICML | 10:55 |
| vojtech | we overlooked one paper which does similar thing | 10:56 |
| vojtech | but this is life | 10:56 |
| sonne|work | which one? | 10:58 |
| vojtech | http://ai.stanford.edu/~chuongdo/papers/proximal.pdf | 10:59 |
| vojtech | in the mean time we discovered very nice method for SO | 11:00 |
| vojtech | as you know the current (cutting plane based) solvers require excessively long time if regularization goes to 0 | 11:01 |
| vojtech | the method we implemented does not have such problem at all | 11:01 |
| vojtech | you can easily train without regularization, which is sometimes very useful | 11:02 |
| sonne|work | wow | 11:02 |
| vojtech | the only shortcoming is that currently it works for problems with up to 1000-2000 paramaters | 11:02 |
| vojtech | but we work on removing the problem | 11:03 |
| sonne|work | hehe | 11:03 |
| vojtech | we already submitted a paper about this to ICPR | 11:03 |
| vojtech | I can send you a copy as the convergence figures are quite impresive | 11:04 |
| sonne|work | why not :) | 11:19 |
| -!- uricamic [~uricamic@2001:718:2:1634:f2de:f1ff:fecf:a6a5] has joined #shogun | 11:29 | |
| -!- vikram360 [~vikram360@117.192.190.128] has quit [Ping timeout: 246 seconds] | 12:03 | |
| -!- blackburn [5bdfb203@gateway/web/freenode/ip.91.223.178.3] has joined #shogun | 12:06 | |
| sonne|work | alright food time | 12:10 |
| blackburn | hey vojtech | 12:11 |
| -!- vojtech [9320543b@gateway/web/freenode/ip.147.32.84.59] has left #shogun [] | 12:14 | |
| blackburn | hehe | 12:15 |
| blackburn | https://lh3.googleusercontent.com/-IFLsH-qGV0s/T6GnqeE0P2I/AAAAAAAAGsg/inaAy0MVP5I/w497-h373/doorsign.jpg | 12:15 |
| sonne|work | heh | 13:10 |
| blackburn | sonne|work: about your recent commit | 13:16 |
| blackburn | so is there memory leaks now? | 13:16 |
| -!- eric___ [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has joined #shogun | 13:16 | |
| eric___ | hi all | 13:17 |
| blackburn | hi | 13:17 |
| -!- vikram360 [~vikram360@117.192.181.161] has joined #shogun | 13:18 | |
| eric___ | wiking: I am wondering if you have any crossvalidation cpp example using multiclass svm ? | 13:18 |
| wiking | eric___: we have a problem with that | 13:18 |
| wiking | or at least me for sure | 13:18 |
| wiking | i still need to debug it because i'm getting segfaults | 13:18 |
| eric___ | wiking: can I help ? | 13:19 |
| blackburn | wiking: what is this segfault in? | 13:19 |
| eric___ | wiking: other thg: For now we only have Confusion matrix to evalute classifier ? | 13:19 |
| eric___ | wiking: I mean multiclass kernel machine | 13:20 |
| blackburn | eric___: which evaluations do you need? | 13:20 |
| wiking | blackburn: heheh i'm running it from java so i really don't know now where does it segfaults | 13:20 |
| wiking | the only thing i see that the jvm crashed | 13:20 |
| wiking | *crashes | 13:20 |
| blackburn | wiking: blind search humm | 13:20 |
| wiking | blackburn: trying now with a small cpp example... | 13:20 |
| blackburn | python would work too | 13:20 |
| wiking | blackburn: yes true | 13:21 |
| wiking | eric___: you can have an accuracy + confusion matrix | 13:21 |
| wiking | but yeah i agree that we would need more | 13:21 |
| wiking | let me know your list of request | 13:21 |
| wiking | and then it can be included as part of an improvement of evaluation | 13:21 |
| eric___ | Roc Fmeasure would be nice | 13:22 |
| wiking | afaik there's such thing | 13:23 |
| blackburn | we have roc but multiclass..? | 13:23 |
| wiking | eric___: shogun/evaluation/ROCEvaluation.h | 13:23 |
| wiking | afaik a per class accuracy and Fmeasure would be great to have | 13:24 |
| wiking | s/afaik/imho/ | 13:24 |
| blackburn | right | 13:24 |
| blackburn | easy to do btw | 13:24 |
| wiking | blackburn: yeah i didn't say that it was rocket science ;) | 13:24 |
| eric___ | I meant automatic pairwise ROC (etc..) for multiclass | 13:24 |
| eric___ | blackburn: agree | 13:25 |
| blackburn | eric___: pairwise ROC? is it so easy to analyze it? | 13:25 |
| blackburn | one could die in hell of graphs :) | 13:25 |
| blackburn | wiking: they study rocket science in my university - sounds easy too :D | 13:26 |
| wiking | blackburn: i know that's why i told that ;) | 13:27 |
| eric___ | wiking: could you let me know your advancement, problems, with multiclass crossvalidation ? If you need help .. | 13:29 |
| wiking | eric___: hehehe yeah if u give me 2 hours i'll let u know | 13:30 |
| -!- vojtech [9320543b@gateway/web/freenode/ip.147.32.84.59] has joined #shogun | 13:30 | |
| eric___ | wiking: btw for your evaluation of latent svm on action recognition you may indicate me which database you need me to process | 13:31 |
| wiking | eric___: well i thought u have data :) | 13:31 |
| wiking | already | 13:31 |
| wiking | :> | 13:31 |
| blackburn | wiking: I lost you fMRI link :( | 13:31 |
| eric___ | I have some, but I focus for now on visual speech | 13:31 |
| wiking | eric___ hahahah last time you were checking video sequence, no? | 13:32 |
| wiking | blackburn: www.oasis-brains.org | 13:32 |
| blackburn | thanks | 13:32 |
| eric___ | yea film sequence of speaking people | 13:33 |
| eric___ | Hollywood database | 13:33 |
| wiking | aaaaha | 13:33 |
| wiking | and u wanna show who's speaking on the video stream? | 13:33 |
| blackburn | really? | 13:35 |
| eric___ | wiking: exactly | 13:35 |
| eric___ | wiking: I have also salsa dataabse : http://www.tsi.telecom-paristech.fr/mm/actualites/ | 13:36 |
| wiking | cool what are your features? | 13:36 |
| blackburn | damn is it feasible to solve? | 13:36 |
| wiking | i mean in case of the hollywood db | 13:36 |
| eric___ | I implemented histogram of oriented optical flow | 13:36 |
| eric___ | with some gradient information | 13:37 |
| blackburn | eric___: hmm thanks for idea - I'm working on road sign recognition and thought - why not to use flow here? ;) | 13:38 |
| eric___ | blackburn: np | 13:38 |
| eric___ | blackburn: but for what I have read, road sign recognition is more based on color and digits recognition (using ANN) ? | 13:39 |
| blackburn | eric___: I use svms | 13:39 |
| blackburn | and HOG | 13:39 |
| eric___ | blackburn: ok, but digits recognition should be a good way. | 13:40 |
| blackburn | it is my bachelor thesis actually :) | 13:40 |
| blackburn | eric___: too late to change paradigm for me | 13:40 |
| eric___ | blackburn: svm/hog were used for pedestrian detection, isnt it ? | 13:41 |
| eric___ | blackburn: dalal, triggs ? | 13:41 |
| blackburn | eric___: right | 13:41 |
| blackburn | eric___: works pretty well for signs too | 13:41 |
| blackburn | I have 97.5% accuracy on GTRSB | 13:41 |
| eric___ | blackburn: do you use opncv ? | 13:41 |
| blackburn | eric___: no only shogun and python clue code | 13:41 |
| eric___ | blackburn: GTRSB ? | 13:42 |
| blackburn | I still have some ideas to try like different color spaces | 13:42 |
| eric___ | blackburn: yes color is very important in this case | 13:42 |
| blackburn | eric___: GTSRB sorry | 13:43 |
| blackburn | http://benchmark.ini.rub.de/ | 13:43 |
| eric___ | blackburn: working on red channel could be nice, .. for europe :p | 13:43 |
| blackburn | eric___: no, Hue is prefferable there | 13:43 |
| blackburn | eric___: there are blue info signs as well | 13:46 |
| wiking | mmm we can parse libsvm files right? | 13:46 |
| eric___ | blackburn: thx for the database, I send it to a colleague which could be very interested | 13:47 |
| blackburn | eric___: how fast optical flow is being computed? | 13:49 |
| eric___ | its very slow usually, but for me in vga, using integral image and small region of interest (from facedetector), it run in realtime 40fps on corei5 | 13:50 |
| blackburn | oh that's bad | 13:51 |
| blackburn | eric___: I thought of implementing a detector based on flow but it would be hard I think | 13:51 |
| blackburn | color is important but I am still unsure it would work well | 13:52 |
| eric___ | blackburn: there are some ways to do faster, I didnt investigate this part too mauch, I only use farneback opencv implementation | 13:52 |
| eric___ | blackburn: a detector based only on flow ? | 13:56 |
| blackburn | eric___: yeah why not? | 13:57 |
| eric___ | blackburn: what are your training data ? | 13:57 |
| eric___ | blackburn: sequences ? | 13:57 |
| blackburn | eric___: I should think about it heh just some idea | 13:58 |
| blackburn | I mean road sign should be visible on flow | 13:58 |
| eric___ | blackburn: I thing there is somthg but more a way to make the road sign detection easier than to recognize a road sign | 13:59 |
| blackburn | it seems it is not that difficult to recognize it | 14:00 |
| eric___ | 97.5% accuracy is only for detection right ? | 14:04 |
| blackburn | eric___: no this dataset involves no detection | 14:05 |
| blackburn | recognition | 14:05 |
| eric___ | ok and you use multiclasssvm from shogun ? | 14:06 |
| blackburn | eric___: yes | 14:07 |
| eric___ | then you need multiclass crossvalidation from wiking too :p | 14:07 |
| eric___ | I ll be around, see you. | 14:07 |
| blackburn | eric___: I did some simple manual xval | 14:07 |
| blackburn | C is the only parameter I had to validate | 14:08 |
| eric___ | right | 14:08 |
| -!- PhilTillet [~Philippe@npasserelle10.minet.net] has joined #shogun | 14:16 | |
| -!- blackburn [5bdfb203@gateway/web/freenode/ip.91.223.178.3] has quit [Ping timeout: 245 seconds] | 14:37 | |
| -!- blackburn [5bdfb203@gateway/web/freenode/ip.91.223.178.3] has joined #shogun | 14:38 | |
| CIA-113 | shogun: Soeren Sonnenburg master * re2748d0 / (24 files in 7 dirs): | 14:40 |
| CIA-113 | shogun: remove most of the destroy/free_vector calls | 14:40 |
| CIA-113 | shogun: that should fix compilation - http://git.io/gUQW2g | 14:40 |
| shogun-buildbot | build #810 of libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/libshogun/builds/810 | 14:45 |
| sonne|work | at least something :) | 14:51 |
| eric___ | sonne|work: why remove most of the destroy/free_vector calls ? | 15:01 |
| sonne|work | eric___: when things will work again it will be sufficient to say SGVector a(len); | 15:08 |
| sonne|work | and a will be automagically cleaned up | 15:08 |
| sonne|work | so no longer a need for destroy/free* functions | 15:08 |
| sonne|work | in the same way one does not have to copy 'a' but just pass it around to other functions | 15:09 |
| sonne|work | (if one doesn't intend to modify the content of a in a non-compat way) | 15:09 |
| wiking | hahahah apparently i've done a course in "3D data in urban environments". how fucking good that course must have been | 15:09 |
| blackburn | wiking: what is this course about? | 15:13 |
| wiking | do i know? :D | 15:15 |
| blackburn | heh | 15:16 |
| sonne|work | blackburn, wiking - if anyone wants to start fixing sgvector double frees and leaks - feel free! | 15:44 |
| -!- cronor [~cronor@fb.ml.tu-berlin.de] has joined #shogun | 15:44 | |
| wiking | sonne|work: ok let's see the new commits with valgrind | 15:44 |
| sonne|work | wiking: for the current crashers I would assume gdb is good enough | 15:45 |
| -!- vikram360 [~vikram360@117.192.181.161] has quit [Ping timeout: 265 seconds] | 15:46 | |
| cronor | Hey, i tried shogun once class (LibSVMOneClass) and can't find any documentation. Are the output labels +1 for normal points and -1 for outliers? I assumed this and tried varying C from 10^-2 to 10^3 and can't see any difference in the results | 15:47 |
| eric___ | sonne|work: I would like gradually help/contribute to your lib, feel free to ask for help. I should have time for that this summer. | 15:59 |
| sonne|work | cronor: you get real valued outputs | 15:59 |
| sonne|work | eric___: what type of stuff is of interest to you ? | 16:00 |
| sonne|work | we need all help we can get :D | 16:00 |
| sonne|work | eric___: for example one relatively simple task is to add a couple of functions to SGVector, e.g. operator overloading to do a+b, a-b etc | 16:01 |
| blackburn | but please delegate it to CMath | 16:11 |
| blackburn | sonne|work: yeah I'll fix a bunch | 16:12 |
| sonne|work | blackburn: actually no - these functions should go away from CMath | 16:12 |
| blackburn | sonne|work: do you think so? | 16:12 |
| blackburn | I do not | 16:12 |
| sonne|work | I mean be moved to sgvectro | 16:12 |
| sonne|work | yes of course | 16:13 |
| blackburn | I have to disagree | 16:13 |
| -!- pluskid [~pluskid@li379-10.members.linode.com] has joined #shogun | 16:13 | |
| sonne|work | filling vectors, adding them belongs to vectors | 16:13 |
| blackburn | yes | 16:13 |
| sonne|work | not CMath | 16:13 |
| blackburn | but dot, +, matrix mult | 16:13 |
| blackburn | should be shared | 16:13 |
| sonne|work | yes in SGVector | 16:13 |
| sonne|work | the same function we had in CMath should be moved to sgvector | 16:13 |
| blackburn | I do not like it that much.. | 16:14 |
| blackburn | sonne|work: but what about lightweight vector? | 16:14 |
| blackburn | weren't you wishing to do that | 16:14 |
| sonne|work | much later | 16:15 |
| sonne|work | I dont' really understand why you want to keep that cluttered CMath cluttered... | 16:15 |
| blackburn | sonne|work: we should measure overhead | 16:15 |
| sonne|work | not yet | 16:15 |
| sonne|work | we first should get things working with all the stuff | 16:15 |
| blackburn | sonne|work: no I want to make that low level available | 16:15 |
| sonne|work | and not just SGVector but matrix, string, sparse, ... | 16:16 |
| sonne|work | blackburn: where? | 16:16 |
| blackburn | sonne|work: in some class like cmath | 16:16 |
| sonne|work | and for what purpose | 16:16 |
| sonne|work | but why? | 16:16 |
| blackburn | sonne|work: to do these operations w/o sgvectors | 16:16 |
| blackburn | one layer is pointers and another is sgvectors | 16:16 |
| sonne|work | blackburn: have a look at SGVector *now* | 16:17 |
| sonne|work | it has functions that will operate on double*, int | 16:17 |
| sonne|work | that is what I am talking about | 16:17 |
| blackburn | sonne|work: yes and it shouldn't be like that | 16:19 |
| sonne|work | why not? | 16:19 |
| blackburn | sonne|work: I see it as different layers.. | 16:20 |
| sonne|work | me too | 16:20 |
| sonne|work | but CMath is a mess | 16:20 |
| sonne|work | why not have all the max /min functions that operate on double* / int (so in fact vectors) in SGVector instead | 16:21 |
| blackburn | sonne|work: yes should be separated | 16:21 |
| sonne|work | just move I mean | 16:21 |
| sonne|work | no more | 16:21 |
| sonne|work | no overhead no nothing | 16:21 |
| blackburn | no SGVector should have only methods that do something on SGVectors | 16:21 |
| sonne|work | but much easier to understand / find the function | 16:21 |
| blackburn | it can be SGVectorDriver :D | 16:22 |
| sonne|work | why? | 16:22 |
| sonne|work | I don't understand why you would want a separate VectorMath class | 16:22 |
| blackburn | sonne|work: because I find strange that SGVector has any methods | 16:23 |
| blackburn | that do something on pointers | 16:23 |
| blackburn | I am ok to have any methods there | 16:23 |
| blackburn | that fill sgvector | 16:23 |
| sonne|work | blackburn: where would you put the vector related functions from CMath then? | 16:24 |
| blackburn | or anything | 16:24 |
| blackburn | sonne|work: just somewhere under SGVector | 16:24 |
| sonne|work | that is what I am saying | 16:24 |
| blackburn | sonne|work: not in CMath but some VectorMath class (no idea about naming) | 16:25 |
| sonne|work | ok I don't agree on that | 16:25 |
| blackburn | sonne|work: ok so you want to opearte on pointers | 16:25 |
| blackburn | why would you think about sgvector? | 16:26 |
| sonne|work | and I don't see any conflict / problem to have static functins in SGVector that work on standard ptrs | 16:26 |
| sonne|work | because I am dealing with vectors | 16:26 |
| blackburn | sonne|work: yes it can be true but I still have something I don't like there | 16:30 |
| blackburn | sonne|work: however it is not any impacting design decision | 16:30 |
| blackburn | can be changed at some point | 16:30 |
| -!- vikram360 [~vikram360@117.192.181.161] has joined #shogun | 16:40 | |
| -!- vojtech [9320543b@gateway/web/freenode/ip.147.32.84.59] has quit [Quit: Page closed] | 16:41 | |
| -!- PhilTillet [~Philippe@npasserelle10.minet.net] has quit [Remote host closed the connection] | 16:49 | |
| blackburn | sonne|work: I think we should measure how slower it is to compute kernel w/ refcounting | 16:50 |
| sonne|work | sure - feel free | 16:51 |
| blackburn | sonne|work: is it the main of possible bottlenecks? | 16:52 |
| blackburn | distances/kernel - what else? | 16:53 |
| sonne|work | feature vectors in general | 16:53 |
| blackburn | sonne|work: dotfeatures? | 16:54 |
| sonne|work | some yes | 16:55 |
| sonne|work | gtg | 16:55 |
| -!- blackburn [5bdfb203@gateway/web/freenode/ip.91.223.178.3] has quit [Quit: Page closed] | 16:56 | |
| eric___ | sonne|work: i am back, operator overloading (or..) is definitely not a problem for me. I egt into shogun since a couple weeks, so I will be able to fully understand the mechanism in a couple more weeks. I will fork shogun and let you know what can I do. | 17:00 |
| @sonney2k | eric___, we have lots of other unfinished stuff so feel free to propose sth :) | 17:11 |
| @sonney2k | pluskid, seeing how SGVector works now I start to like the idea of having automagic refcounting... | 17:12 |
| pluskid | sonney2k: haha! that's cool! | 17:13 |
| pluskid | sonney2k: but we should figure out whether this works with SWIG, which I'm not quite familiar with | 17:13 |
| @sonney2k | pluskid, yeah I guess it is too much too ask to do this before this GSoC so we can only start this in september or later... | 17:17 |
| pluskid | sonney2k: as a leader, you are right on this issue :D | 17:18 |
| pluskid | sonney2k: but otherwise, I personally like RAII (which is why auto-refcounting is implement-able) very much, and think it is one of the core feature of C++ over C/Java etc. http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization | 17:19 |
| @sonney2k | pluskid, haha | 17:19 |
| -!- uricamic [~uricamic@2001:718:2:1634:f2de:f1ff:fecf:a6a5] has quit [Quit: Leaving.] | 17:21 | |
| CIA-113 | shogun: Soeren Sonnenburg master * rf4d8694 / src/NEWS : move next release date to ~september'12 - http://git.io/m_CFYg | 17:26 |
| CIA-113 | shogun: Soeren Sonnenburg master * r1c8b9b0 / (21 files): Adjust static examples to not do SGVector refcounting. - http://git.io/muaIoQ | 17:26 |
| @sonney2k | I agree :) | 17:27 |
| @sonney2k | got to leave train | 17:28 |
| @sonney2k | anyone wishing to fix the new sgvector crashes - now would be a good time :) | 17:28 |
| -!- n4nd0 [~n4nd0@193.147.77.214] has joined #shogun | 17:42 | |
| n4nd0 | wiking, hey! | 17:43 |
| wiking | yoyo | 17:43 |
| wiking | who's the exams going? | 17:43 |
| n4nd0 | pse, so so | 17:43 |
| n4nd0 | still lot of work to do, but I hope it will be ok :) | 17:44 |
| n4nd0 | wiking, what about your papers, everything ok? | 17:44 |
| wiking | n4nd0: got it accepted | 17:44 |
| wiking | \o/ | 17:44 |
| n4nd0 | wow awesome, congrats! | 17:45 |
| n4nd0 | wiking, I see on the logs that you wanted to discuss something | 17:45 |
| wiking | thnx well it's about so fw but there' already an email about it | 17:46 |
| n4nd0 | ok | 17:46 |
| wiking | so it's ok we'll see where it brings us, and moreover work now on your exams ;) | 17:46 |
| n4nd0 | yes, but I enjoy taking rests and getting up to date with shogun too :) | 17:47 |
| wiking | :p procrastinator! | 17:49 |
| n4nd0 | :-O | 17:49 |
| -!- gsomix [~gsomix@188.168.2.163] has joined #shogun | 17:53 | |
| gsomix | hi all | 17:53 |
| gsomix | uff, I'm home | 17:53 |
| gsomix | *at :D | 17:54 |
| gsomix | sonney2k, sonne|work how are you? | 17:54 |
| -!- karlnapf [~heiko@host86-176-4-24.range86-176.btcentralplus.com] has joined #shogun | 18:06 | |
| -!- pluskid [~pluskid@li379-10.members.linode.com] has quit [Quit: Leaving] | 18:11 | |
| karlnapf | sonney2k, around? | 18:12 |
| karlnapf | or anybody else? | 18:12 |
| -!- blackburn [~qdrgsm@188.168.2.65] has joined #shogun | 18:12 | |
| wiking | yes | 18:13 |
| wiking | gsomix karlnapf sonney2k is on his way home... | 18:13 |
| karlnapf | wiking hi | 18:13 |
| wiking | hey hey | 18:13 |
| karlnapf | how is it going? :) | 18:14 |
| n4nd0 | hi! | 18:14 |
| karlnapf | n4nd0, hi, alright there? | 18:14 |
| wiking | uf busy busy | 18:15 |
| karlnapf | yeh same here | 18:15 |
| blackburn | hey there | 18:15 |
| blackburn | gsomix could you please proceed with sgvector fixes? | 18:15 |
| karlnapf | blackburn hi | 18:15 |
| blackburn | karlnapf: hey how are your exams? | 18:15 |
| karlnapf | hey blackburn, yes going along, just had one | 18:15 |
| karlnapf | now got 2/7 | 18:15 |
| blackburn | n4nd0: hey did you try to implement so labels? | 18:15 |
| blackburn | karlnapf: 7 exams? | 18:16 |
| blackburn | they must be crazy | 18:16 |
| blackburn | I had one today too | 18:16 |
| karlnapf | pretty much, yes :) | 18:16 |
| karlnapf | what did you have? | 18:16 |
| karlnapf | I just did supervised learning | 18:17 |
| blackburn | karlnapf: should sound like political science I think | 18:17 |
| blackburn | hah happy you study machine learning | 18:17 |
| karlnapf | and tuesway was probabilistic and unsupervised learning | 18:17 |
| karlnapf | yeh, pretty cool | 18:17 |
| karlnapf | had to derive some SVM related stuff today in the exam | 18:17 |
| blackburn | dual? | 18:17 |
| karlnapf | yes | 18:17 |
| blackburn | I should be able to pass that exam too ;) | 18:17 |
| karlnapf | wasnt too hard | 18:18 |
| karlnapf | however, unsupervised learning was hard | 18:18 |
| blackburn | I had problems with gradient of crammer-singer dual | 18:18 |
| karlnapf | whatever :D | 18:18 |
| blackburn | karlnapf: what is unsupervised course about? | 18:18 |
| karlnapf | coursely: PCA, PPCA&FA, EM in all its variants, time-series (HMM, SSM etc), graphical model and junction tree algo, bayesian modelselection and GP | 18:20 |
| blackburn | i am dim reduction expert :D | 18:20 |
| karlnapf | we mostly did Gaussian stuff | 18:20 |
| blackburn | huh crazy | 18:20 |
| blackburn | too much things | 18:20 |
| karlnapf | yes, this was an insane course | 18:20 |
| karlnapf | I also worked so many nights for the coursework back in december | 18:21 |
| blackburn | karlnapf: I am on the way to start writing thesis :D | 18:21 |
| karlnapf | these gatsby people want to defend their standards so they put up hard exams | 18:21 |
| karlnapf | wow, cool | 18:21 |
| karlnapf | whats the title? | 18:21 |
| blackburn | hmm | 18:21 |
| blackburn | let me recall | 18:21 |
| blackburn | "Development and analysis of road sign recognition algorithms based on support vector machines" | 18:22 |
| blackburn | sth like that | 18:22 |
| blackburn | it was translation | 18:22 |
| karlnapf | ah nice that thing | 18:22 |
| n4nd0 | blackburn, not yet | 18:22 |
| karlnapf | youre writing in Russian? | 18:23 |
| blackburn | in english I'd call it in other words | 18:23 |
| karlnapf | sad, I will never be able to reed it :) | 18:23 |
| blackburn | I am not able to write in english :( | 18:23 |
| blackburn | not because of my skills | 18:23 |
| n4nd0 | blackburn, I will see wait first what do we get in UML by next week as Nico suggested | 18:23 |
| karlnapf | blackburn, say I got a little problem and would like to have someones opinion | 18:23 |
| karlnapf | For my statistical tests I need to do bootstrapping | 18:24 |
| n4nd0 | gtg now guys | 18:24 |
| n4nd0 | see you later | 18:24 |
| blackburn | n4nd0: ok UML is nice | 18:24 |
| blackburn | see you | 18:24 |
| karlnapf | n4nd0 bye | 18:24 |
| karlnapf | which means mixing the two sets of samples and computing the statistics | 18:24 |
| blackburn | karlnapf: I never tried bootstrapping so far :( | 18:24 |
| blackburn | so? | 18:24 |
| -!- n4nd0 [~n4nd0@193.147.77.214] has quit [Quit: Ex-Chat] | 18:24 | |
| karlnapf | so I will need to merge two sets of features | 18:24 |
| blackburn | yeah | 18:24 |
| blackburn | I had similar problem at some point | 18:25 |
| karlnapf | I would like to treat them via a single feature interface | 18:25 |
| blackburn | hmmm I'd like to have a class | 18:25 |
| karlnapf | so I would like to create CFeatures(CFeatures*a, CFeautre*b) | 18:25 |
| karlnapf | but without copying the data | 18:25 |
| blackburn | karlnapf: can be more general | 18:25 |
| karlnapf | how would you do that? | 18:25 |
| blackburn | hmmm | 18:25 |
| blackburn | karlnapf: the problem is that we can't keep types here :( | 18:26 |
| karlnapf | year | 18:26 |
| blackburn | karlnapf: UnitedDotFeatures would work too I think | 18:26 |
| karlnapf | however, in my case, the types of the features WILL be the same | 18:26 |
| blackburn | yes but this united class | 18:27 |
| blackburn | what interface does it provide? | 18:27 |
| karlnapf | get_feature_vector is what I need | 18:27 |
| karlnapf | need to compute kernel values on them | 18:28 |
| blackburn | karlnapf: then dot features | 18:28 |
| blackburn | however get_feature_vector is absent | 18:28 |
| karlnapf | But how can they do this merging? | 18:28 |
| karlnapf | mmmh | 18:29 |
| blackburn | karlnapf: hmm just keep the list of underlying feature instances and override all dotfeatures operations | 18:29 |
| blackburn | karlnapf: should be pretty easy I think | 18:29 |
| blackburn | karlnapf: no forget not so easy | 18:30 |
| karlnapf | mmmh | 18:30 |
| blackburn | but feasible still | 18:30 |
| karlnapf | so you mean to implement a new class ? | 18:30 |
| karlnapf | did not really get you | 18:30 |
| blackburn | karlnapf: yes sure | 18:30 |
| karlnapf | But why base it on dot features, I would rather base it on CFeatures | 18:30 |
| blackburn | karlnapf: yes exactly what I was talking about | 18:31 |
| karlnapf | kk | 18:31 |
| blackburn | karlnapf: the problem is still here | 18:31 |
| blackburn | karlnapf: if you base it on cfeatures | 18:31 |
| blackburn | how can you use svm on top of it or anything? | 18:31 |
| karlnapf | yes, its not very flexible | 18:31 |
| karlnapf | One would need a united version of *every* feature class | 18:32 |
| blackburn | karlnapf: I think there is other way though | 18:32 |
| blackburn | karlnapf: UnionConverter? | 18:32 |
| karlnapf | like? | 18:32 |
| blackburn | inherited from converter | 18:32 |
| blackburn | returns CFeatures | 18:32 |
| blackburn | karlnapf: would need specialization here | 18:32 |
| karlnapf | Converter class has no documentation, I cannot see what it does ;) | 18:33 |
| blackburn | karlnapf: haha | 18:33 |
| blackburn | nothing | 18:33 |
| blackburn | just takes features | 18:33 |
| eric___ | wiking: I am going home, I will work on my datasets tonight, let me know about multiclass crossvalid plz ! cya | 18:33 |
| blackburn | and gives features | 18:33 |
| karlnapf | MMh I like the other variant more | 18:33 |
| blackburn | karlnapf: latter one? | 18:33 |
| karlnapf | UnionFeatures | 18:34 |
| karlnapf | and then derive it for every type when needed | 18:34 |
| karlnapf | I mean its just append features | 18:34 |
| blackburn | karlnapf: UnionConverter sounds better for me actually | 18:34 |
| karlnapf | but how do you want to do that, the interface only accepts one instance of CFeatures | 18:34 |
| blackburn | karlnapf: we can extend it ;) | 18:35 |
| karlnapf | still, when you want to merge features in-place, you will have to have another class that encapsulates multiple features | 18:35 |
| blackburn | karlnapf: ah in place sure.. | 18:36 |
| karlnapf | otherwise, I would just append the feature matrices, but i dont wanna do that | 18:36 |
| blackburn | karlnapf: UnitedDotFeatures then | 18:36 |
| karlnapf | kk | 18:36 |
| wiking | eric___: will u be around? | 18:36 |
| blackburn | no need to implement any other | 18:36 |
| karlnapf | yes, I will start with that one | 18:36 |
| blackburn | karlnapf: all the necessary API is provided with dot | 18:36 |
| wiking | eric___: tongiht? | 18:36 |
| karlnapf | however, any feature class that should be available for the MMD-tests will have to implement this | 18:37 |
| blackburn | karlnapf: why/ | 18:37 |
| karlnapf | string features for example | 18:37 |
| karlnapf | graph kernel possibly | 18:37 |
| karlnapf | all no dot-features | 18:37 |
| karlnapf | argh, get_feature_vector is an abstract method | 18:37 |
| karlnapf | I cannot call it from CUnionFeatures | 18:38 |
| blackburn | karlnapf: there is other method you can call | 18:38 |
| blackburn | get_computed_dot_feature_vector | 18:38 |
| blackburn | naming is awful! | 18:38 |
| blackburn | karlnapf: use it | 18:38 |
| blackburn | more general btw | 18:38 |
| blackburn | works for sparse as dense | 18:39 |
| karlnapf | mmh, but not for non-vector data | 18:39 |
| karlnapf | and that is one of the strengths of the kernel-two-sample-tests | 18:39 |
| blackburn | karlnapf: damn :( | 18:39 |
| karlnapf | I fear there will have to be a separate class for any feature class | 18:39 |
| blackburn | should be an elegant way.. | 18:40 |
| blackburn | yeah I don't like it | 18:40 |
| karlnapf | MMh, well I will try to put most of the stuff to a base class | 18:40 |
| blackburn | karlnapf: would be possible with multiple inheritance but you know | 18:40 |
| karlnapf | yeh, but thats nasty anyway, even if we would do it :) | 18:41 |
| blackburn | karlnapf: ok I have to go - I'll try to think about it | 18:41 |
| karlnapf | blackburn, ok, thanks for the chat :) | 18:41 |
| karlnapf | take care | 18:41 |
| blackburn | see you | 18:41 |
| karlnapf | Ill write to the list | 18:41 |
| blackburn | sure makes sense | 18:41 |
| @sonney2k | karlnapf, I dont' understand the problem | 19:20 |
| karlnapf | sonney2k, hi | 19:21 |
| karlnapf | well I have this method that computes something on the base of two feature objects | 19:21 |
| karlnapf | now I want to merge these two and permute and recompute | 19:21 |
| karlnapf | more like: merge, permute, split, recompute | 19:22 |
| karlnapf | and all that in-place | 19:23 |
| -!- cronor [~cronor@fb.ml.tu-berlin.de] has quit [Ping timeout: 246 seconds] | 19:23 | |
| @sonney2k | karlnapf, I assume this is for numerical features only? | 19:24 |
| karlnapf | no should work on all | 19:24 |
| karlnapf | also string | 19:24 |
| @sonney2k | so what you shuffle around are vectors not elements of vectors right? | 19:24 |
| karlnapf | yes | 19:25 |
| karlnapf | features | 19:25 |
| karlnapf | could be non-vectorfeatures | 19:25 |
| @sonney2k | and why do you need 2 separate feature objects for that? | 19:25 |
| @sonney2k | why isn't one sufficient? | 19:25 |
| @sonney2k | gsomix, hi - sgvector at least compiles now | 19:26 |
| @sonney2k | breakage all over the place though | 19:26 |
| karlnapf | well you got two sets of samples that you want to test whether they are from the same source | 19:26 |
| @sonney2k | karlnapf, btw sgvector sharing stuff should work now - except that lots of stuff needs fixes | 19:26 |
| karlnapf | its natural to have two feature objects for that | 19:26 |
| karlnapf | sonney2k, wow cool :) | 19:26 |
| @sonney2k | karlnapf, why not use combined features for that then? | 19:26 |
| @sonney2k | I mean you use 2 feature objects - put them into combined features and add a subset to that | 19:27 |
| @sonney2k | and voila | 19:27 |
| karlnapf | does that treat these 2 objects as one? for example the indices translate? | 19:28 |
| @sonney2k | no that is sth you would have to implement | 19:29 |
| karlnapf | you can only access complete feature objects | 19:29 |
| karlnapf | not the elements themselves | 19:29 |
| @sonney2k | yeah actually that doesn't make sense/work | 19:29 |
| @sonney2k | because you need access to the actual type | 19:30 |
| karlnapf | yes, thats the problem | 19:30 |
| karlnapf | I am currently thinking of just forcing a user to provide only 1 feature object where first half is one class and second half is the other | 19:30 |
| karlnapf | that would solve everything while being a bit unfriendly | 19:30 |
| @sonney2k | well you can add a convenience function for that... | 19:30 |
| karlnapf | But then the features would have to be copied | 19:31 |
| karlnapf | I want to stay in place | 19:31 |
| @sonney2k | karlnapf, for sparse/strings it would not matter | 19:31 |
| karlnapf | but for large matrices it would | 19:32 |
| @sonney2k | because you are just resizing one array and moving ptrs | 19:32 |
| @sonney2k | only for simplefeatures it would | 19:32 |
| karlnapf | The nicest thing would be to have a class that you can give multiple feature objects of the same type, and then this class would translate the get_feature_vector()-like method to the underlying list of feature objects | 19:32 |
| karlnapf | But its tricky | 19:33 |
| @sonney2k | but users are free to create the object in one go or use the convenience function | 19:33 |
| @sonney2k | karlnapf, yeah but that you would need to do type specific | 19:33 |
| @sonney2k | so for simple/sparse/string... | 19:33 |
| karlnapf | yes | 19:33 |
| karlnapf | so you are for copying, and if that doesnt fit, user can create feature object in one go? | 19:34 |
| karlnapf | aka convenience method or produce in one go | 19:34 |
| @sonney2k | the other alternative is to have a function in simple/sparse/string that gets as parameter the second feature object and a Subset | 19:34 |
| @sonney2k | and you do the access from there | 19:34 |
| @sonney2k | that would also be fast | 19:35 |
| karlnapf | oh yes, that sounds nice | 19:35 |
| karlnapf | like get_feature_vector(CFeatures* extension, CSubset* overall_subset, index_t idx) ? | 19:35 |
| @sonney2k | yes but probably a different function name | 19:36 |
| karlnapf | would only work for one additional feature object though | 19:36 |
| @sonney2k | maybe get_feature_vector_from_joint_features ;-) | 19:36 |
| karlnapf | lol :) the names are getting longer and longer here | 19:36 |
| @sonney2k | karlnapf, or you have a DynamicObjectArray there | 19:37 |
| @sonney2k | and make the function static | 19:37 |
| karlnapf | yes | 19:37 |
| karlnapf | however, then, on every access, all the lenths of the feature objects would have to be accessed, so its a bit slower | 19:37 |
| @sonney2k | karlnapf, well you could create a mapping table for that | 19:38 |
| @sonney2k | like for every index -> ptr to object & subindex | 19:38 |
| @sonney2k | but yes one more memory access | 19:38 |
| @sonney2k | or 2 even | 19:38 |
| karlnapf | mmh, do you think its worth the effort? I will only need two joint feature objects, but perhaps later seombody else will need that? | 19:39 |
| karlnapf | Also more complicated to call | 19:39 |
| @sonney2k | I also don't have a use case for that yet | 19:40 |
| @sonney2k | so IMHO simple things first | 19:40 |
| karlnapf | ok then I will stick with the two elements case and see what happens :) | 19:40 |
| @sonney2k | heh - I would do the same | 19:41 |
| karlnapf | sonney2k, just found another problem with this | 19:48 |
| karlnapf | I am interfacing the features via the kernel | 19:48 |
| karlnapf | kernel method of kernel | 19:48 |
| karlnapf | thats why I wanted to have a separate object, now I remember | 19:49 |
| karlnapf | So I think it will be copying in the con. method or creating one feature object for the user | 19:51 |
| -!- davePrime [40fb4a0c@gateway/web/freenode/ip.64.251.74.12] has joined #shogun | 20:13 | |
| @sonney2k | karlnapf, in this case really the only other alternative is to derive a class from each feature object and override the getter in there | 20:15 |
| @sonney2k | your uninon features won't work | 20:15 |
| karlnapf | sonney2k, yes I realised that | 20:15 |
| karlnapf | that would be too much work for this little problem in my eyes | 20:15 |
| karlnapf | I mean, not only overriding the getters | 20:15 |
| karlnapf | but also the results of some other methods would change | 20:16 |
| karlnapf | along with a huge amount of subclasses | 20:16 |
| karlnapf | I enforce this all features being in one object and then fiddle around with the indices in my test, that all works out of the box now | 20:16 |
| CIA-113 | shogun: Soeren Sonnenburg master * r2d8d9bc / (88 files in 13 dirs): remove SGVector& -> use SGVector instead - http://git.io/4nvrUA | 20:17 |
| @sonney2k | yeah. with helper functions this is actually not too bad | 20:21 |
| @sonney2k | heheh http://www.thenextgalaxy.com/ | 20:25 |
| karlnapf | machine learning takes over the world :) | 20:25 |
| -!- nickon [~noneedtok@d54C1F8A8.access.telenet.be] has joined #shogun | 20:25 | |
| karlnapf | oh this is in london :) | 20:27 |
| gsomix | receiving of data submodule is so slow... =___= | 20:42 |
| -!- davePrime [40fb4a0c@gateway/web/freenode/ip.64.251.74.12] has quit [Ping timeout: 245 seconds] | 20:51 | |
| @sonney2k | yeah its big | 20:51 |
| -!- eric___ [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has quit [Ping timeout: 245 seconds] | 20:51 | |
| blackburn | sonney2k: why did you do that ^ | 21:05 |
| shogun-buildbot | build #227 of nightly_all is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/227 | 21:05 |
| blackburn | karlnapf: what is difficult in tr? | 21:11 |
| karlnapf | blackburn, what? | 21:11 |
| blackburn | trace | 21:11 |
| karlnapf | nothing | 21:11 |
| karlnapf | just asking if somebody needs it | 21:11 |
| karlnapf | if yes i will do this now and the other person can use it | 21:11 |
| blackburn | karlnapf: I am confused if I understand it right :/ | 21:12 |
| karlnapf | I am just suggesting to add a method get_trace to kernel | 21:12 |
| blackburn | for(int i=0; i<N; i++) trace+=matrix[i*N+i]? | 21:12 |
| blackburn | ahh | 21:12 |
| blackburn | to kernel | 21:12 |
| blackburn | I see now | 21:13 |
| blackburn | karlnapf: is it only for square kernel matrices? | 21:14 |
| karlnapf | yes | 21:14 |
| @sonney2k | http://bits.blogs.nytimes.com/2012/05/03/microsoft-taps-yahoo-scientists-for-new-york-research-lab/?src=twrhp | 21:15 |
| blackburn | A*A makes sense too at some point | 21:15 |
| @sonney2k | there we have it | 21:15 |
| @sonney2k | JL is now at M$ | 21:15 |
| blackburn | sonney2k: phew | 21:15 |
| @sonney2k | blackburn, do what? | 21:15 |
| blackburn | sonney2k: removed const and & | 21:15 |
| @sonney2k | because it is no longer | 21:16 |
| @sonney2k | ref counts | 21:16 |
| blackburn | hmmmmm so does it refs on call? | 21:16 |
| blackburn | function call | 21:16 |
| @sonney2k | every time it is passed around yes | 21:16 |
| -!- davePrime [40fb4a0c@gateway/web/freenode/ip.64.251.74.12] has joined #shogun | 21:16 | |
| @sonney2k | (done in copy constructor) | 21:17 |
| blackburn | sonney2k: I did not expect it | 21:17 |
| blackburn | sounds cool | 21:17 |
| davePrime | . | 21:17 |
| blackburn | have to get to other thing again, see you | 21:17 |
| @sonney2k | ... | 21:18 |
| davePrime | If anyone has time to answer this beginner question, I'd appreciate it. The shogun website says that shogun "interfaces to Matlab(tm), R, Octave and Python", and the table says that "Language Bindings" are available in C# and Java. What's the difference between an "interface" and a "language binding" here? | 21:19 |
| davePrime | Feel free to ignore if you don't have time, but thanks for reading. | 21:19 |
| karlnapf | davePrime, hi | 21:22 |
| karlnapf | it all basically means that you can access shogun methods from any of these languages | 21:22 |
| karlnapf | and interface and language binding should be the same thing | 21:23 |
| karlnapf | what is it that you want to do? | 21:24 |
| davePrime | hi karlnapf. i want to write a java program that uses the shogun api for a classification problem | 21:27 |
| karlnapf | davePrime, that is possible, have a look at the examples to get started, try to run one of them would be the first step | 21:27 |
| karlnapf | if you have any problems, just ask here or the mailing list | 21:28 |
| karlnapf | if you are using automatic parameter selection, you should use the current git instead of the latest release (there is a bug) | 21:29 |
| @sonney2k | karlnapf, except that this week nothing will work on git master... | 21:30 |
| @sonney2k | sgvector transition | 21:30 |
| karlnapf | sonney2k, true, sorry | 21:30 |
| karlnapf | davePrime, so start with the latest release to get stuff working. then you might change later | 21:31 |
| davePrime | all right, thanks karlnapf, thanks for the info. i'm still not sure I get why the website is worded the way it is (for some reason, it greatly emphasizes the matlab, r, octave, and python interfaces), but i guess that doesn't really matter. again, thanks for the info. | 21:36 |
| karlnapf | davePrime, that is because the other interfaces are new and the website hasnt changed | 21:36 |
| karlnapf | python is the "main"-interface though, most complete in terms of examples | 21:37 |
| davePrime | makes sense. | 21:37 |
| karlnapf | however ,java should work | 21:37 |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 21:53 | |
| gsomix | sonney2k, CSet - done. | 21:54 |
| -!- nickon [~noneedtok@d54C1F8A8.access.telenet.be] has quit [Read error: Connection reset by peer] | 21:57 | |
| @sonney2k | gsomix, great | 22:02 |
| CIA-113 | shogun: Soeren Sonnenburg master * r786790d / (4 files in 3 dirs): overload assignment operator and add GC debug output for sgvector - http://git.io/PPQjzA | 22:02 |
| @sonney2k | gsomix, can I merge it already? | 22:02 |
| @sonney2k | gsomix, and btw how fast is it now? | 22:03 |
| @sonney2k | gsomix, I had some minor comments | 22:06 |
| gsomix | sonney2k, it's fast as standart hashmap. from O(1+a) to O(n) for insert | 22:16 |
| gsomix | sonney2k, there is some space for optimization, of course. but later, in spare time. | 22:17 |
| @sonney2k | gsomix, ok | 22:19 |
| @sonney2k | btw one thing | 22:19 |
| @sonney2k | it would be nice if we can serialize these things too | 22:19 |
| -!- davePrime [40fb4a0c@gateway/web/freenode/ip.64.251.74.12] has quit [Quit: Page closed] | 22:19 | |
| @sonney2k | for that to work everything must be of either some sgvector type or use SGObjects or int/float | 22:20 |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 22:20 | |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 22:20 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 22:20 | |
| -!- karlnapf [~heiko@host86-176-4-24.range86-176.btcentralplus.com] has quit [Ping timeout: 276 seconds] | 22:24 | |
| gsomix | sonney2k, hmm. It seems, that HashSetNode should be SG class, right? | 22:32 |
| @sonney2k | gsomix, what does it do? | 22:36 |
| @sonney2k | gsomix, anyway we can merge this first then you can improve... | 22:37 |
| @sonney2k | it is 1000x better than old CSet | 22:37 |
| -!- wiking [~wiking@huwico/staff/wiking] has quit [Quit: wiking] | 22:37 | |
| gsomix | sonney2k, okey. just last testes... | 22:40 |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 22:47 | |
| -!- wiking [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 22:47 | |
| -!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 22:47 | |
| gsomix | sonney2k, okay, you can merge it. | 23:01 |
| CIA-113 | shogun: Evgeniy Andreev master * r7c05227 / (3 files): CHashSet -> CSet - http://git.io/gWZqJw | 23:07 |
| CIA-113 | shogun: Evgeniy Andreev master * rb225c47 / (2 files in 2 dirs): fixes for transition - http://git.io/tJaS2g | 23:07 |
| CIA-113 | shogun: Evgeniy Andreev master * rf1050ea / examples/undocumented/libshogun/library_hashset.cpp : minor fixes - http://git.io/qb5PFg | 23:07 |
| CIA-113 | shogun: Evgeniy Andreev master * r84311ca / src/shogun/lib/Set.h : fixes in codestyle - http://git.io/spGLAw | 23:07 |
| CIA-113 | shogun: Soeren Sonnenburg master * r392ab41 / (5 files in 3 dirs): | 23:07 |
| CIA-113 | shogun: Merge pull request #495 from gsomix/CSet | 23:07 |
| CIA-113 | shogun: CHashSet -> CSet - http://git.io/k0aUFw | 23:07 |
| gsomix | sonney2k, thanks. | 23:08 |
| @sonney2k | gsomix, please think about serialization ... the other thing you could do is this Array -> Dynarray transition | 23:17 |
| * sonney2k goes to bed now | 23:18 | |
| @sonney2k | cu all | 23:18 |
| gsomix | sonney2k, aha. | 23:19 |
| gsomix | sonney2k, good night | 23:19 |
| gsomix | physics labs at 8am, oh | 23:32 |
| gsomix | good night | 23:33 |
| --- Log closed Fri May 04 00:00:37 2012 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!
