--- Log opened Thu Jun 06 00:00:33 2013 | ||
shogun-notifier- | shogun: Sergey Lisitsyn :feature/model_selection_syntax * f2209a5 / src/shogun/modelselection/ModelSelectionParameters.h: https://github.com/shogun-toolbox/shogun/commit/f2209a59e2cad391a427a503b9de04d04cb3e261 | 00:45 |
---|---|---|
shogun-notifier- | shogun: Added step support for range helper | 00:45 |
-!- lisitsyn [~blackburn@37.61.180.242] has left #shogun [] | 00:45 | |
-!- travis-ci [~travis-ci@ec2-50-17-124-118.compute-1.amazonaws.com] has joined #shogun | 01:08 | |
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/7823429 | 01:08 |
-!- travis-ci [~travis-ci@ec2-50-17-124-118.compute-1.amazonaws.com] has left #shogun [] | 01:08 | |
-!- nube [~rho@49.244.97.103] has joined #shogun | 03:15 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 03:45 | |
-!- nube [~rho@49.244.97.103] has quit [Quit: Leaving.] | 04:11 | |
-!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has quit [Ping timeout: 245 seconds] | 04:37 | |
-!- lambday [67157d36@gateway/web/cgi-irc/kiwiirc.com/ip.103.21.125.54] has joined #shogun | 05:38 | |
-!- nube [~rho@36.252.240.87] has joined #shogun | 05:44 | |
-!- nube [~rho@36.252.240.87] has quit [Read error: Connection reset by peer] | 05:52 | |
-!- nube [~rho@36.252.240.87] has joined #shogun | 05:53 | |
-!- nube [~rho@36.252.240.87] has quit [Ping timeout: 248 seconds] | 06:00 | |
lambday | sonney2k: sonne|work: good morning | 06:13 |
-!- nube [~rho@36.253.105.205] has joined #shogun | 06:16 | |
@sonney2k | lambday, moin! | 06:17 |
lambday | moin? :) | 06:17 |
@sonney2k | northern coast German for good morning | 06:18 |
lambday | :D | 06:18 |
lambday | and morgen? | 06:18 |
@sonney2k | yeah usually 'Guten Morgen!' | 06:19 |
@sonney2k | Gut == Good | 06:19 |
@sonney2k | Morgen == morning | 06:19 |
lambday | :) | 06:19 |
lambday | the only german I know is guten morgen and mein herz brennt (credit goes to rammstein) | 06:21 |
lambday | hope to learn some more very soon | 06:21 |
lambday | :) | 06:21 |
lambday | something is weird.. complex tests passed yesterday morning and failed in the evening! | 07:11 |
@sonney2k | lambday, lisitsyn fixed them on the buildbot by reducing accuracy | 07:27 |
@sonney2k | gtg | 07:27 |
@sonney2k | brb | 07:27 |
lambday | sonney2k: okay.. ciao | 07:27 |
lambday | ya I saw that.. but am just wondering what might cause this | 07:27 |
-!- foulwall [~foulwall@2001:da8:215:503:a97a:6257:9fe3:8dd7] has joined #shogun | 08:06 | |
-!- iglesiasg [d58f3246@gateway/web/freenode/ip.213.143.50.70] has joined #shogun | 08:12 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 08:14 | |
-!- nube [~rho@36.253.105.205] has quit [Quit: Leaving.] | 08:16 | |
-!- nube [~rho@36.253.105.205] has joined #shogun | 08:16 | |
@sonney2k | lambday, I *think* that fabs is somehow computed differently on this machine and that std is just having the same issues due to using fabs like CMath::abs | 08:27 |
@sonney2k | anyways | 08:27 |
@sonney2k | lets move on | 08:27 |
* sonney2k looks into sparse matrix hell | 08:27 | |
lambday | ya.. moving on | 08:28 |
-!- nube [~rho@36.253.105.205] has quit [Ping timeout: 256 seconds] | 08:43 | |
gsomix | good morning | 08:44 |
-!- nube [~rho@116.90.228.137] has joined #shogun | 08:53 | |
@iglesiasg | lambday: I am taking a look to your PR | 09:04 |
lambday | iglesiasg: okay :) | 09:10 |
@iglesiasg | lambday: just check a moment the thing of the naming for one of the tests | 09:11 |
lambday | iglesiasg: checking.. | 09:11 |
lambday | iglesiasg: you're right.. there is no reason! I should better just name them compare_ptype_null3, compare_ptype_null4 | 09:12 |
lambday | changing | 09:12 |
@iglesiasg | lambday: mmm but in that one you are not comparing it with null, are you? | 09:13 |
lambday | iglesiasg: in the second case COMPLEX64 is fine I think | 09:14 |
lambday | I'm talking about the case where I'm comparing it with null | 09:14 |
lambday | iglesiasg: for the second one (where I check with another complex param), I followed the same format as of others (in caps) | 09:17 |
lambday | made changes for the other one | 09:17 |
@iglesiasg | lambday: all right | 09:17 |
lambday | please check | 09:17 |
@iglesiasg | lambday: ok, nicely done! | 09:18 |
-!- foulwall [~foulwall@2001:da8:215:503:a97a:6257:9fe3:8dd7] has quit [Remote host closed the connection] | 09:18 | |
lambday | iglesiasg: thanks :) | 09:18 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 09:27 | |
shogun-notifier- | shogun: lambday :develop * 43c4b4e / tests/unit/base/Parameter_unittest.cc,tests/unit/mathematics/Math_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/43c4b4e94fb392a290e8784379e0e9eb6fc9415e | 09:27 |
shogun-notifier- | shogun: complex64_t unit-tests added for TParameter | 09:27 |
shogun-notifier- | shogun: Fernando Iglesias :develop * 44c8ae8 / tests/unit/base/Parameter_unittest.cc,tests/unit/mathematics/Math_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/44c8ae8e63b218919cec4167419c2a799272cc8b | 09:27 |
shogun-notifier- | shogun: Merge pull request #1151 from lambday/develop | 09:27 |
shogun-notifier- | shogun: | 09:27 |
shogun-notifier- | shogun: complex64_t unit-tests added for TParameter | 09:27 |
shogun-buildbot | build #912 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/912 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 09:38 |
shogun-buildbot | build #913 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/913 blamelist: lambday <heavensdevil6909@gmail.com> | 09:53 |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 09:58 | |
-!- mode/#shogun [+o lisitsyn] by ChanServ | 09:58 | |
-!- iglesiasg [d58f3246@gateway/web/freenode/ip.213.143.50.70] has quit [Quit: Page closed] | 10:06 | |
-!- 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] | 10:15 | |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 10:36 | |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has joined #shogun | 11:31 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 11:33 | |
thoralf | Hmm, something goes wrong in SVMlight classifier: "Number of SV: 19772 (including 140432545692465 at upper bound)" | 11:44 |
@lisitsyn | thoralf: oh sounds like quite a lot support vectors haha :) | 11:46 |
@iglesiasg | haha | 11:46 |
@iglesiasg | large-scale toolbox -- what did you expect? :P | 11:47 |
thoralf | iglesiasg: I'd expect far less SVs than examples. ;) | 11:48 |
@iglesiasg | thoralf: you've got a point in there :) | 11:48 |
thoralf | SG_INFO("Number of SV: %ld (including %ld at upper bound)\n", model->sv_num-1,upsupvecnum); | 11:49 |
thoralf | int32_t upsupvecnum | 11:49 |
@iglesiasg | the ld must be | 11:49 |
@iglesiasg | could you try just with %d? | 11:50 |
thoralf | iglesiasg: I will. ;) | 11:50 |
thoralf | 140432545692465 >> max of int32_t ;) | 11:50 |
thoralf | So it must be some conversion issue. | 11:50 |
@iglesiasg | indeed | 11:50 |
-!- nube [~rho@116.90.228.137] has quit [Ping timeout: 256 seconds] | 12:03 | |
-!- nube [~rho@116.90.228.137] has joined #shogun | 12:07 | |
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 12:27 | |
wiking | is this maybe fixed by some of the latest changes of combined kernel: https://github.com/shogun-toolbox/shogun/issues/926 | 12:33 |
wiking | meaning anybody ran valgrind lately on the unit tests? :) | 12:33 |
thoralf | iglesiasg: Seems to work "Number of SV: 19772 (including 15153 at upper bound)" | 12:59 |
thoralf | :) | 12:59 |
@iglesiasg | thoralf: nice! | 12:59 |
@iglesiasg | thoralf: by the way is the other variable, model->sv_num a int64_t? | 12:59 |
@iglesiasg | thoralf: otherwise, I guess the same error could arise | 12:59 |
-!- HeikoS [~heiko@nat-189-255.internal.eduroam.ucl.ac.uk] has joined #shogun | 13:00 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 13:00 | |
thoralf | iglesiasg: I fixed it for both variables. | 13:00 |
@iglesiasg | thoralf: thanks, could you please issue a PR with that? | 13:00 |
thoralf | iglesiasg: (and even in another source file - thanks to code duplication) | 13:00 |
thoralf | iglesiasg: Already preparing. | 13:00 |
@iglesiasg | thoralf: haha yeah copy+paste is both dangerous and comfortable | 13:00 |
thoralf | iglesiasg: It's only comfortable to the one who did it... ;) | 13:01 |
@iglesiasg | very true | 13:01 |
thoralf | iglesiasg: But it's so much pain afterwards... | 13:01 |
thoralf | iglesiasg: In case you're feeling responsible: https://github.com/shogun-toolbox/shogun/pull/1152 | 13:08 |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 13:10 | |
shogun-notifier- | shogun: Thoralf Klein :develop * f8e2d67 / src/shogun/classifier/svm/SVMLight.cpp,src/shogun/regression/svr/SVRLight.cpp: https://github.com/shogun-toolbox/shogun/commit/f8e2d67d75ab2d727dce65da2676a288c679f6cf | 13:10 |
shogun-notifier- | shogun: SVMLight: Fixing type conversion when printing number of support vectors (%d instead of %ld, because variable is of type int32_t). | 13:10 |
shogun-notifier- | shogun: Fernando Iglesias :develop * dd60047 / src/shogun/classifier/svm/SVMLight.cpp,src/shogun/regression/svr/SVRLight.cpp: https://github.com/shogun-toolbox/shogun/commit/dd600474fb8c113852fa2995080e3a2c510596ec | 13:10 |
shogun-notifier- | shogun: Merge pull request #1152 from tklein23/develop | 13:10 |
shogun-notifier- | shogun: | 13:10 |
shogun-notifier- | shogun: SVMLight: Fixing type conversion when printing number of support vectors. | 13:10 |
@iglesiasg | thoralf: btw, are you using Shogun for something on your work or just contributing? | 13:10 |
thoralf | iglesiasg: I'm using shogun for my research, but until now I'm pushing shogun to work as expected. | 13:12 |
thoralf | iglesiasg: (large scale) text classification, hashing, mkl | 13:13 |
thoralf | large scale not only meaning lots of examples, but also lots of classes | 13:13 |
@iglesiasg | thoralf: aham I see | 13:15 |
@iglesiasg | thoralf: you have probably seen we have something in ECOC | 13:15 |
thoralf | ecoc? | 13:15 |
@iglesiasg | I believe that is used in classification with many classes | 13:15 |
@iglesiasg | error correcting output codes IIRC | 13:15 |
@iglesiasg | there was a project last summer's GSoC in multiclass classification | 13:16 |
@iglesiasg | some methods for this were implemented, and I think some of them are well suited to classification with lot of classes | 13:16 |
shogun-buildbot | build #914 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/914 blamelist: Thoralf Klein <thoralf.klein@zib.de> | 13:17 |
@iglesiasg | thoralf: I meant this project http://shogun-toolbox.org/page/Events/gsoc2012_ideas#multiclass | 13:17 |
thoralf | iglesiasg: Thanks, I will check it. | 13:19 |
-!- nube [~rho@116.90.228.137] has quit [Quit: Leaving.] | 13:23 | |
thoralf | Can anyone recommend, which environment to use for building shogun applications or contributing to shogun? | 13:31 |
@HeikoS | thoralf: I use eclipse | 13:31 |
thoralf | In emacs I'm missing auto completion of class methods :) | 13:31 |
@HeikoS | which is a bit of a pain to set up | 13:31 |
@HeikoS | but once it works, its very nice | 13:31 |
@HeikoS | thoralf: all you do is import existing makefile project (src folder of shogun) | 13:32 |
thoralf | HeikoS: Thanks. Are they other IDEs you tried, but failed? ;) | 13:32 |
@HeikoS | and then create another project for your application, which links against the shogun one | 13:32 |
@HeikoS | you can even add valrind support to eclipse | 13:32 |
@HeikoS | thoralf: I used plain text editors before | 13:32 |
@HeikoS | gedit/vim/emacs | 13:32 |
@lisitsyn | I use vim + clang_complete for autocompletion | 13:33 |
@HeikoS | eclipse is very nice if your computer is reasonbly modern | 13:33 |
@lisitsyn | pretty powerful | 13:33 |
@HeikoS | in eclipse you have this very nice feature that you can press ctrl-shift-r and then just enter a class name and then it magically opens the files for you | 13:33 |
thoralf | HeikoS: Anything I need for eclipse is a big screen ;) | 13:34 |
@HeikoS | yes :) | 13:34 |
thoralf | HeikoS: Okay, I'll give it a try. | 13:34 |
shogun-buildbot | build #915 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/915 blamelist: Fernando Iglesias <fernando.iglesiasg@gmail.com> | 13:38 |
-!- sonney2k [~shogun@7nn.de] has quit [Ping timeout: 264 seconds] | 13:47 | |
-!- sonney2k [~shogun@7nn.de] has joined #shogun | 13:49 | |
@iglesiasg | HeikoS: I think I will try eclipse some time for fun | 14:07 |
@iglesiasg | I like it when I use java | 14:07 |
@HeikoS | iglesiasg: what do you use? | 14:07 |
@iglesiasg | HeikoS: terminal and vim | 14:07 |
@HeikoS | eclipse is also nice for python development | 14:07 |
@iglesiasg | true | 14:08 |
thoralf | I think this could be a good topic for the workshop in July. | 14:08 |
@HeikoS | and it has a git integration | 14:08 |
@HeikoS | and valgrind also | 14:08 |
@iglesiasg | I did that too a few years ago | 14:08 |
@iglesiasg | thoralf: good idea | 14:08 |
@HeikoS | thoralf: good idea, but not many votes on that | 14:08 |
thoralf | Having tools/workflows/configs to support you when developing. | 14:08 |
@HeikoS | thoralf: we really need a tutorial on how to set up shogun on the website, want to write one? :) | 14:08 |
thoralf | HeikoS: Yes and no. ;) | 14:08 |
@HeikoS | haha :) | 14:08 |
@HeikoS | I know takes ages | 14:09 |
@HeikoS | but we desperately need this | 14:09 |
@HeikoS | I am currently getting a few people around UCL in London involved | 14:09 |
@HeikoS | and most time is spent on setting it up | 14:09 |
@HeikoS | which is very frustrating | 14:09 |
@iglesiasg | ok guys, I will be back after lunch | 14:10 |
@HeikoS | enjoy! | 14:10 |
@iglesiasg | thanks! | 14:10 |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has quit [Quit: Page closed] | 14:10 | |
thoralf | HeikoS: I think this fix is a good start ;) https://github.com/shogun-toolbox/shogun/pull/1154 | 14:12 |
thoralf | HeikoS: Since it's something I did wrong (while following the official documentation) | 14:12 |
shogun-notifier- | shogun: Thoralf Klein :develop * 0fb4348 / src/README.developer: https://github.com/shogun-toolbox/shogun/commit/0fb43481b07b64b79763966406dcf53d104cc570 | 14:13 |
shogun-notifier- | shogun: README.developer: Updated the git instructions for committing patches to upstream. | 14:13 |
@HeikoS | yep, thanks! :) | 14:13 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 81dd25b / src/README.developer: https://github.com/shogun-toolbox/shogun/commit/81dd25b23c42f7ba2133d65930f7311dfc0b6eeb | 14:13 |
shogun-notifier- | shogun: Merge pull request #1154 from tklein23/develop | 14:13 |
shogun-notifier- | shogun: | 14:13 |
shogun-notifier- | shogun: README.developer: Updated the git instructions for committing patches to upstream | 14:13 |
thoralf | Hope I didn't make it worse, but I think it's okay. | 14:13 |
@HeikoS | I think its fine | 14:15 |
@HeikoS | thoralf: but seriously, if you are going into the effort of making eclipse work, it would be great to have a tutorial on this | 14:16 |
shogun-buildbot | build #916 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/916 blamelist: Thoralf Klein <thoralf.klein@zib.de> | 14:17 |
@HeikoS | noooooo | 14:17 |
shogun-buildbot | build #917 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/917 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 14:18 |
thoralf | HeikoS: Only if eclipse saves me as much time as I need for writing a tutorial. ;) | 14:21 |
@HeikoS | thoralf: deal :) | 14:21 |
thoralf | HeikoS: In eclipse, did you select a particular "Toolchain for indexer settings"? | 14:24 |
@HeikoS | autotools | 14:24 |
sonne|work | thoralf: hey I am interested in switching to eclipse too btw :D | 14:24 |
@HeikoS | and gcc/g++ | 14:24 |
@HeikoS | maybe we can even add the config to git? | 14:27 |
@lisitsyn | we already have it | 14:27 |
@HeikoS | lisitsyn: does it work? never tried? | 14:27 |
@lisitsyn | no idea | 14:27 |
@lisitsyn | :) | 14:27 |
thoralf | I already converted two projects for using IDE-assisted-development - and it's been the best decision I ever had. | 14:27 |
sonne|work | HeikoS: well I used it | 14:27 |
@HeikoS | thoralf: nice! | 14:28 |
@HeikoS | sonne|work: cool, maybe Ill give it a go later | 14:28 |
thoralf | sonne|work: I didn't expect you not to use an IDE. ;) | 14:28 |
@HeikoS | sonne|work: have you seen my mail? | 14:28 |
sonne|work | thoralf: you are talking to a vim person | 14:28 |
sonne|work | HeikoS: no | 14:28 |
sonne|work | what mail? | 14:28 |
@HeikoS | workshop topics to shogun-list | 14:29 |
sonne|work | ahh seen it | 14:29 |
sonne|work | so fernando would do SO? | 14:29 |
sonne|work | HeikoS: you GPs | 14:29 |
@HeikoS | lisitsyn: which class does plain lasso? | 14:29 |
sonne|work | and lisitsyn dimred? | 14:29 |
@HeikoS | yes I can do GPs | 14:29 |
@HeikoS | and maybe MMD stuff | 14:30 |
@HeikoS | sonne|work: you mkl and svms? | 14:30 |
@lisitsyn | HeikoS: plain like? | 14:32 |
@lisitsyn | sonne|work: yes I don't mind | 14:32 |
@HeikoS | ||y- X\beta|| + \lambda|\beta|_1 | 14:32 |
@lisitsyn | HeikoS: least angle regression | 14:33 |
@lisitsyn | somewhat like that in regression | 14:33 |
@HeikoS | ok | 14:33 |
@HeikoS | did you ever test/use it? | 14:33 |
sonne|work | HeikoS: ok | 14:33 |
@lisitsyn | HeikoS: yes it works, we have a graphical example | 14:33 |
@HeikoS | cool | 14:33 |
@HeikoS | thanks | 14:33 |
@lisitsyn | and it is written by chiyuan | 14:33 |
@lisitsyn | that MIT guy | 14:33 |
@lisitsyn | he knows a way around heh :) | 14:33 |
@lisitsyn | HeikoS: we actually have an example for my group lasso too | 14:34 |
-!- nube [~rho@116.90.228.137] has joined #shogun | 14:34 | |
@lisitsyn | and it seems it is ok | 14:34 |
@lisitsyn | but not for the multiclass one | 14:34 |
@HeikoS | lisitsyn: thats fine for now | 14:34 |
@lisitsyn | anyway again - I tested it and it was not bad | 14:34 |
@HeikoS | I will just use regression and see | 14:34 |
@lisitsyn | like 92% accuracy | 14:35 |
@HeikoS | so it does better than lars? | 14:35 |
@HeikoS | thats cool | 14:35 |
@lisitsyn | HeikoS: hmm what does better than lars? | 14:35 |
@HeikoS | maybe I misunderstood the plots | 14:35 |
@HeikoS | checking the code | 14:35 |
@HeikoS | lisitsyn, sonne|work should we have a list with people who do talks? | 14:35 |
@lisitsyn | HeikoS: lasso may be worse than least squares | 14:36 |
-!- nube [~rho@116.90.228.137] has quit [Quit: Leaving.] | 14:40 | |
sonne|work | HeikoS: yes we should and make a plan | 14:40 |
@HeikoS | how many speakers? | 14:40 |
@HeikoS | sergey, you, me, fernando, gunnar, who else? | 14:41 |
@HeikoS | lisitsyn: argh, lasso segfaults | 14:51 |
@lisitsyn | HeikoS: lars? | 14:53 |
@HeikoS | yes | 14:53 |
@lisitsyn | surprising | 14:53 |
@HeikoS | I am not really surprised | 14:53 |
@lisitsyn | HeikoS: sorry my ass is on fire, can get to that tonight | 14:53 |
@HeikoS | lisitsyn: dont worry :) | 14:53 |
@HeikoS | will investigate myself | 14:53 |
@HeikoS | good luck with fighting the fire! | 14:53 |
@lisitsyn | HeikoS: we made some progress on the algorithm but have to update some 'business logic' :D | 14:54 |
@HeikoS | man this is annoying, how should we expect people to use our software if everything crashes whenever you touch it | 14:54 |
@HeikoS | haha :) | 14:54 |
@HeikoS | we have to do it differently this gsoc | 14:55 |
@HeikoS | waterproof code | 14:55 |
@HeikoS | switching to scikit learn now :( | 14:55 |
@lisitsyn | HeikoS: we can't avoid bugs :) | 14:55 |
@HeikoS | I know, but there are too many | 14:55 |
@HeikoS | we can definitely avoid that | 14:56 |
@lisitsyn | that's the drawback of using low-level C++ | 14:56 |
@lisitsyn | the less code we have the less bugs we have | 14:56 |
@HeikoS | no its not c++, its our development model | 14:56 |
@lisitsyn | that's the only way to avoid bugs | 14:56 |
@HeikoS | we dont ensure quality | 14:56 |
@lisitsyn | HeikoS: # of bugs per line is constant anyway | 14:56 |
@HeikoS | at least we did not last year | 14:56 |
@lisitsyn | no matter how you cover it with tests | 14:56 |
@HeikoS | I am very sure this segfault is again a very simple thing that would have been easily catched | 14:57 |
-!- gsomix [~Miranda@37.61.180.242] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] | 14:57 | |
@HeikoS | but now someone needs to invest a few hours | 14:57 |
@HeikoS | lisitsyn: I know | 14:57 |
@lisitsyn | HeikoS: yes - don't use pointers | 14:57 |
@lisitsyn | :) | 14:57 |
@HeikoS | but still, we should really take more care | 14:57 |
@HeikoS | when merging code | 14:57 |
@HeikoS | make the developers test it more and stuff | 14:57 |
@HeikoS | but same discussion has already been done | 14:57 |
@HeikoS | so lets not get into that | 14:58 |
@lisitsyn | HeikoS: all segfaults happen due to pointers - you won't see any segfault with eigen :) | 15:06 |
@lisitsyn | so it is important too | 15:06 |
@HeikoS | lisitsyn: I dont agree to blame pointers nor c++ for that | 15:06 |
@HeikoS | this is due to no testing the code | 15:07 |
@HeikoS | I mean come on, I just call a method on some data | 15:07 |
@HeikoS | nothing fancy | 15:07 |
@HeikoS | no complicated framework structure | 15:07 |
@lisitsyn | HeikoS: we won't cover all the code with tests though | 15:08 |
@HeikoS | lisitsyn: I know, thats not my point | 15:08 |
@HeikoS | we dont have to | 15:08 |
@HeikoS | however, this one crashes on the most simple case | 15:08 |
@HeikoS | this jsut should not happen | 15:08 |
@HeikoS | this means, it was never tried on a dataset | 15:09 |
@HeikoS | because otherwise we would have noticed this error | 15:09 |
@lisitsyn | HeikoS: hm we have an example | 15:09 |
@HeikoS | thats toy data | 15:09 |
@HeikoS | and very very small | 15:09 |
@lisitsyn | does it crash? | 15:09 |
@HeikoS | no | 15:09 |
-!- shogun-notifier- [~irker@7nn.de] has quit [Ping timeout: 264 seconds] | 15:10 | |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 264 seconds] | 15:10 | |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has joined #shogun | 15:10 | |
-!- naywhayare [~ryan@spoon.lugatgt.org] has quit [Ping timeout: 264 seconds] | 15:11 | |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has joined #shogun | 15:15 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 15:15 | |
@iglesiasg | HeikoS, lisitsyn : we didn't need to register for the workshop, did we? | 15:16 |
@iglesiasg | I think I asked soeren about that once | 15:16 |
@HeikoS | iglesiasg: you should, then you can vote on the topics :) | 15:16 |
@HeikoS | all others did too | 15:16 |
@iglesiasg | HeikoS: true | 15:16 |
@iglesiasg | then I am going to right now | 15:16 |
sonne|work | iglesiasg: yes you should | 15:17 |
-!- naywhayare [~ryan@spoon.lugatgt.org] has joined #shogun | 15:17 | |
@iglesiasg | sonne|work: thanks, I probably imagined asking :D | 15:17 |
@lisitsyn | HeikoS: I think no that's what I mean ;) | 15:17 |
@lisitsyn | anyway, what crashes? | 15:17 |
-!- lisitsyn1 [~lisitsin@mxs.kg.ru] has joined #shogun | 15:17 | |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Write error: Connection reset by peer] | 15:18 | |
@iglesiasg | registered | 15:20 |
thoralf | HeikoS: How did you integrate the unit tests? As a own project? | 15:47 |
-!- Yanglittle [deb20afd@gateway/web/freenode/ip.222.178.10.253] has joined #shogun | 16:01 | |
Yanglittle | Hey is there any body , it's strange that i run chi2kernel(data,data,width,20), but it returns an empty array, here data is a realfeatures object | 16:04 |
Yanglittle | yesterday it runs well.. | 16:04 |
-!- Yanglittle_ [deb20afd@gateway/web/freenode/ip.222.178.10.253] has joined #shogun | 16:07 | |
sonne|work | Yanglittle errm I don't recall anyone doing any changes | 16:09 |
-!- Yanglittle [deb20afd@gateway/web/freenode/ip.222.178.10.253] has quit [Ping timeout: 250 seconds] | 16:09 | |
Yanglittle_ | so strange... i did nothing. reinstall it? | 16:10 |
sonne|work | well what is the size of data? | 16:12 |
thoralf | sonne|work: About the pthreads problem again - what about adding LINKFLAGS="$LINKFLAGS $pthr" in src/configure, line 3225? | 16:12 |
sonne|work | Yanglittle_: data.get_num_vectors() | 16:12 |
thoralf | sonne|work: LINKFLAGS will be passed through... | 16:13 |
sonne|work | thoralf: ohh postlinkflags is not! good catch | 16:13 |
sonne|work | we should just pass POSTLINKFLAGS through then | 16:14 |
Yanglittle_ | it returns 0, but the data is made by Realfeatures(data), the original data is a array with 2000*576 | 16:16 |
wiking | ok i'm putting up some leak report | 16:17 |
wiking | 1155, 1156 and 1157 | 16:21 |
wiking | HeikoS: 1156 | 16:21 |
wiking | and 1157 is for GaussianLikelihood and StudentsTLikelihood so i guess somebody working on them now in gsoc can fix it :P | 16:22 |
sonne|work | Yanglittle_: which language is that? | 16:34 |
Yanglittle_ | python | 16:34 |
sonne|work | HeikoS: well we changed our development model. so relax. just push sergey to write an example / unit test for his old code :) | 16:34 |
sonne|work | Yanglittle_: print it! | 16:35 |
sonne|work | I never heard of a problem like that... | 16:35 |
Yanglittle_ | yesterday it worked well, the data i checked | 16:37 |
Yanglittle_ | all are the right type | 16:37 |
Yanglittle_ | i try to reinstall it ,and it needs to uninstall it? i downloaded the newest through the git. | 16:44 |
-!- nube [~rho@49.244.31.182] has joined #shogun | 16:50 | |
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 17:01 | |
shogun-notifier- | shogun: vigsterkr :develop * 1648596 / src/shogun/lib/SGMatrix.cpp: https://github.com/shogun-toolbox/shogun/commit/164859643da442a0e3eb3837be8cbdf26527dc64 | 17:01 |
shogun-notifier- | shogun: Fix leak in SGMatrix::get_row_vector function | 17:01 |
shogun-notifier- | shogun: vigsterkr :develop * 8d8eabd / tests/unit/mathematics/Random_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/8d8eabd3da95cb159c74d96a5c626ed93cc17f0d | 17:03 |
shogun-notifier- | shogun: Fix leak in Random_unittest | 17:03 |
lisitsyn1 | sonne|work: ich habe ein problem mit cygwin + shogun | 17:03 |
lisitsyn1 | sonne|work: it fails to run with syntax error :D | 17:04 |
sonne|work | lisitsyn1: syntax terrorist! | 17:05 |
wiking | mmm | 17:06 |
shogun-notifier- | shogun: vigsterkr :develop * f2221e4 / tests/unit/base/Serialization_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/f2221e48164729fdd2aaebf68029dbe3d096688f | 17:08 |
shogun-notifier- | shogun: Fix leak in Serialization.liblinear unit test | 17:08 |
@HeikoS | thoralf: I just do them in a text editor and then make in terminal | 17:09 |
@HeikoS | but when I write them I use a test project which I use in to test out things in general | 17:09 |
@HeikoS | wiking: thanks for the reports! | 17:09 |
@HeikoS | wiking: maybe send roman an email about the leaks in GP stuff | 17:09 |
@HeikoS | sonne|work: yes, things should be getting better | 17:10 |
-!- lisitsyn1 [~lisitsin@mxs.kg.ru] has quit [Read error: Connection reset by peer] | 17:13 | |
wiking | HeikoS: done | 17:13 |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has joined #shogun | 17:14 | |
@HeikoS | lisitsyn: how to do std lasso logistic regression in shogun? | 17:14 |
lisitsyn | HeikoS: FeatureBlockLogisticRegression | 17:14 |
@HeikoS | and blocks? | 17:16 |
@HeikoS | just one index each? | 17:16 |
lisitsyn | HeikoS: the same thing | 17:17 |
@HeikoS | nono | 17:17 |
@HeikoS | how to set up the groups for std lasso | 17:17 |
lisitsyn | ahhhhhhh | 17:17 |
lisitsyn | :D | 17:17 |
lisitsyn | lasso | 17:17 |
lisitsyn | not group lasso right? | 17:17 |
lisitsyn | HeikoS: bad news then! | 17:17 |
@HeikoS | yep not group | 17:17 |
lisitsyn | HeikoS: we only have lars | 17:17 |
@HeikoS | ah so no logistic regression? | 17:18 |
lisitsyn | HeikoS: least squares only | 17:18 |
@HeikoS | mmh | 17:18 |
lisitsyn | HeikoS: though I can port the method for that! | 17:18 |
@HeikoS | nono | 17:18 |
@HeikoS | maybe later | 17:18 |
@HeikoS | so the only sparse linear regression we have is in liblinear right? | 17:18 |
lisitsyn | HeikoS: yes probably | 17:19 |
lisitsyn | HeikoS: though you can use featureblock thing | 17:19 |
shogun-buildbot | build #918 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/918 blamelist: vigsterkr <vigsterkr@gmail.com> | 17:19 |
@HeikoS | lisitsyn: how? | 17:20 |
@HeikoS | I guess each group consists of one element? | 17:20 |
lisitsyn | HeikoS: oops I remember it has L1 by default | 17:21 |
lisitsyn | it is called 'supernode' | 17:21 |
lisitsyn | :D | 17:21 |
-!- iglesiasg [c1934d16@gateway/web/freenode/ip.193.147.77.22] has quit [Quit: Page closed] | 17:21 | |
lisitsyn | HeikoS: oops not sure | 17:23 |
@HeikoS | lisitsyn: doesnt liblinear do L1? | 17:23 |
-!- HeikoS [~heiko@nat-189-255.internal.eduroam.ucl.ac.uk] has left #shogun [] | 17:26 | |
lisitsyn | HeikoS it does | 17:27 |
-!- HeikoS [~heiko@nat-189-255.internal.eduroam.ucl.ac.uk] has joined #shogun | 17:28 | |
-!- mode/#shogun [+o HeikoS] by ChanServ | 17:28 | |
-!- iglesiasg [~iglesiasg@193.147.77.22] has joined #shogun | 17:31 | |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 17:31 | |
shogun-buildbot | build #919 of cyg1 - libshogun is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/919 blamelist: vigsterkr <vigsterkr@gmail.com> | 17:32 |
wiking | HeikoS: wouldn't it be enough if i do a TParameter.copy_data for each parameter of an SGObject to do clone-ing? | 17:39 |
@HeikoS | wiking: yes | 17:39 |
@HeikoS | totally | 17:39 |
@HeikoS | wiking: have a look at the equals method | 17:39 |
wiking | HeikoS: yep i've checked it | 17:39 |
-!- Yanglittle_ [deb20afd@gateway/web/freenode/ip.222.178.10.253] has quit [Quit: Page closed] | 17:39 | |
@HeikoS | very similar to this, but not comparing, but copying | 17:39 |
@HeikoS | wiking: its just a little tedious to implement this | 17:39 |
@HeikoS | has to be very carefully unit-tested etc to avoid weird errors | 17:40 |
@HeikoS | so if you want to do this: a test for every case | 17:40 |
@HeikoS | but I can also do it | 17:40 |
wiking | HeikoS: no worries work on something else | 17:40 |
@HeikoS | since I did the equals already, I already know what to look out for | 17:40 |
wiking | HeikoS: i just wanted to double check if i understood it right | 17:40 |
@HeikoS | maybe if you want to do other things instead? | 17:40 |
wiking | HeikoS: ah ok so i'll just create a TParameter* TParameter::clone() const; function | 17:42 |
shogun-buildbot | build #920 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/920 blamelist: vigsterkr <vigsterkr@gmail.com> | 17:43 |
@HeikoS | wiking: no not exactly | 17:46 |
@HeikoS | wiking: so the first issue is: TParameter instances are very hard to create from scratch | 17:46 |
@HeikoS | I did that for the migration framework | 17:46 |
@HeikoS | and its a pain in the *** | 17:46 |
@HeikoS | so it would be better to use std constructors and then just copy data into the existing parameters of the empty CSGObject | 17:47 |
wiking | aaah | 17:47 |
@HeikoS | so first the CSGObject needs to create an empty instance of its own type | 17:47 |
@HeikoS | which is the first challenge | 17:47 |
@HeikoS | How would that work? | 17:48 |
wiking | deep_copy :D | 17:49 |
wiking | SG_NOTIMPLEMENTED :> | 17:49 |
@HeikoS | no an emptry instance | 17:50 |
@HeikoS | say I am a CGaussianKernel | 17:50 |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has joined #shogun | 17:50 | |
thoralf | Sure ;) | 17:50 |
@HeikoS | how to create such an instance from CSGObject::clone() | 17:50 |
@HeikoS | votjakovr: hi! | 17:50 |
wiking | votjakovr: thnx for the PR | 17:51 |
votjakovr | HeikoS: hi | 17:51 |
@HeikoS | votjakovr: there are a few memory leaks in GP stuff | 17:51 |
wiking | votjakovr: let's see what does travis do and then i'll merge it | 17:51 |
wiking | votjakovr: i suspect that it'll do just fine :P | 17:51 |
votjakovr | HeikoS: Ok :) | 17:51 |
votjakovr | HeikoS: Sorry, memory leaks are my mistake. | 17:52 |
votjakovr | HeikoS: Btw is it possible to use valgrind with travis? | 17:53 |
wiking | votjakovr: yes | 17:54 |
wiking | but we didn't enabled it | 17:54 |
@HeikoS | votjakovr: you heard the man | 17:54 |
@HeikoS | votjakovr: just make sure your code doesnt leak when you run it yourself | 17:54 |
wiking | HeikoS: CSGObject::clone() what would be the return value? :) | 17:54 |
wiking | i mean CSGObject* i guess | 17:54 |
@HeikoS | wiking: we should enable this at some point and throw errors if it leaks | 17:54 |
wiking | but we would need to cast it at some point | 17:54 |
@HeikoS | wiking: yes | 17:54 |
@HeikoS | but how to instanciate? | 17:54 |
@HeikoS | we would need a class factors | 17:55 |
@HeikoS | factory | 17:55 |
wiking | mmm | 17:55 |
@HeikoS | that we pass this pointer and that returns a new std instance of the same type | 17:55 |
@HeikoS | maybe sonney2k has an idea | 17:55 |
wiking | typeid(obj).name() | 17:55 |
wiking | :) | 17:55 |
wiking | HeikoS: http://www.cplusplus.com/reference/typeinfo/type_info/ | 17:56 |
@HeikoS | ok | 17:56 |
wiking | although | 17:56 |
@HeikoS | and then the factory instanciates? | 17:57 |
wiking | we always have get_name() | 17:57 |
@HeikoS | this could work | 17:57 |
@HeikoS | even automatically | 17:57 |
@HeikoS | if names are unique | 17:57 |
@HeikoS | but they have to be anyway | 17:57 |
wiking | so that's standard within shogun as apparently typeid implementation differs among various compiles | 17:57 |
@HeikoS | of we add an abstract method to CSGobject | 17:57 |
@HeikoS | create_empty()=0 | 17:57 |
@HeikoS | which returns new CClassName() | 17:58 |
@HeikoS | I think that might be best | 17:58 |
@HeikoS | we will ahve to add it to all classes though | 17:58 |
@HeikoS | non-abstract classes | 17:58 |
wiking | maybe it's better to use it with copy ctors | 17:58 |
wiking | actually copy ctor of CSGObject is not correct | 17:59 |
wiking | as it doesn't copy the parameter values | 18:00 |
wiking | only does init(); set_global_objects(); | 18:00 |
wiking | HeikoS: if we fix copy ctor in SGObject | 18:00 |
wiking | then the copy ctor of any class should work | 18:00 |
@HeikoS | dont get it | 18:00 |
@HeikoS | how would that look? | 18:00 |
wiking | so we have this | 18:00 |
wiking | CSGObject(const CSGObject& orig) | 18:01 |
wiking | right? | 18:01 |
wiking | but it doesn't really do deep copy of the orig | 18:01 |
wiking | just creates another CSGObject actually | 18:02 |
wiking | it's essentially the same as if i would call CSGObject() | 18:02 |
wiking | but that's not what a copy ctor should do | 18:02 |
wiking | it should actually copy orig itself | 18:02 |
wiking | the parameters we can copy | 18:02 |
wiking | we need a clone method for TParameter | 18:02 |
@HeikoS | I dont see how you can clone with that | 18:03 |
@HeikoS | we need CSGObject::clone() | 18:03 |
@HeikoS | which returns a new CSGObject instance | 18:03 |
wiking | HeikoS: a copy ctor actually is the same | 18:03 |
wiking | LibSVM a(origSVM); | 18:03 |
-!- gsomix [~Miranda@5850-AMTS-1-48.dialup.samtel.ru] has joined #shogun | 18:03 | |
gsomix | good evegning | 18:04 |
gsomix | *evening | 18:04 |
wiking | HeikoS: if one has this ctor one expects that a equals b | 18:04 |
wiking | i.e. it's copied | 18:04 |
@HeikoS | wiking: but this is not polymoirphic | 18:04 |
@HeikoS | we want to be able to call clone without knowing the type | 18:05 |
@HeikoS | for a copy constructor one needs to know the type | 18:05 |
@HeikoS | gsomix: hi! | 18:06 |
-!- iglesiasg [~iglesiasg@193.147.77.22] has quit [Quit: Leaving] | 18:14 | |
wiking | HeikoS: mmm in that case ...? | 18:17 |
@HeikoS | wiking: what do you think of an abstract method? | 18:17 |
-!- travis-ci [~travis-ci@ec2-23-22-250-98.compute-1.amazonaws.com] has joined #shogun | 18:17 | |
travis-ci | [travis-ci] it's vigsterkr'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/7844100 | 18:17 |
-!- travis-ci [~travis-ci@ec2-23-22-250-98.compute-1.amazonaws.com] has left #shogun [] | 18:17 | |
@HeikoS | maybe this can even be done automatically | 18:17 |
wiking | HeikoS: you mean virtual clone()=0;? | 18:17 |
@HeikoS | wiking: no | 18:18 |
wiking | where then? :) | 18:18 |
@HeikoS | virtual CSGObject* create_empty_instance() = 0 | 18:18 |
@HeikoS | in CSGObject::clone() this is then called | 18:18 |
@HeikoS | and parameters are copied | 18:18 |
wiking | HeikoS: create_empty_instance() { new ObjName(); } :) | 18:21 |
wiking | HeikoS: i mean the code can be generated actually :P | 18:22 |
@HeikoS | wiking: exactly | 18:22 |
@HeikoS | or are there c++ tricks to do this? | 18:22 |
wiking | HeikoS: yeah i'm just trying to find out | 18:22 |
thoralf | HeikoS: Cool, eclipse can run valgrind on the unit tests *and* parse its output, so you can point-and-click on the stack traces. | 18:26 |
@HeikoS | wiking: if not we will just add an automagically constructed method to all non-abstract classes | 18:26 |
@HeikoS | thoralf: yep :) | 18:27 |
@HeikoS | imagine all the time that it saved you! :) | 18:27 |
thoralf | the savings are still negative ;) | 18:31 |
thoralf | Hmm. Too many undefined-variables-warnings in valgrind. | 18:39 |
thoralf | You guys should check the valgrind warnings more often. | 18:40 |
@HeikoS | thoralf: that is? | 18:40 |
@HeikoS | which program? | 18:40 |
thoralf | HeikoS: shogun-unit-test | 18:40 |
@HeikoS | thoralf: yep, the plan is at some point to turn it on by default | 18:40 |
@HeikoS | which tests? | 18:40 |
thoralf | HeikoS: All. ;) | 18:40 |
@HeikoS | what? | 18:40 |
thoralf | HeikoS: Running all tests, I see a lot of warnings. ;) | 18:41 |
thoralf | HeikoS: (instead of "all tests throw warnings") | 18:42 |
@HeikoS | thoralf: I will check | 18:42 |
@HeikoS | wiking: recently posted some memory problems in unit tests | 18:42 |
shogun-notifier- | shogun: Roman Votyakov :develop * 43cabcf / tests/unit/regression/gp/ (2 files): https://github.com/shogun-toolbox/shogun/commit/43cabcf46af6a81168bfefa27bb8cea84e8f7533 | 18:42 |
shogun-notifier- | shogun: Fixed memory leak in GaussianLikelihood and StudentsTLikelihood unit tests | 18:42 |
shogun-notifier- | shogun: Heiko Strathmann :develop * 9850f44 / tests/unit/regression/gp/ (2 files): https://github.com/shogun-toolbox/shogun/commit/9850f44aa213fab987e30c179e58a5bcbbdbed9f | 18:42 |
shogun-notifier- | shogun: Merge pull request #1159 from votjakovr/develop | 18:42 |
shogun-notifier- | shogun: | 18:42 |
shogun-notifier- | shogun: Fixed memory leak in GaussianLikelihood and StudentsTLikelihood unit tests | 18:42 |
@HeikoS | should be a few less now | 18:42 |
@HeikoS | wiking: btw are you doing this random forest stuff currently? | 18:43 |
thoralf | sonne|work: You should add "lhs_equals_rhs=false;" to CKernel::init() (Kernel.cpp:962) | 18:44 |
@HeikoS | I have a suggestion: Could the Bagging class be able to handle arbritary machines? | 18:44 |
thoralf | sonne|work: Just a random warning. ;) | 18:44 |
thoralf | Enough playing. Heading home now. | 18:45 |
thoralf | Bye! | 18:45 |
@HeikoS | thoralf: bye and thanks for your help! :) | 18:46 |
shogun-buildbot | build #921 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/921 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 18:47 |
wiking | HeikoS: trying | 18:49 |
wiking | HeikoS: yes it is currently lik ethat | 18:50 |
wiking | HeikoS: or i have a WIP commit for BaggingMachine | 18:50 |
wiking | HeikoS: but i would need machine.clone() | 18:50 |
@HeikoS | cool! | 18:50 |
@HeikoS | we will get that | 18:50 |
@HeikoS | buts lets discuss with sören about the std instance first | 18:50 |
wiking | HeikoS: i'm waiting for that for a month now :P | 18:50 |
wiking | i mean for clone | 18:50 |
@HeikoS | wiking | 18:53 |
@HeikoS | once we have the std instance | 18:53 |
@HeikoS | its not that hard | 18:53 |
@HeikoS | very simmilar to equaöls | 18:53 |
@HeikoS | and it will work for all objects | 18:53 |
@HeikoS | so only implementing this once | 18:53 |
wiking | std instance? | 18:54 |
@HeikoS | and then we can also remove this annoying deep_copy() shallow_copy stuff | 18:54 |
@HeikoS | yes new CClassName | 18:54 |
wiking | ah you mean the create_empty_class() ? | 18:54 |
@HeikoS | lisitsyn, sonney2k, [----------] 2 tests from CustomKernelTest | 18:55 |
@HeikoS | [ RUN ] CustomKernelTest.add_row_subset | 18:55 |
@HeikoS | Segmentation fault (core dumped) | 18:55 |
@HeikoS | wiking: yes | 18:55 |
shogun-buildbot | build #922 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/922 blamelist: Roman Votyakov <votjakovr@gmail.com> | 18:57 |
-!- lisitsyn [~lisitsin@mxs.kg.ru] has quit [Quit: Leaving.] | 19:02 | |
wiking | HeikoS: we can do a simple class factory | 19:03 |
@HeikoS | how would you do it? | 19:04 |
wiking | template<typename T> CSGObject* create_empty_object() {return new T();} | 19:05 |
@HeikoS | wiking, thats it! | 19:05 |
@HeikoS | nice | 19:05 |
@HeikoS | ah no | 19:05 |
@HeikoS | nono | 19:05 |
@HeikoS | it needs to be typefree | 19:06 |
@HeikoS | for this one, one needs to specify T | 19:06 |
@HeikoS | I think the abstract method is the only way | 19:06 |
-!- gsomix [~Miranda@5850-AMTS-1-48.dialup.samtel.ru] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] | 19:08 | |
wiking | HeikoS: well then we need to add that little code to each class in shogun :P | 19:10 |
wiking | HeikoS: maaaybe we can do this with some macro hacking | 19:12 |
@HeikoS | wiking | 19:12 |
@HeikoS | I would suggest that we have a script that does this for us | 19:12 |
wiking | so the preprocessor generates the create_empty_class() for each shogun class | 19:12 |
@HeikoS | since it is the same for all | 19:12 |
wiking | HeikoS: yeah either that or macro | 19:13 |
wiking | i'll check if macro is possible | 19:13 |
@HeikoS | can the preprocessor read the filename? | 19:13 |
wiking | of course | 19:13 |
@HeikoS | then just use it | 19:13 |
@HeikoS | CSGObject* create_std_instance() | 19:14 |
@HeikoS | ah its more difficult - only non-abstract classes have this | 19:14 |
@HeikoS | otherwise it wont compile | 19:14 |
@HeikoS | I am sure that sonney2k know what to do here | 19:15 |
@HeikoS | wiking btw the alternative is to serialise the instance | 19:25 |
@HeikoS | and load | 19:25 |
@HeikoS | ah no | 19:25 |
wiking | HeikoS: yeah i wrote that once :P | 19:25 |
@HeikoS | again needs a std instance | 19:25 |
wiking | HeikoS: i mean here in chat | 19:25 |
@HeikoS | so we need that anyway | 19:25 |
wiking | HeikoS: actually i'll work.... :) | 19:25 |
@HeikoS | also serialisation might be slow | 19:25 |
@HeikoS | which you dont want | 19:26 |
wiking | HeikoS: serialize into a file and that's it ;) | 19:26 |
wiking | and load it n times | 19:26 |
@HeikoS | wiking: rather a bytestream that a file | 19:26 |
wiking | hehehe :) | 19:26 |
wiking | that's eyecandy | 19:26 |
@HeikoS | things should stay in memory | 19:26 |
@HeikoS | no file is very slow | 19:26 |
wiking | yeah of course | 19:26 |
wiking | but essentially it's the same | 19:26 |
wiking | apart from the IO | 19:26 |
@HeikoS | copy will be much faster still | 19:27 |
@HeikoS | serialisation code is not really good ;) | 19:27 |
@HeikoS | we should just write copy, its easy, just a bit of work | 19:27 |
wiking | well then we have to generate that create_obj() for each non-abstract class | 19:27 |
wiking | ;P | 19:27 |
@HeikoS | yes | 19:29 |
@HeikoS | either by hand or by magic | 19:29 |
@HeikoS | I dont know | 19:29 |
@HeikoS | should be automatic | 19:29 |
@HeikoS | talk to sören about that | 19:30 |
@HeikoS | once its there, I will write the copy code | 19:30 |
wiking | heheheh | 19:30 |
wiking | HeikoS: ok | 19:36 |
wiking | HeikoS: i have another idea | 19:36 |
@HeikoS | wiking: yes? | 19:37 |
wiking | mmm just writing to gist | 19:39 |
wiking | HeikoS: well one simple solution of course | 19:41 |
wiking | instead of going throught the whole fucking derived classes | 19:41 |
wiking | is that we create a factory | 19:41 |
wiking | of class | 19:41 |
wiking | and it has a function something like | 19:42 |
wiking | CSGObject* createInstance(const char* name) | 19:42 |
@HeikoS | remember that we have to call this from CSGObject and it has to create instances of CGaussianKernel | 19:42 |
@HeikoS | I see | 19:42 |
@HeikoS | and then in the factory have the code? | 19:42 |
wiking | yes | 19:42 |
wiking | a lot of if (name == "GaussianKernel") | 19:42 |
wiking | and since we always have get_name() in every class | 19:42 |
wiking | this should work | 19:43 |
@HeikoS | maybe the factory could do some magic | 19:43 |
wiking | well | 19:43 |
wiking | not really :) | 19:44 |
wiking | either we go with this | 19:44 |
wiking | and then we have to edit only one file | 19:44 |
wiking | or do the other | 19:45 |
wiking | and then we have to edit all the files which are not abstract classes | 19:45 |
wiking | :P | 19:45 |
wiking | i'd go with the first option | 19:47 |
wiking | so we only need to write edit one file | 19:48 |
@HeikoS | wiking: yes agreed | 19:49 |
@HeikoS | gotta go now, well talk about this tomorrow | 19:49 |
@HeikoS | maybe catch sonney2k on this | 19:49 |
-!- lisitsyn [~blackburn@188.168.14.83] has joined #shogun | 19:50 | |
lisitsyn | haaha! votjakovr have you heard the news? | 19:59 |
lisitsyn | divorce of the asshole! | 19:59 |
wiking | HeikoS: https://gist.github.com/vigsterkr/5723548 | 20:02 |
votjakovr | lisitsyn: hey! nope... Please more details | 20:02 |
wiking | lisitsyn: comments.... https://gist.github.com/vigsterkr/5723548 | 20:02 |
lisitsyn | votjakovr: putin divorces! | 20:02 |
wiking | sonney2k: when u have battery/time plz check it out and comment: https://gist.github.com/vigsterkr/5723548 | 20:03 |
votjakovr | lisitsyn: i think it's not a news :) | 20:03 |
lisitsyn | votjakovr: now officially! | 20:03 |
lisitsyn | wiking: like generic clone? | 20:03 |
wiking | lisitsyn: yeah to have clone without starting to edit all the files in shogun | 20:04 |
lisitsyn | wiking: ja gut | 20:04 |
wiking | lisitsyn: although it will be still pain in the ass to do this for all the classes... and of course what happens if somebody adds a new class and forgets to edit the createObject() static function :P | 20:05 |
lisitsyn | wiking: wait we have some structure | 20:05 |
lisitsyn | wiking: classlist.cpp | 20:05 |
wiking | where's that | 20:06 |
lisitsyn | wiking: base | 20:06 |
lisitsyn | wiking: autogenerated before compilation | 20:06 |
wiking | ah | 20:06 |
wiking | lol man | 20:06 |
wiking | static class_list_entry_t class_list[] | 20:06 |
lisitsyn | wiking: I wouldn't mind a static map here | 20:07 |
wiking | this is it! | 20:07 |
lisitsyn | no it is array | 20:07 |
wiking | it's already there | 20:07 |
wiking | yaeh | 20:07 |
wiking | but | 20:07 |
lisitsyn | linear | 20:07 |
wiking | CSGObject* shogun::new_sgserializable(const char* sgserializable_name, EPrimitiveType generic) | 20:07 |
lisitsyn | ahh yes it is here | 20:07 |
wiking | so we have this already | 20:08 |
wiking | ;) | 20:08 |
lisitsyn | yes wiking how would serialization work otherwise | 20:08 |
lisitsyn | :D | 20:08 |
wiking | so if i call shogun::new_sgserializable("ScatterSVM") | 20:08 |
wiking | i should get a ScatterSVM* | 20:08 |
wiking | as CSGObject* | 20:08 |
wiking | so it's all good | 20:08 |
lisitsyn | yes | 20:08 |
wiking | HeikoS: start working ;) | 20:08 |
wiking | HeikoS: as we have a factory method | 20:09 |
-!- mode/#shogun [+o sonney2k] by ChanServ | 20:18 | |
@sonney2k | wiking, we have that already | 20:19 |
@sonney2k | wiking, look at the automatically generated shogun/base/class_list.cpp | 20:19 |
@sonney2k | wiking, HeikoS and then new_sgserializable("CanberraMetric", PT_NOT_GENERIC) will just do what you want | 20:22 |
@sonney2k | it will also handle templated types | 20:23 |
@sonney2k | e.g. for DenseFeatures of type float64 you would do | 20:23 |
@sonney2k | new_sgserializable("CanberraMetric", PT_FLOAT64) | 20:23 |
lisitsyn | HeikoS: uh valgrinding it is not that easy! | 20:35 |
wiking | sonney2k: yeah lisitsyn just made me aware of that ;) | 20:43 |
lisitsyn | wiking: he doesn't see my messages I guess :D | 20:44 |
@HeikoS | wiking, lisitsyn, sonney2k well nice, lesson learned :) | 20:45 |
lisitsyn | wiking: begging machine :D | 20:53 |
-!- zxtx [~zv@cpe-75-83-151-252.socal.res.rr.com] has quit [Ping timeout: 248 seconds] | 20:53 | |
shogun-notifier- | shogun: Sergey Lisitsyn :develop * 818a18b / tests/unit/converter/TDistributedStochasticNeighborEmbedding_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/818a18beed6343a860178f2347ecdf3ba0232112 | 21:12 |
shogun-notifier- | shogun: Added missed unrefs in T-SNE unit test. Closes #1155 | 21:12 |
shogun-buildbot | build #923 of cyg1 - libshogun is complete: Failure [failed configure] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cyg1%20-%20libshogun/builds/923 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 21:17 |
wiking | HeikoS: still around? | 21:35 |
@HeikoS | wiking: kind of | 21:35 |
wiking | HeikoS: ok so i've started to write the CSGObject::clone | 21:36 |
wiking | so i thought that we should have Parameter::clone() and TParameter::clone as well | 21:36 |
@HeikoS | wiking: nice | 21:36 |
wiking | just to make it actually easy | 21:36 |
@HeikoS | Parameter::clone is not necessary | 21:36 |
@HeikoS | just TParameter | 21:36 |
wiking | yeah i know | 21:36 |
@HeikoS | and also no need for a clone method | 21:36 |
@HeikoS | since thats very hard | 21:36 |
@HeikoS | rather | 21:37 |
wiking | copy | 21:37 |
@HeikoS | we want a copy method | 21:37 |
wiking | ? | 21:37 |
@HeikoS | TParameter::copy(TParameter* target) | 21:37 |
wiking | ah | 21:37 |
wiking | what's copy_data? | 21:37 |
@HeikoS | let me check | 21:37 |
lisitsyn | HeikoS: https://github.com/shogun-toolbox/shogun/commit/f9cdccf2cf48cf4168437cbc3741288a209a2727#L0L-1 | 21:37 |
wiking | btw: how do i add TParameter to Parameter? | 21:37 |
@HeikoS | howdy | 21:38 |
@HeikoS | maybe this is already there | 21:38 |
@HeikoS | let me check | 21:38 |
-!- travis-ci [~travis-ci@ec2-23-20-127-141.compute-1.amazonaws.com] has joined #shogun | 21:38 | |
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/7851770 | 21:38 |
-!- travis-ci [~travis-ci@ec2-23-20-127-141.compute-1.amazonaws.com] has left #shogun [] | 21:38 | |
lisitsyn | oops HeikoS rather that https://github.com/shogun-toolbox/shogun/commit/f9cdccf2cf48cf4168437cbc3741288a209a2727#L0R36 | 21:38 |
@HeikoS | wiking: I think we can use this existing one. we might have to modify it | 21:39 |
@HeikoS | but thats great in fact | 21:39 |
@HeikoS | lisitsyn: I like this, but is it that much easier than before? | 21:39 |
lisitsyn | HeikoS: actually no | 21:40 |
@HeikoS | wiking: the copy_data is nice since it exploits c++ | 21:40 |
lisitsyn | lets see if I get something reasonable from it | 21:40 |
@HeikoS | it just copies the memory | 21:40 |
wiking | HeikoS: iok i'll just do that for now | 21:40 |
@HeikoS | wiking: but please dont change anything yet, we need to take care when doing that since copy_data is deeply involved in the migration framework | 21:40 |
wiking | HeikoS: Paramater needs an add_parameter(TParameter*) function though | 21:40 |
wiking | HeikoS: i won't touch anything in TParameter | 21:41 |
@HeikoS | wiking: why? | 21:41 |
@HeikoS | wiking no we cannot use this method | 21:41 |
@HeikoS | we should add a new one | 21:41 |
@HeikoS | (and maybe remove the old one at some point) | 21:41 |
wiking | why is it not good? | 21:42 |
wiking | just that i know what to look out for | 21:42 |
@HeikoS | wiking: huh, its baaaad code | 21:42 |
@HeikoS | I did not know shogun well enough back then | 21:42 |
@HeikoS | ;D | 21:42 |
@HeikoS | we should rewrite it | 21:42 |
@HeikoS | and we should do it the better way | 21:42 |
lisitsyn | no forward declaration for enum ARGH | 21:43 |
lisitsyn | wiking: HeikoS: a note to remember: you can't forward declare an enum | 21:43 |
@HeikoS | haha :) | 21:44 |
lisitsyn | it is totally freaking possible to forward a class | 21:45 |
lisitsyn | but not an enum | 21:45 |
wiking | lisitsyn: ? :) | 21:45 |
@HeikoS | wiking: yeah this copy_data is a nightmare | 21:46 |
@HeikoS | I should get inprisoned into golark for at least 2 years for that | 21:46 |
lisitsyn | wiking: unentangling includes here | 21:46 |
wiking | HeikoS: ok i'll redo one then | 21:47 |
wiking | i'll just add it to a separate branh | 21:48 |
wiking | so you can comment it | 21:48 |
wiking | *branch | 21:48 |
@HeikoS | wiking: I can also do this one, since I already diud the equals | 21:48 |
@HeikoS | that might be more effective | 21:48 |
wiking | HeikoS: i need it now :) | 21:48 |
@HeikoS | wiking: okay, let me start now then | 21:48 |
@HeikoS | will push to a feature branch | 21:48 |
wiking | cool | 21:48 |
wiking | HeikoS: wait | 21:49 |
wiking | before doing that | 21:49 |
wiking | well no matter do it :) | 21:49 |
-!- zxtx [~zv@rrcs-74-62-200-195.west.biz.rr.com] has joined #shogun | 22:04 | |
shogun-notifier- | shogun: Sergey Lisitsyn :feature/model_selection_syntax * e46acce / src/ (6 files): https://github.com/shogun-toolbox/shogun/commit/e46acce195d84bfe8267f8a8fd9aea24d8d51ad2 | 22:06 |
shogun-notifier- | shogun: Extracted model selection range builder out | 22:06 |
lisitsyn | HeikoS: ping | 22:13 |
@HeikoS | pong | 22:13 |
lisitsyn | HeikoS: what if we put root of model selection tree | 22:14 |
lisitsyn | to machine? | 22:14 |
@HeikoS | ? | 22:14 |
lisitsyn | HeikoS: well we just set parameters for classifier | 22:15 |
lisitsyn | and it stores the root | 22:15 |
lisitsyn | HeikoS: classifier = LibSVM() | 22:15 |
@HeikoS | no the root never has something | 22:15 |
@HeikoS | you have to create a child and add parameters there | 22:15 |
lisitsyn | classifier.parameter("C1").... | 22:16 |
lisitsyn | HeikoS: ^ this creates the root and adds a child | 22:16 |
@HeikoS | ok | 22:17 |
lisitsyn | HeikoS: so what do you think? | 22:18 |
lisitsyn | currently it looks like no tree is needed then | 22:18 |
@HeikoS | lisitsyn: let me check that tomorrow | 22:18 |
@HeikoS | but already looking good! | 22:18 |
lisitsyn | I mean it will be under the hood | 22:18 |
@HeikoS | yes, thats pretty cool"! | 22:18 |
lisitsyn | HeikoS: what I am worried though | 22:18 |
lisitsyn | say we have root of classifier | 22:18 |
lisitsyn | and then we add kernel as parameter | 22:19 |
lisitsyn | kernel should also have a root | 22:19 |
lisitsyn | it should be handled somehow | 22:19 |
lisitsyn | argh I wish I could draw what I mean | 22:19 |
@HeikoS | wiking: its a bit more tricky than I thought | 22:19 |
@HeikoS | this will not be quickly solved | 22:19 |
@HeikoS | I gotta think about a few things | 22:19 |
@HeikoS | lisitsyn: not following :) | 22:20 |
lisitsyn | HeikoS: alright laterz | 22:20 |
@HeikoS | wiking: so the problem is overwriting old data | 22:20 |
@HeikoS | lisitsyn: no explain | 22:20 |
lisitsyn | HeikoS: hmm alright | 22:20 |
@HeikoS | wiking: we should do this very carefully, then we might also catch problems of the migration framework somehow | 22:20 |
lisitsyn | classifier has root | 22:20 |
@HeikoS | wiking: first thing is to write a TParameter::copy_ptype | 22:21 |
lisitsyn | then we add a kernel as child | 22:21 |
@HeikoS | thats already quite a challenge | 22:21 |
lisitsyn | kernel also has root | 22:21 |
@HeikoS | why has a kernel a root? | 22:21 |
lisitsyn | kernel.parameter("width").blabla | 22:21 |
wiking | HeikoS: overwriting old data? | 22:21 |
@HeikoS | wiking: I will look at this on the weekend | 22:21 |
lisitsyn | we should have some root for that too | 22:21 |
@HeikoS | wiking: yes there are all sorts of issues arising from that | 22:21 |
wiking | HeikoS: why we would overwrite anything? | 22:22 |
lisitsyn | HeikoS: in the end everything should be merged into one tree I mean | 22:22 |
@HeikoS | lisitsyn: but there is only one root in the tree | 22:22 |
wiking | i mean what we actually need is a simple clone of the TParameter | 22:22 |
@HeikoS | you just append the rest | 22:22 |
lisitsyn | HeikoS: yes and we should avoid empty nodes here\ | 22:22 |
@HeikoS | wiking: well imagine an object has a CSGObject variable | 22:22 |
lisitsyn | like appended root | 22:22 |
@HeikoS | this one is not NULL | 22:22 |
@HeikoS | after std constructpor | 22:22 |
@HeikoS | then the copy will overwrite it | 22:22 |
@HeikoS | so we might need to free memory | 22:22 |
@HeikoS | which is scary stuff, trust me, I have spent hours of hours on that 2 years ago | 22:23 |
@HeikoS | This time, I want to do it more systematically | 22:23 |
@HeikoS | lisitsyn: I am note sure this would even work with empty node | 22:24 |
@HeikoS | s | 22:24 |
@HeikoS | cant you just remove the root? | 22:24 |
lisitsyn | HeikoS: yes won't work so I'd have to merge | 22:24 |
lisitsyn | HeikoS: oh I think I understand what should be done here | 22:24 |
lisitsyn | lets see if I implement that | 22:24 |
wiking | HeikoS: can't we just call clone on the TParameter if it's a CSGObject? :) | 22:24 |
@HeikoS | yep | 22:25 |
@HeikoS | thats what we need to do | 22:25 |
wiking | ok | 22:25 |
lisitsyn | HeikoS: my aim is to avoid any tree construction for user | 22:25 |
@HeikoS | but still the old one has to be de-referenced | 22:25 |
wiking | HeikoS: old one? :) | 22:25 |
@HeikoS | yes the existing object in the TParameter to copy to | 22:25 |
@HeikoS | lisitsyn: very good aim | 22:26 |
@sonney2k | wiking, when you do that - one very welcome patch would be to make the copy constructor private and empty in each Object | 22:27 |
@sonney2k | to prevent abuse | 22:27 |
-!- nube [~rho@49.244.31.182] has quit [Ping timeout: 276 seconds] | 22:27 | |
@sonney2k | and only in objects that support shallow copy change that behavior | 22:27 |
@HeikoS | sonney2k: thats good! | 22:27 |
@HeikoS | wiking, sonney2k I will start working on the copy_ptype soon, this is the hardest one | 22:28 |
@sonney2k | HeikoS, wiking - I hope you agree that we do shallow copies in copy constructor (as in refcount increase but no real copy) | 22:28 |
@sonney2k | and clone() for real copy | 22:28 |
wiking | sonney2k: yes | 22:28 |
@HeikoS | then there are some issues with the datatype lengths, but these are less complicated | 22:28 |
@HeikoS | sonney2k: totally, yes | 22:28 |
@sonney2k | ok (it is the same we do with sgvector currently...) | 22:29 |
wiking | HeikoS: i really cannot see the complication atm you are talking about | 22:29 |
wiking | but i guess you know what's happening there | 22:29 |
wiking | oppose to me who has no clue :) | 22:29 |
@sonney2k | wiking, believe me - trust HeikoS | 22:29 |
@sonney2k | HeikoS, I am close to have SGSparseMatrix stuff to compile | 22:30 |
@sonney2k | HeikoS, but I know upfront serialization will be totally b0rken | 22:30 |
@sonney2k | HeikoS, any ideas how to handle that? | 22:30 |
@HeikoS | wiking: I dont mean to be slowing this stuff down, its just that I have been into exactly these problems a while ago and made the mistake of not thinking well enough about them which causes all sorts of annoying problems. | 22:31 |
@HeikoS | sonney2k: what? | 22:31 |
@sonney2k | SGSparseVector / SGSparseMatrix | 22:31 |
@HeikoS | wiking: once I have a quite moment, I will checkout the copy_ptype one | 22:31 |
@HeikoS | sonney2k: no idea, I would rather do that later after GSoC | 22:31 |
lisitsyn | CModelSelectionParameters* parameter(const char* name) | 22:31 |
@sonney2k | HeikoS, so we leave it broken? | 22:31 |
lisitsyn | HeikoS: sonney2k: ^ to sgobject? | 22:32 |
@HeikoS | sonney2k: thats also crap you are right | 22:32 |
@HeikoS | sonney2k: so what about this? I was talking the lambday about unit-testing the serialisation framework | 22:32 |
@HeikoS | for all types seperately | 22:32 |
@sonney2k | HeikoS, btw you still have 2 bugs assigned and the equals method is waiting :D | 22:32 |
@HeikoS | from low-level | 22:32 |
@HeikoS | so if this is working, the transition for sparse will be much easier | 22:33 |
@HeikoS | sonney2k: I know, but the parameter stuff is all related | 22:33 |
@sonney2k | HeikoS, problem is we need this sparse stuff ASAP for van51's dotfeature improvements | 22:33 |
@sonney2k | we currently disabled some tests that are crashing otherwise | 22:33 |
@HeikoS | sonney2k: okay, so lambday is currently writing serialisaion tests for complex | 22:33 |
@HeikoS | I can ask him to write these for all types | 22:34 |
@HeikoS | should not take more than a day or so | 22:34 |
@HeikoS | (he already agreed to do that ;) | 22:34 |
@HeikoS | but we postponed since we thought its not needed now | 22:34 |
@HeikoS | should I ask him? | 22:34 |
@sonney2k | HeikoS, yeah but we have no way of restoring any of the SGReferenced data types | 22:34 |
@HeikoS | onces these work you will get very low-level answers of what is wrong | 22:34 |
@HeikoS | maybe it doesnt help | 22:35 |
@HeikoS | I dont know | 22:35 |
@HeikoS | just want to avoid that things become broken and that we loose more shogun parts when doing this | 22:35 |
@HeikoS | the last time costed us the streaming framework | 22:35 |
@sonney2k | HeikoS, recall that we have this hack currently for storing SGVector and double* in the same way | 22:35 |
@HeikoS | yep | 22:35 |
@sonney2k | HeikoS, van51 will need that too - so we will need to see a conversion to SGVector / SGSparseVector there too | 22:36 |
@sonney2k | HeikoS, van51 is writing the best tests I have seen so far | 22:36 |
@sonney2k | so what we will get from him will survive quite a bit of refactoring :D | 22:36 |
@HeikoS | so maybe he can give lambday a hand? | 22:37 |
@HeikoS | thats good :D | 22:37 |
@HeikoS | maybe just go ahead, but in a feature branch? | 22:37 |
-!- travis-ci [~travis-ci@ec2-23-20-127-141.compute-1.amazonaws.com] has joined #shogun | 22:39 | |
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/7853585 | 22:39 |
-!- travis-ci [~travis-ci@ec2-23-20-127-141.compute-1.amazonaws.com] has left #shogun [] | 22:39 | |
-!- nube [~rho@49.244.14.162] has joined #shogun | 22:41 | |
-!- votjakovr [~votjakovr@host-46-241-3-209.bbcustomer.zsttk.net] has quit [Quit: Leaving] | 22:43 | |
@HeikoS | dude, shogun grows, takes ages to compile | 22:58 |
lisitsyn | HeikoS: I am desperate to find a way | 22:58 |
@HeikoS | for what? | 22:58 |
lisitsyn | HeikoS: I want to drop some code actually | 22:58 |
@HeikoS | lisitsyn: really? why? | 22:58 |
lisitsyn | HeikoS: to make it compile faster | 22:58 |
@HeikoS | I see | 22:58 |
@HeikoS | like modules | 22:58 |
lisitsyn | HeikoS: we should drop unsupported code | 22:58 |
@HeikoS | yep, I would agree, make a stable release | 22:59 |
@HeikoS | and try to extend that | 22:59 |
@HeikoS | but out of scope for now :D | 22:59 |
@HeikoS | too many other things | 22:59 |
lisitsyn | HeikoS: and more important may be we should get rid of templated features | 22:59 |
@HeikoS | yes? | 22:59 |
@HeikoS | man | 22:59 |
@HeikoS | thats tough | 22:59 |
-!- hushell [~hushell@c-24-21-141-32.hsd1.or.comcast.net] has quit [Ping timeout: 245 seconds] | 23:00 | |
lisitsyn | HeikoS: it is useless | 23:00 |
lisitsyn | HeikoS: no reason to expose real type | 23:00 |
lisitsyn | HeikoS: in modular features we are not able to provide compile-time checks anyway | 23:01 |
@HeikoS | yeah maybe | 23:01 |
lisitsyn | HeikoS: so template it or not - it just doesn't matter | 23:01 |
lisitsyn | HeikoS: next is shared_ptr | 23:01 |
@HeikoS | yep | 23:01 |
@HeikoS | many things that will break all the old stuff :D | 23:02 |
lisitsyn | HeikoS: that's good | 23:02 |
@HeikoS | we can also think of rewriting it in proper c++ ;) | 23:02 |
@HeikoS | like eigen | 23:02 |
lisitsyn | HeikoS: well depends | 23:02 |
lisitsyn | HeikoS: I am experting in hoch C++ but not all of its features are needed there | 23:03 |
lisitsyn | HeikoS: we are really tied to interfaces | 23:04 |
lisitsyn | so no C++ tricks here | 23:04 |
@HeikoS | yeah | 23:04 |
lisitsyn | I wish we at least had operator overloading | 23:04 |
lisitsyn | but it is possible only for python | 23:04 |
lisitsyn | HeikoS: if we had it we could write svm.C() = 3 | 23:04 |
lisitsyn | or svm.C = 3 which is even better | 23:05 |
@HeikoS | yeah | 23:05 |
@HeikoS | python is quite cool | 23:05 |
@HeikoS | recently done a lot of things in it | 23:05 |
@HeikoS | no need for other languages :D | 23:05 |
@HeikoS | so easy to write ml stuff | 23:05 |
lisitsyn | HeikoS: I would drop some interfaces too.. | 23:05 |
@HeikoS | R Matlab and python and the most important ones anyway, maybe java | 23:05 |
@HeikoS | are, not and | 23:05 |
lisitsyn | HeikoS: no we are not java library | 23:05 |
@HeikoS | well, some ML people use java | 23:06 |
@HeikoS | thats how it is | 23:06 |
@HeikoS | Matlab is also shit | 23:06 |
@HeikoS | and I also dont like R | 23:06 |
@HeikoS | however | 23:06 |
lisitsyn | HeikoS: no java is cool | 23:06 |
lisitsyn | and fast | 23:06 |
@HeikoS | should be supported | 23:06 |
lisitsyn | but we are not following java | 23:06 |
lisitsyn | it is important for java programs to heavily use OOP and interfaces and etc | 23:06 |
lisitsyn | using it as low-level backend for ML is too cumbersome for java | 23:07 |
lisitsyn | and anyway recalling that java is mapreduce | 23:07 |
lisitsyn | I wouldn't expect anyone use it like that | 23:07 |
lisitsyn | HeikoS: ah and one more thing - java is dead :D | 23:09 |
lisitsyn | (the language) | 23:09 |
@HeikoS | lisitsyn: yeah | 23:09 |
@HeikoS | agreed | 23:09 |
@HeikoS | so which ones would you keep? | 23:09 |
lisitsyn | now it is like a platform for new cool languages | 23:09 |
lisitsyn | HeikoS: COBOL, Shakespeare and Fortran interfaces are must have | 23:10 |
lisitsyn | so I'd keep these ones | 23:10 |
@HeikoS | argh unit tests segfault | 23:11 |
lisitsyn | HeikoS: we desperately need matlab modular and R modular | 23:11 |
@HeikoS | cannot run my own ones :( | 23:11 |
@HeikoS | lisitsyn: totally | 23:11 |
@HeikoS | top priority | 23:11 |
@HeikoS | but so annyoying ;) | 23:11 |
lisitsyn | lua/ruby -> trash | 23:11 |
@HeikoS | there will be soon many stats people trying to use shogun | 23:11 |
@HeikoS | they need R | 23:11 |
@HeikoS | and some also matlab | 23:11 |
lisitsyn | HeikoS: may be I should attempt revivification of matlab swig | 23:13 |
@sonney2k | sry guys got disconnected | 23:13 |
@HeikoS | lisitsyn: yes I have the feeling that we have to push this | 23:13 |
@sonney2k | HeikoS, the last thing I saw was - thats good :D | 23:13 |
@HeikoS | sonney2k: ehm :) | 23:14 |
lisitsyn | I don't know if the only brain cell of mine is capable of doing that | 23:14 |
@sonney2k | you both are funny | 23:14 |
@HeikoS | thats a while ago | 23:14 |
@HeikoS | sonney2k: its getting late ;) | 23:14 |
@HeikoS | so whats wrong with the unit tests | 23:14 |
@HeikoS | some fail | 23:14 |
@HeikoS | the others dont terminate | 23:14 |
@HeikoS | (on my machine) | 23:14 |
lisitsyn | HeikoS: have you cleaned? | 23:14 |
lisitsyn | the closet | 23:14 |
@sonney2k | maybe we should write a new matlab clone? | 23:14 |
lisitsyn | sonney2k: ha-ha funny | 23:15 |
@sonney2k | well I heard you say you want to do swig for matlab *haha* | 23:15 |
lisitsyn | sonney2k: well it was tried to be done | 23:15 |
lisitsyn | I don't know the status | 23:15 |
lisitsyn | http://julialang.org/ | 23:15 |
@sonney2k | no nothing there | 23:15 |
@sonney2k | and who has matlab? | 23:15 |
wiking | HeikoS: do a make clean in unit/tests | 23:16 |
lisitsyn | lets rather add an interface for julia | 23:16 |
@sonney2k | we couldn't even run tests for that | 23:16 |
lisitsyn | sonney2k: I have everything | 23:16 |
wiking | HeikoS: usually that's when u have segfaults in unit tests | 23:16 |
@HeikoS | wiking: cool thanks! | 23:16 |
lisitsyn | sonney2k: anti-piracy thing is not here yet :D | 23:16 |
@HeikoS | julia :D | 23:16 |
wiking | yeah let's have interface for sas and spss as well | 23:16 |
wiking | just in case | 23:16 |
@HeikoS | there is also the google lanuage | 23:17 |
lisitsyn | wiking: hahah | 23:17 |
@HeikoS | then we get more slots | 23:17 |
lisitsyn | HeikoS: julia is fast | 23:17 |
lisitsyn | according to benches | 23:17 |
@sonney2k | lisitsyn, well and javascript is fast too! | 23:18 |
@sonney2k | wait fortran is faster! | 23:18 |
lisitsyn | sonney2k: java script is crazy fast | 23:18 |
@HeikoS | lisitsyn: I dont even know julia | 23:18 |
lisitsyn | HeikoS: well me neither :D | 23:19 |
wiking | sonney2k: well if it's about vectors then of course fortran is better than c :P | 23:19 |
@HeikoS | a guy I know is writing a framework for automagic differantiation in ulia | 23:19 |
lisitsyn | there is also http://halide-lang.org/ | 23:19 |
@sonney2k | so lets make a vote - which language are you guys using besides C++ ? | 23:20 |
lisitsyn | anyway guys - if we don't go either distributed or GPU or massive multicore or reduce the size of our codebase we are going to die | 23:20 |
lisitsyn | sonney2k: python javascript clojure java | 23:20 |
wiking | lisitsyn: nono it'll end up being like octave :P | 23:20 |
@sonney2k | lisitsyn, compile time of libshogun didn't grow over the years btw | 23:21 |
@sonney2k | lisitsyn, for me it is java, python,javascript | 23:21 |
lisitsyn | sonney2k: no the size of codebase is the # of bugs | 23:21 |
@sonney2k | lisitsyn, wrong | 23:21 |
wiking | python, java | 23:21 |
lisitsyn | sonney2k: not wrong | 23:21 |
wiking | btw why dont we pursue that thing with viennacl? | 23:22 |
@HeikoS | sonney2k: really? | 23:22 |
@sonney2k | lisitsyn, yes you are - number of bugs only goes out of control if you have dependencies like in a fully connected graph | 23:22 |
@HeikoS | I have the feeling it takes longer that a while ago | 23:22 |
@sonney2k | HeikoS, and you? | 23:22 |
@HeikoS | languages? | 23:23 |
lisitsyn | sonney2k: writing pointers in 2013 is wrong | 23:23 |
@sonney2k | HeikoS, I am talking about libshogun. Of course if we do heavy template meta programming then we can kill ourselves | 23:23 |
@sonney2k | HeikoS, languages is only slow with swig but that is only because we have a single module at the end | 23:23 |
lisitsyn | we are killing ourselves right now | 23:23 |
lisitsyn | :D | 23:23 |
@HeikoS | ideal world: python, R, Matlab/octave, maybe java | 23:24 |
@HeikoS | sonney2k: thats all fine | 23:24 |
@HeikoS | did not complain I just was impressed by the size of the codebase | 23:24 |
@sonney2k | lisitsyn, I don't see this. to me it seems we are improving | 23:24 |
lisitsyn | sonney2k: improving in what? | 23:24 |
@sonney2k | code quality & tests | 23:24 |
lisitsyn | well we reduce number of bugs | 23:25 |
@HeikoS | I agree on that we are improving | 23:25 |
lisitsyn | what is the purpose of having 34234 svms | 23:26 |
lisitsyn | if we don't even support them? | 23:26 |
@sonney2k | HeikoS, ohh maybe we have a misunderstanding with compile time. When I started like 14 years ago machines were slow and the code base was tiny. Machines scaled up just nicely | 23:26 |
@sonney2k | lisitsyn, which svm is unsupported? | 23:27 |
lisitsyn | sonney2k: what about scatter svm? | 23:27 |
lisitsyn | you don't even sure it works | 23:27 |
@sonney2k | yes it works | 23:27 |
@sonney2k | not a killer though | 23:28 |
lisitsyn | why to have anything that is not a killer? | 23:28 |
@sonney2k | no free lunch... | 23:28 |
lisitsyn | we are just collecting code | 23:28 |
@sonney2k | it is like saying neural nets are the best - drop the rest | 23:28 |
@sonney2k | it is just wrong and stupid | 23:28 |
lisitsyn | sonney2k: I don't see the slot we are targeting | 23:28 |
@sonney2k | let the user decide what to use | 23:29 |
@sonney2k | ok I see | 23:29 |
lisitsyn | sonney2k: 99,9% of users will just use working solution | 23:29 |
@sonney2k | sure | 23:29 |
@sonney2k | argh brb | 23:29 |
lisitsyn | HeikoS: can you explain what is the slot I am talking about? | 23:30 |
lisitsyn | do you see any? | 23:30 |
@HeikoS | lisitsyn: I agree with you on this one | 23:30 |
@sonney2k | lisitsyn, sure I do | 23:30 |
@HeikoS | however I have a different perspective | 23:30 |
@HeikoS | I think we should have proper documentation of all these methos | 23:30 |
@sonney2k | the unique feature of shogun is that you can use almost any kind of feature type | 23:30 |
@HeikoS | explain the user what he can do | 23:30 |
@HeikoS | tell him std ways to do things | 23:30 |
@HeikoS | and drop stuff that is not working 99% | 23:31 |
@sonney2k | stacking features together with dotfeatures and multiple kernels / distances | 23:31 |
@sonney2k | and all algorithms with bindings to several languages | 23:31 |
@HeikoS | I also think we should be careful with adding all these things | 23:31 |
@sonney2k | so what you have learned with C++ will work with python & java | 23:31 |
@HeikoS | we are sometimes just adding new methods for the purpose of having them | 23:31 |
@HeikoS | but they are not used | 23:31 |
@HeikoS | since not working/not documented | 23:31 |
lisitsyn | HeikoS: we are constantly doing that | 23:32 |
@sonney2k | HeikoS, but that is a thing of the past | 23:32 |
@sonney2k | lisitsyn, no | 23:32 |
@sonney2k | now we require tests and examples and doc | 23:32 |
@HeikoS | efforts should be still focussed a bit more towards usability | 23:32 |
lisitsyn | this year gsoc will be just expanding the codebase again | 23:32 |
lisitsyn | no matter it covered with tests or now | 23:33 |
lisitsyn | or not* | 23:33 |
@HeikoS | lisitsyn: well if things are well documented its fine to add | 23:33 |
@HeikoS | but only then | 23:33 |
@HeikoS | otherwise its a bit pointless | 23:33 |
@HeikoS | even more if they stop working after a while | 23:33 |
lisitsyn | HeikoS: recalling scikits | 23:34 |
lisitsyn | they have a rule | 23:34 |
lisitsyn | they just don't implement anything that has less than say X citations | 23:34 |
wiking | lisitsyn http://viennacl.sourceforge.net/viennacl-examples-eigen.html | 23:34 |
lisitsyn | wiking: I used that | 23:34 |
wiking | and? | 23:34 |
lisitsyn | well it worked | 23:34 |
lisitsyn | wiking: what else would you expect ;) | 23:35 |
@HeikoS | lisitsyn: I dont think thats a very helpful rule | 23:35 |
@sonney2k | yeah it is useless | 23:35 |
@HeikoS | but I really find their website amazing | 23:36 |
@HeikoS | also, things work | 23:36 |
@sonney2k | it is like MKL or group lasso would be worth having | 23:36 |
lisitsyn | HeikoS: ohh well who needs X if we have no random forest | 23:36 |
@HeikoS | lisitsyn: yes agreed | 23:36 |
lisitsyn | we don't even have the baseline | 23:36 |
lisitsyn | the algorithms everybody uses | 23:36 |
@HeikoS | yep | 23:36 |
@HeikoS | even worse | 23:36 |
lisitsyn | so that's a helpful rule | 23:36 |
@HeikoS | even developers fail to use existing methods | 23:36 |
@sonney2k | well of course if you set the threshold very high then it will work | 23:37 |
@HeikoS | I would raher go for proper quality | 23:37 |
@sonney2k | HeikoS, that is because ML is complex... | 23:37 |
wiking | quality is one thing | 23:37 |
wiking | but as lisitsyn pointed out | 23:37 |
@sonney2k | and you need to be an expert in using the methods | 23:37 |
@sonney2k | HeikoS, if you don't know about SVMs you will fail using them | 23:37 |
@sonney2k | no matter what | 23:37 |
@HeikoS | sonney2k: I dont agree on that | 23:37 |
wiking | 2 things are needed: a) somehow be able to scale. or target embedded environment, but we already failed that with this codebase | 23:38 |
wiking | b) start having some really basic ML methods as well ;P | 23:38 |
@sonney2k | wiking, libshogun runs on an iphone ... | 23:38 |
wiking | sonney2k: it does | 23:38 |
wiking | i know | 23:38 |
wiking | have u tried to run a classification? | 23:38 |
@sonney2k | for what task? | 23:39 |
wiking | sonney2k: liblinear | 23:39 |
wiking | so i'm not asking to be able to train | 23:39 |
@sonney2k | that is the algorithm | 23:39 |
wiking | just to be able to classify | 23:39 |
@sonney2k | yes so? | 23:39 |
lisitsyn | it is all performance <-> scalabilty tradeoff | 23:39 |
@HeikoS | guys, what do you think on a priority list? | 23:39 |
lisitsyn | I can already say we are not going to be remarkable among scalable solutions | 23:40 |
@sonney2k | wiking, it is very fast and lean yes | 23:40 |
wiking | and that's another question. if we want embedded code then we should be able to throw out half of the library somehow since nobody expects to be able to run training on an embedded device. only classification | 23:40 |
wiking | sonney2k: it's a shit :) | 23:40 |
@sonney2k | lisitsyn, what is scalable for you | 23:40 |
@sonney2k | wiking, nope faster than liblinear | 23:40 |
wiking | sonney2k: we don't use any part of iphone's arm processor | 23:40 |
@HeikoS | why do we even care about iphones? | 23:40 |
lisitsyn | sonney2k: what runs on multiple machines | 23:40 |
wiking | just the simple fucking x86 asm instruments | 23:40 |
@HeikoS | shogun is scientific software | 23:40 |
wiking | no NEON optimization | 23:41 |
@HeikoS | anyone who wants to do commercial stuff uses another package anyways | 23:41 |
@sonney2k | wiking, we use blas / lapack / atlas - so yes we do if you have dense features | 23:41 |
@sonney2k | HeikoS, I don't personally care | 23:41 |
@sonney2k | HeikoS, I need shogun to do rapid prototyping | 23:41 |
wiking | a simple cortexA8 (which is like iphone 1 or 2) has some really good asm instruments that we dont exploit at all | 23:41 |
@sonney2k | so I can test algorithms | 23:41 |
lisitsyn | I don't get the point of using iphones though | 23:42 |
-!- iglesiasg [d58f321f@gateway/web/freenode/ip.213.143.50.31] has joined #shogun | 23:42 | |
@sonney2k | and yes scipy and all other solutiosn I tried where way way too slow | 23:42 |
@HeikoS | sonney2k: I try that often too, but I usually find things crashing or I dont understand how to use them | 23:42 |
-!- mode/#shogun [+o iglesiasg] by ChanServ | 23:42 | |
lisitsyn | sonney2k: come on we are *SLOWER* than scikits | 23:42 |
wiking | lisitsyn: well if not embedded target then we need to be able to run on clusters, or at least multicore or gpu | 23:42 |
@sonney2k | lisitsyn, *lol* | 23:42 |
@sonney2k | wiking, the stuff I used doesn't benefit from GPUs at all | 23:43 |
wiking | lisitsyn: currently we are having the typical beginning of 2000s desktop machine target | 23:43 |
lisitsyn | wiking: exactly | 23:43 |
wiking | which was great back then | 23:43 |
lisitsyn | wiking: yes out of time | 23:43 |
lisitsyn | it is not 2013 | 23:43 |
@sonney2k | and yes the stuff I needed uses multiple cores | 23:43 |
wiking | lisitsyn: heheh just as a sidenote: sw from ibm released in 2012 was not supporting utf8 | 23:44 |
lisitsyn | wiking: yes they are in 1980s still I guess | 23:44 |
wiking | 2012 and no utf8... i was about to fucking blow up ibm | 23:44 |
wiking | :) | 23:44 |
@sonney2k | HeikoS, well that we can fix with tests/examples/documentation | 23:44 |
@HeikoS | sonney2k: yes totally | 23:44 |
@HeikoS | I am optimistic :) | 23:44 |
@HeikoS | would just change things a bit | 23:44 |
wiking | sonney2k: ok i understand that what you use specifically does not benefit from gpu | 23:44 |
@sonney2k | I don't see the GPU hype | 23:44 |
@HeikoS | have *.deb packages for people | 23:45 |
@HeikoS | proper webiste | 23:45 |
@HeikoS | tutorial | 23:45 |
wiking | neither from multicores nor from clusters | 23:45 |
@HeikoS | std method working | 23:45 |
wiking | but | 23:45 |
@HeikoS | have nice examples as scikit | 23:45 |
wiking | even if one method woudl benefit from it | 23:45 |
lisitsyn | sonney2k: the trouble is that you don't need the things you needed anymore | 23:45 |
@HeikoS | and continue to extend with cool algorithms | 23:45 |
wiking | we dont even have a the means to implement it in shogun | 23:45 |
lisitsyn | neither do I | 23:45 |
@sonney2k | lisitsyn, I still do | 23:45 |
@HeikoS | I would stay away from GPU and cluster stuff | 23:45 |
@sonney2k | lisitsyn, I cannot train with scikits in 100million on the fly computed feature spaces | 23:45 |
lisitsyn | sonney2k: yes it is not suited for that | 23:46 |
@HeikoS | but use multicore and independent jobs over PBS stuff | 23:46 |
@sonney2k | and I personally don't have a cluster here at home | 23:46 |
@sonney2k | nor a GPU | 23:46 |
lisitsyn | for dense stuff we suck | 23:46 |
@sonney2k | so I cannot test that stuff | 23:46 |
wiking | sonney2k: u still use simple terminal in linux? | 23:46 |
@sonney2k | lisitsyn, where exactly? | 23:46 |
@sonney2k | wiking, no some multicore machine | 23:46 |
@sonney2k | wiking, 512GB memory and 64cores | 23:46 |
@HeikoS | lisitsyn: rather than being fast I also would like to be easy to install | 23:46 |
wiking | i mean really you do not own any machine that has a gpu? | 23:46 |
@HeikoS | I always have to explain people new to shogun about 1hr how to set it up | 23:47 |
wiking | that supports opengl 1.0? | 23:47 |
@sonney2k | wiking, I do but it is faster using the CPU for the algorithms I use | 23:47 |
@sonney2k | like SVMs | 23:47 |
lisitsyn | sonney2k: mainly usability and availability of methods | 23:47 |
wiking | sonney2k: because in that case i'll start asking for donations that we buy you a simple nvidia card ;) | 23:47 |
@sonney2k | wiking, I have one but it is *slower* to use it | 23:48 |
wiking | so you can play doom 3 :) | 23:48 |
wiking | sonney2k: yeah no i get it of course | 23:48 |
wiking | sonney2k: moving around data between memory is slooow | 23:48 |
@sonney2k | exactly | 23:48 |
wiking | and it might even kill the benefit of having gpued algo | 23:48 |
wiking | that's all good | 23:48 |
wiking | don't get me wrong: been there done that | 23:48 |
wiking | but still | 23:48 |
@sonney2k | wiking, you need highly tuned mini-batch algorithms to benefit from GPUs at all | 23:48 |
lisitsyn | guys even samsung S4 has 8 cores already | 23:49 |
wiking | we do not have the FW within shogun to support anything that is multicore or clustered or GPUed | 23:49 |
@sonney2k | lisitsyn, nope 4 cores! | 23:49 |
lisitsyn | and you are still saying it is ok to use 1 core | 23:49 |
lisitsyn | in 2013 | 23:49 |
lisitsyn | it is totally un-ok | 23:49 |
@sonney2k | lisitsyn, shogun uses multiple cores since 1999 | 23:49 |
wiking | sonney2k: how? | 23:49 |
wiking | please tell me | 23:49 |
wiking | and dont tell me to use pthread | 23:50 |
@sonney2k | it is one of the first svm's that does this | 23:50 |
wiking | in 2013 | 23:50 |
wiking | :D | 23:50 |
@sonney2k | sure pthread | 23:50 |
wiking | fuck man | 23:50 |
wiking | that's like great stuff | 23:50 |
wiking | and everything is depending on it | 23:50 |
wiking | but there are new ways (better ways) to do multithread | 23:50 |
@sonney2k | wiking, how? | 23:50 |
lisitsyn | openmp / tbb | 23:50 |
lisitsyn | at least | 23:50 |
wiking | there's a good reason why people invented openmp | 23:50 |
@sonney2k | you cannot cancel an openmp job without killing the whole process | 23:51 |
@sonney2k | with pthreads you can still intervene | 23:51 |
@sonney2k | ever trained on massive datasets with shogun? | 23:51 |
@sonney2k | I did? | 23:51 |
wiking | sonney2k: but it takes like 10x more time to do a simple parallel for loop with ONLY pthread | 23:51 |
wiking | than openmp | 23:51 |
wiking | and that's the smallest thing | 23:51 |
lisitsyn | what I don't like in such verbose things | 23:52 |
@sonney2k | yeah but what if you want after a few days of computing just stop the job and get a result? | 23:52 |
lisitsyn | hundreds of lines to do a simple thing | 23:52 |
@sonney2k | with shogun you can just send it a SIGURG and you get it | 23:52 |
lisitsyn | and often repeated | 23:52 |
@sonney2k | lisitsyn, I know | 23:52 |
lisitsyn | it is unsupportable | 23:52 |
@sonney2k | I don't like that either | 23:52 |
lisitsyn | life is too short and we are too busy to have so many LoC | 23:52 |
@sonney2k | but openmp is not done well :/ | 23:53 |
wiking | sonney2k: i mean using today pthread for multicore | 23:53 |
wiking | is like writing mmx and sse2 code | 23:53 |
wiking | in asm | 23:53 |
@sonney2k | wiking, c'mon stop wining openmp uses pthreads too | 23:53 |
@sonney2k | true | 23:53 |
wiking | for exploiting SIMD | 23:53 |
wiking | in your cpu | 23:53 |
wiking | and dont get me wrong | 23:53 |
wiking | i did that | 23:53 |
@sonney2k | wiking, that is what eigen3 and atlas people are doing | 23:54 |
@sonney2k | wiking, me too | 23:54 |
wiking | because actually it was better the way i wrote the asm (better = faster) than start fukcing around with gcc optimization flags and using the intristrics header | 23:54 |
wiking | (or how the fuck you call it) | 23:54 |
lisitsyn | eigen3 is actually not more the performance thing | 23:54 |
wiking | but then again | 23:54 |
lisitsyn | GCC optimizes it the same way usually | 23:54 |
wiking | it's a fucking pain in this | 23:54 |
wiking | *ass | 23:54 |
lisitsyn | but loops is useless LoC | 23:54 |
@sonney2k | wiking, nowadays the compiler does it almost as good | 23:54 |
lisitsyn | which are = bugs | 23:54 |
wiking | sonney2k: yeah i know but still... | 23:55 |
wiking | that wasn't the point | 23:55 |
wiking | the point was that our codebase is like blowing up | 23:55 |
wiking | github can tell stats about it for sure | 23:55 |
wiking | how much each month | 23:55 |
wiking | but if we want to support multicore for one simple little algo | 23:55 |
wiking | we start to blow up even more our codebase | 23:55 |
wiking | because it's a fucking nightmare to write with only pthread | 23:56 |
wiking | no no true | 23:56 |
wiking | it's nice and clean etc | 23:56 |
wiking | but huge amount of code redundancy | 23:56 |
wiking | for sure and a lot of waste of time... | 23:56 |
wiking | and yes as you pointed out openmp has it's drawbacks | 23:57 |
@sonney2k | wiking, https://www.ohloh.net/p/shogun | 23:57 |
@sonney2k | here you see how our code base grows | 23:57 |
wiking | but i think it has a lot of pros as well | 23:57 |
-!- hushell [~hushell@8-92.ptpg.oregonstate.edu] has joined #shogun | 23:57 | |
wiking | to start actually fucking at least recognise with ./configure if we have openmp support | 23:57 |
wiking | ;) | 23:57 |
wiking | i mean if we can have one... | 23:57 |
lisitsyn | well we already have openmp code | 23:58 |
lisitsyn | in tapkee | 23:58 |
lisitsyn | but it is not used in shogun | 23:58 |
wiking | sonney2k: so in ~1 year we got 100k LoC | 23:58 |
lisitsyn | so just disabled | 23:58 |
wiking | extra i mean | 23:58 |
wiking | and imagine we start thinking about doing some fancy multicore stuff for some of the algos using oooonly pthread | 23:59 |
wiking | that's +30k LoC | 23:59 |
wiking | easy | 23:59 |
wiking | :) | 23:59 |
--- Log closed Fri Jun 07 00:00:18 2013 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!