| --- Log opened Mon Mar 06 00:00:14 2017 | ||
| --- Day changed Mon Mar 06 2017 | ||
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 00:00 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 00:05 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 00:32 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 00:37 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 00:46 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 00:51 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 01:02 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 01:07 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 01:33 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 01:38 | |
| @wiking | CaBa, hi | 01:40 |
|---|---|---|
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 02:04 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 02:08 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 02:36 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 02:41 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 03:22 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 03:27 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 03:53 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 03:53 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 03:55 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 03:57 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 04:03 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 04:03 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Client Quit] | 04:03 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 04:03 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Client Quit] | 04:05 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 04:05 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 04:14 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 04:15 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 04:22 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 04:22 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 04:24 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 04:28 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 04:30 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 04:30 | |
| shogun-buildbot | build #5 of nightly jessie deb is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly%20jessie%20deb/builds/5 | 04:33 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 04:56 | |
| shogun-buildbot | build #6 of nightly jessie deb is complete: Failure [failed dput] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly%20jessie%20deb/builds/6 | 04:57 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 05:00 | |
| shogun-buildbot | build #8 of nightly jessie deb is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly%20jessie%20deb/builds/8 | 05:10 |
| shogun-buildbot | build #9 of nightly jessie deb is complete: Failure [failed dput] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly%20jessie%20deb/builds/9 | 05:22 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 05:26 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 05:27 | |
| shogun-buildbot | build #10 of nightly jessie deb is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly%20jessie%20deb/builds/10 | 05:28 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 05:28 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 05:32 | |
| -!- mikeling [uid89706@gateway/web/irccloud.com/x-xdeahjqiddqpshoo] has quit [Quit: Connection closed for inactivity] | 06:00 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 06:00 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 06:05 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 06:45 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 06:50 | |
| @sukey | Issue #3678 "LD_LIBRARY_PATH failed in finding .dylib with macOS 10.12" opened by cullengao - https://github.com/shogun-toolbox/shogun/issues/3678 | 07:11 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 07:16 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 07:21 | |
| @sukey | Issue #3678 "LD_LIBRARY_PATH failed in finding .dylib with macOS 10.12" closed by vigsterkr - https://github.com/shogun-toolbox/shogun/issues/3678 | 07:23 |
| -!- mikeling [uid89706@gateway/web/irccloud.com/x-stivvlifoncsnvft] has joined #shogun | 07:32 | |
| mikeling | wiking: hi, do you still around? | 07:32 |
| @wiking | yes | 07:32 |
| mikeling | wiking: due to my comment in https://github.com/shogun-toolbox/shogun/pull/3641#issuecomment-281281455, do you think we should refactor cover tree class a little bit? | 07:33 |
| @wiking | which part do you refere? | 07:33 |
| @wiking | *refer | 07:33 |
| @wiking | sorry i'm a bit out of context | 07:34 |
| mikeling | wiking: hmmm, actually, I'm not sure. I just 'guess' the memory leaking happened in some place in the cover tree itself....like forget to free a memory it alloc to some pointer | 07:38 |
| mikeling | I found JLCoverTree is actually using struct rather than class. So I'm wondering | 07:39 |
| @wiking | mikeling, struct is the same as class | 07:39 |
| @wiking | only difference | 07:39 |
| @wiking | is the member values scope | 07:39 |
| @wiking | in the default visibility | 07:40 |
| @wiking | but where did you see mem leak? | 07:41 |
| mikeling | wiking: after this https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/multiclass/KNN.cpp#L191 line been executed | 07:43 |
| @wiking | and that's only when you use cover tree? | 07:45 |
| mikeling | I leave most of valgrind output in https://github.com/shogun-toolbox/shogun/pull/3641#issuecomment-281281455 | 07:45 |
| mikeling | yep | 07:45 |
| @wiking | mmm | 07:45 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 07:47 | |
| @wiking | yeah | 07:49 |
| @wiking | mikeling, this obviously leaks | 07:49 |
| mikeling | ah? | 07:49 |
| @wiking | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/multiclass/CoverTreeKNNSolver.cpp#L25-L28 | 07:49 |
| @wiking | these 2 v_array's content | 07:50 |
| @wiking | is never released | 07:50 |
| @wiking | here https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/lib/JLCoverTreePoint.h#L191-L201 | 07:52 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 07:52 | |
| @wiking | the v_array is filled up wiht CJLCoverTreePoint | 07:52 |
| @wiking | but that v_array and it's content is never released | 07:52 |
| @wiking | which causes the leak | 07:52 |
| mikeling | wiking: oh great! I will work on it then | 07:54 |
| mikeling | Thank you for your help | 07:54 |
| mikeling | !\ | 07:54 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 07:55 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 08:00 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 08:11 | |
| shogun-buildbot | build #16 of nightly jessie deb is complete: Failure [failed dput] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly%20jessie%20deb/builds/16 | 08:14 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 08:16 | |
| shogun-buildbot | build #18 of nightly jessie deb is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly%20jessie%20deb/builds/18 | 08:19 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 08:43 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 08:48 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 09:15 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 09:20 | |
| @sukey | Wiki page: Fernando-J.-Iglesias-García edited on shogun-toolbox/shogun by iglesias | 09:27 |
| @sukey | Wiki page: Fernando-J.-Iglesias-García edited on shogun-toolbox/shogun by iglesias | 09:29 |
| @sukey | Wiki page: Fernando-J.-Iglesias-García edited on shogun-toolbox/shogun by iglesias | 09:30 |
| @sukey | Wiki page: Fernando-J.-Iglesias-García edited on shogun-toolbox/shogun by iglesias | 09:31 |
| @sukey | Wiki page: Fernando-J.-Iglesias-García edited on shogun-toolbox/shogun by iglesias | 09:32 |
| @sukey | Wiki page: GSoC_2017_project_swig edited on shogun-toolbox/shogun by iglesias | 09:32 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 09:47 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 09:51 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 10:18 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 10:22 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 10:50 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 10:55 | |
| -!- norpi [~norbert.b@540391D6.catv.pool.telekom.hu] has joined #shogun | 11:00 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 11:06 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 11:10 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 11:22 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 11:26 | |
| -!- suhas2go [uid201652@gateway/web/irccloud.com/x-ervcghqajlnwbrpo] has quit [Quit: Connection closed for inactivity] | 11:26 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 11:53 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 11:57 | |
| CaBa | wiking: that octave unit test - does that generally fail right now or is it related to my changes? | 11:58 |
| CaBa | 30 - integration_meta_octave-multiclass_classifier-random_forest (OTHER_FAULT) | 11:58 |
| CaBa | 128 - generated_octave-multiclass_classifier-random_forest (OTHER_FAULT) | 11:58 |
| @wiking | CaBa, unrelated | 12:01 |
| CaBa | 👍 | 12:06 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 12:14 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 12:18 | |
| -!- norpi [~norbert.b@540391D6.catv.pool.telekom.hu] has quit [Ping timeout: 260 seconds] | 12:24 | |
| -!- norpi [~norbert.b@540391D6.catv.pool.telekom.hu] has joined #shogun | 12:33 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 12:45 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 12:51 | |
| -!- suhas2go [uid201652@gateway/web/irccloud.com/x-uauhmkxdbtsokwjl] has joined #shogun | 12:56 | |
| -!- norpi [~norbert.b@540391D6.catv.pool.telekom.hu] has quit [Ping timeout: 260 seconds] | 13:17 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 13:18 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 13:22 | |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun | 13:48 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 13:48 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 13:50 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 13:55 | |
| -!- lambday [6a3316ec@gateway/web/freenode/ip.106.51.22.236] has joined #shogun | 14:02 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 14:02 | |
| CaBa | HeikoS: hola | 14:09 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 14:22 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 14:26 | |
| @HeikoS | CaBa: jojo | 14:29 |
| @HeikoS | wiking: tell me when I shoulud ask everyone in the lab to start instances | 14:33 |
| @wiking | not yet | 14:33 |
| @wiking | i need shogun functionality to be tested | 14:33 |
| @HeikoS | kk | 14:35 |
| @HeikoS | just started a wasteful job | 14:35 |
| @HeikoS | notebook | 14:35 |
| @HeikoS | seems like a fast instance | 14:35 |
| @wiking | ok cool | 14:37 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 14:54 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 14:59 | |
| @wiking | HeikoS, ping | 15:18 |
| @HeikoS | wiking: pong | 15:18 |
| @wiking | HeikoS, ok so | 15:19 |
| @wiking | have you tried any simple shit | 15:19 |
| @wiking | with shogun on the cloud? | 15:19 |
| @HeikoS | yes | 15:19 |
| @HeikoS | computing kernel matrices | 15:19 |
| @HeikoS | works | 15:19 |
| @HeikoS | shall I try more | 15:19 |
| @wiking | that's ok | 15:20 |
| @HeikoS | like upload a noteobok | 15:20 |
| @HeikoS | ? | 15:20 |
| @wiking | ah that is simple shit | 15:20 |
| @wiking | that has nothing to do with us | 15:20 |
| @wiking | anyhow | 15:20 |
| @wiking | this shogun in it | 15:20 |
| @wiking | is from today :) | 15:20 |
| @HeikoS | ? | 15:22 |
| @HeikoS | what? | 15:22 |
| @HeikoS | wiking: no I mean to run a complex shogun notebook | 15:22 |
| @wiking | sure | 15:22 |
| @wiking | kill it | 15:22 |
| @wiking | i mean run it and try to kill it | 15:22 |
| @wiking | but it should work | 15:22 |
| @sukey | Pull Request #3670 "LinalgRefactor - enable GPU_WARNINGS switch" synchronized by OXPHOS - https://github.com/shogun-toolbox/shogun/pull/3670 | 15:23 |
| @sukey | Pull Request #3676 "Fix CAlphabet::Clone + unit test" merged by vigsterkr - https://github.com/shogun-toolbox/shogun/pull/3676 | 15:23 |
| @sukey | New Commit "Merge pull request #3676 from lkuchenb/fix/CAlphabetClone | 15:23 |
| @sukey | Fix CAlphabet::Clone + unit test" to shogun-toolbox/shogun by vigsterkr: https://github.com/shogun-toolbox/shogun/commit/0ed97dc96eca42b82134cd8dd2781f9ffce86e29 | 15:23 |
| @HeikoS | wiking: shogun-data is missing | 15:23 |
| @HeikoS | =? | 15:23 |
| @HeikoS | or a link | 15:23 |
| @wiking | yeah i told ya | 15:23 |
| @wiking | :) | 15:23 |
| @HeikoS | okok | 15:23 |
| @wiking | nothing in the thing yet | 15:23 |
| @wiking | will fix this in the next 20 hours | 15:24 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 15:25 | |
| @HeikoS | kk | 15:26 |
| @HeikoS | wiking: great! | 15:26 |
| @sukey | Pull Request #3673 "Bahsically remove that BAHSIC" closed by karlnapf - https://github.com/shogun-toolbox/shogun/pull/3673 | 15:28 |
| @sukey | Pull Request #3673 "Bahsically remove that BAHSIC" reopened by karlnapf - https://github.com/shogun-toolbox/shogun/pull/3673 | 15:28 |
| @sukey | Pull Request #3673 "Bahsically remove that BAHSIC" merged by karlnapf - https://github.com/shogun-toolbox/shogun/pull/3673 | 15:28 |
| @sukey | New Commit "Merge pull request #3673 from shogun-toolbox/feature/aint-bahsic | 15:28 |
| @sukey | Bahsically remove that BAHSIC" to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/ed4829cfd62499874c114db3d9e806bdf55ab8ca | 15:28 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 15:29 | |
| CaBa | HeikoS: '👯 ♂'? ^^ | 15:30 |
| @HeikoS | haha :) | 15:30 |
| CaBa | HeikoS: not sure i get you there ^^ | 15:31 |
| @HeikoS | found this github thing | 15:31 |
| @HeikoS | nevermind | 15:31 |
| CaBa | :D | 15:31 |
| @HeikoS | thanks for the patches | 15:31 |
| @HeikoS | fine to merge | 15:31 |
| @HeikoS | so ping any of the others to press the button | 15:31 |
| @HeikoS | if you valgrinded them | 15:31 |
| CaBa | i didn't actually. can do so. wiking already merged one of them though ;) | 15:32 |
| @wiking | :> | 15:32 |
| CaBa | wiking: why don't you merge stuff yourself btw? ^^ | 15:35 |
| @sukey | Issue #3672 "octave-modular build failed again"- https://github.com/shogun-toolbox/shogun/issues/3672 | 15:36 |
| @sukey | Issue #3672 "octave-modular build failed again" karlnapf added label: "BUG" - https://github.com/shogun-toolbox/shogun/issues/3672 | 15:36 |
| @sukey | Issue #3672 "octave-modular build failed again" karlnapf added label: "cmake" - https://github.com/shogun-toolbox/shogun/issues/3672 | 15:36 |
| @HeikoS | CaBa: we want to have 4 eyes on every merge | 15:38 |
| @HeikoS | CaBa: wiking imposed that on me as I tend to merge too early ;) | 15:38 |
| @wiking | yes | 15:48 |
| @wiking | he does | 15:48 |
| @wiking | :) | 15:48 |
| @HeikoS | there you go ;) | 15:51 |
| @HeikoS | wiking: shall I wait for cloud with numfocus application email? | 15:51 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 15:57 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 16:01 | |
| CaBa | https://files.photomics.org/10fxval.png <- 10-fold parallel xval grilling cpus :) | 16:04 |
| CaBa | Saurabh7_: 👍 | 16:04 |
| -!- HeikoS1 [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has joined #shogun | 16:05 | |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Ping timeout: 260 seconds] | 16:06 | |
| @sukey | Pull Request #3671 "Add averaged perceptron cookbook page" synchronized by geektoni - https://github.com/shogun-toolbox/shogun/pull/3671 | 16:12 |
| @sukey | Pull Request #3671 "Add averaged perceptron cookbook page" merged by karlnapf - https://github.com/shogun-toolbox/shogun/pull/3671 | 16:21 |
| @sukey | New Commit "Merge pull request #3671 from geektoni/patch-10 | 16:21 |
| @sukey | Add averaged perceptron cookbook page" to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/5b126ce90ed6d1f7706e1f25c69b8b5922c73fc2 | 16:21 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 16:29 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 16:33 | |
| -!- Trion [75d7f596@gateway/web/freenode/ip.117.215.245.150] has joined #shogun | 16:37 | |
| -!- Trion [75d7f596@gateway/web/freenode/ip.117.215.245.150] has quit [Client Quit] | 16:37 | |
| @sukey | Pull Request #3679 "Trained models serialization test" opened by micmn - https://github.com/shogun-toolbox/shogun/pull/3679 | 16:53 |
| -!- HeikoS1 [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has quit [Ping timeout: 268 seconds] | 16:55 | |
| -!- travis-ci [~travis-ci@ec2-54-146-219-246.compute-1.amazonaws.com] has joined #shogun | 16:58 | |
| travis-ci | it's Viktor Gal's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/208214868 | 16:58 |
| -!- travis-ci [~travis-ci@ec2-54-146-219-246.compute-1.amazonaws.com] has left #shogun [] | 16:58 | |
| -!- HeikoS [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has joined #shogun | 16:59 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 16:59 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 17:01 | |
| -!- HeikoS [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has quit [Ping timeout: 260 seconds] | 17:04 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 17:06 | |
| -!- kesslerfrost [~textual@2405:204:188:a4fc:1ca4:7d9b:62cd:25d] has joined #shogun | 17:07 | |
| shogun-buildbot | build #138 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/138 blamelist: Giovanni De Toni <giovanni.det@gmail.com>, Heiko Strathmann <heiko.strathmann@gmail.com> | 17:14 |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun | 17:21 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 17:21 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 17:22 | |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Remote host closed the connection] | 17:25 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 17:26 | |
| @sukey | Pull Request #3635 "LinalgRefactor - Memory Transfer Mutex" merged by OXPHOS - https://github.com/shogun-toolbox/shogun/pull/3635 | 17:36 |
| @sukey | New Commit "LinalgRefactor - Memory Transfer Mutex (#3635) | 17:36 |
| @sukey | * atomic gpu transfer methods" to shogun-toolbox/shogun by OXPHOS: https://github.com/shogun-toolbox/shogun/commit/1d3adbe6caa115bad019209a4377d5f2e910f138 | 17:36 |
| -!- OXPHOS [92bd305b@gateway/web/freenode/ip.146.189.48.91] has joined #shogun | 17:36 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 17:44 | |
| -!- travis-ci [~travis-ci@ec2-54-198-226-137.compute-1.amazonaws.com] has joined #shogun | 17:48 | |
| travis-ci | it's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/208216330 | 17:48 |
| -!- travis-ci [~travis-ci@ec2-54-198-226-137.compute-1.amazonaws.com] has left #shogun [] | 17:48 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 17:51 | |
| -!- mikeling [uid89706@gateway/web/irccloud.com/x-stivvlifoncsnvft] has quit [Quit: Connection closed for inactivity] | 17:51 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 18:15 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 18:20 | |
| -!- travis-ci [~travis-ci@ec2-23-20-164-57.compute-1.amazonaws.com] has joined #shogun | 18:33 | |
| travis-ci | it's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/208234000 | 18:33 |
| -!- travis-ci [~travis-ci@ec2-23-20-164-57.compute-1.amazonaws.com] has left #shogun [] | 18:33 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 18:47 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 18:52 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 19:00 | |
| -!- OXPHOS [92bd305b@gateway/web/freenode/ip.146.189.48.91] has quit [Ping timeout: 260 seconds] | 19:02 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 19:05 | |
| -!- indra_ [uid215631@gateway/web/irccloud.com/x-rewajimunujieszs] has quit [Quit: Connection closed for inactivity] | 19:07 | |
| kesslerfrost | i was trying to cmake the shogun with python modular interfaces using -DPythonModular=ON when I got this error | 19:12 |
| kesslerfrost | Could NOT find PythonLibs: Found unsuitable version "2.7.10", but required | 19:13 |
| kesslerfrost | │ is exact version "3.5.2" (found PYTHON_LIBRARY-NOTFOUND) | 19:13 |
| kesslerfrost | │Call Stack (most recent call first): | 19:13 |
| kesslerfrost | │ /usr/local/Cellar/cmake/3.7.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake: | 19:13 |
| kesslerfrost | │376 (_FPHSA_FAILURE_MESSAGE) | 19:13 |
| kesslerfrost | │ cmake/FindPythonLibs.cmake:190 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) | 19:13 |
| kesslerfrost | │ src/interfaces/python_modular/CMakeLists.txt:3 (FIND_PACKAGE) | 19:13 |
| kesslerfrost | does it builds on oython 2.7 only? | 19:14 |
| kesslerfrost | i'm sorry if it wasn't allowed to ask here. | 19:16 |
| @sukey | Pull Request #3666 "added check before ref_count method to avoid buildbot failure" synchronized by lambday - https://github.com/shogun-toolbox/shogun/pull/3666 | 19:18 |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun | 19:18 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 19:18 | |
| -!- zoq [~marcus_zo@urgs.org] has quit [Quit: Lost terminal] | 19:19 | |
| @lambday | HeikoS: yo! https://github.com/shogun-toolbox/shogun/pull/3666/commits/a1a6806dce27ba4b23040e334b4ca6220caa4571 | 19:20 |
| @HeikoS | lambday: jojo | 19:20 |
| @HeikoS | lambday: ah nice! | 19:21 |
| @HeikoS | let me check PR | 19:21 |
| @HeikoS | ah this was open for a while | 19:21 |
| @lambday | HeikoS: yep.. a week | 19:21 |
| @HeikoS | slipped through my mails | 19:21 |
| @HeikoS | so this seems good to merge? | 19:21 |
| @HeikoS | let me read | 19:21 |
| @lambday | HeikoS: let'swait for the buildbot... everything works locally | 19:22 |
| @lambday | even memcheck | 19:22 |
| @HeikoS | ci you mean | 19:22 |
| @lambday | sorry, travis and appvyoer (or whatever... never got the name correct) | 19:23 |
| @lambday | HeikoS: please check the doc for FeaturesUtil::create_merged_copy.. | 19:23 |
| @lambday | is the explanation good enough? | 19:24 |
| @lambday | readability | 19:24 |
| @HeikoS | checking | 19:25 |
| @HeikoS | ok just put some comments, now checking this thing maybe some of them are easy explained | 19:25 |
| @HeikoS | lambday: so my main questions: | 19:26 |
| @HeikoS | why do we need a utils class? why not abstract method? | 19:26 |
| @HeikoS | purely virtual I mean | 19:26 |
| @HeikoS | and then second, create_merged_copy subset behaviour, the original method behaves different, can't we unify this? | 19:26 |
| @lambday | HeikoS: we could have... but we already have a method that does this.. except, it doesn't respect the subset stack of the object it is called on... you told me earlier to create a separate method and class for doing so.. cause if I change the existing behavior, it might break many things | 19:27 |
| @lambday | HeikoS: yeah.. by having a different method.. | 19:28 |
| @lambday | can't think of a good name for that.. | 19:28 |
| @lambday | :( | 19:28 |
| @HeikoS | lambday: so the other method doesnt respect one of the subsets? | 19:28 |
| @lambday | HeikoS: nope | 19:28 |
| @HeikoS | which one | 19:28 |
| @lambday | it directly copies the underlying matrix | 19:28 |
| @HeikoS | let me check api | 19:28 |
| @lambday | HeikoS: check CDenseFeatures<ST>::create_merged_copy(CList*) impl | 19:28 |
| @HeikoS | so the API doesnt talk about this | 19:29 |
| @lambday | HeikoS: yeah, it is kind of misleading | 19:29 |
| @HeikoS | ah man this code | 19:30 |
| @HeikoS | is old :D | 19:30 |
| @lambday | HeikoS: haha :D | 19:30 |
| @lambday | memcpy :D | 19:30 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 19:32 | |
| @sukey | Issue #3680 "Clean up old style error messages" karlnapf added label: "entrance" - https://github.com/shogun-toolbox/shogun/issues/3680 | 19:36 |
| @sukey | Issue #3680 "Clean up old style error messages" karlnapf added label: "Cleanups" - https://github.com/shogun-toolbox/shogun/issues/3680 | 19:36 |
| @sukey | Issue #3680 "Clean up old style error messages" opened by karlnapf - https://github.com/shogun-toolbox/shogun/issues/3680 | 19:36 |
| @HeikoS | lambday: https://github.com/shogun-toolbox/shogun/issues/3680 | 19:36 |
| @HeikoS | lambday: well this implementation is buggy | 19:36 |
| @lambday | HeikoS: shall I merge this txn, if the build succeeds? cleanups can be done later... i can move on to other pending tasks | 19:36 |
| @HeikoS | lambday: it *has* to respect subsets | 19:37 |
| @HeikoS | so it needs a check | 19:37 |
| @HeikoS | like at the other places in dense features | 19:37 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 19:37 | |
| @HeikoS | like in line 268 | 19:37 |
| @HeikoS | http://shogun.ml/api/latest/DenseFeatures_8cpp_source.html | 19:37 |
| @HeikoS | lambday: there it returns the matrix itself when there is no subset, and a copy of the subset otherwise | 19:38 |
| @HeikoS | aaah this is SO bad, since not const | 19:38 |
| @HeikoS | but anyways | 19:38 |
| @HeikoS | so I would not make this mess more messy now | 19:38 |
| @HeikoS | but rather make the method respect subsets if set | 19:38 |
| @HeikoS | (it was only added for mmd I think, so should be safe to check what things are done) | 19:39 |
| @HeikoS | and then unit test | 19:39 |
| @HeikoS | lambday: and tada, shogun got a tiny bit better by your new feature | 19:39 |
| @lambday | HeikoS: alright.. maybe next task is that | 19:39 |
| @HeikoS | this way, adding new stuff just bloats things more | 19:39 |
| @lambday | HeikoS: haha I'd be happier if the kernels work with different kinds of features.. :D | 19:39 |
| @HeikoS | I mean I realise this now, back when I wrote the method, I didnt realise | 19:39 |
| -!- kesslerfrost [~textual@2405:204:188:a4fc:1ca4:7d9b:62cd:25d] has quit [Quit: kesslerfrost] | 19:39 | |
| @HeikoS | but definitely using/adjusting the existing is better in this case | 19:40 |
| @HeikoS | lambday: should be straight forward | 19:40 |
| @lambday | HeikoS: lol if i look at my old code now, I'll cry for two hours before getting myself drunk to death... | 19:40 |
| @HeikoS | lambday: learning is a good think I think | 19:40 |
| @lambday | haha.. | 19:40 |
| @HeikoS | but lets not merge this PR yet | 19:40 |
| @HeikoS | but integrate that part | 19:40 |
| @lambday | HeikoS: it's gonna be too big of a PR if i do that | 19:41 |
| @lambday | it's just one method left.. create_merged_copy | 19:41 |
| @lambday | since we have a task list, shouldn't cause any more delay i presume | 19:41 |
| @HeikoS | what about that CKernel vector thing, remind me | 19:42 |
| @sukey | Issue #3680 "Clean up old style error messages"- https://github.com/shogun-toolbox/shogun/issues/3680 | 19:43 |
| @lambday | HeikoS: umm... creating CKernel instances next to each other in kernel selection algorithm? | 19:43 |
| @lambday | in memory I mean | 19:44 |
| @lambday | ? | 19:44 |
| @lambday | less cache miss | 19:44 |
| @HeikoS | nono I mean the vector<CKernel*> | 19:45 |
| @HeikoS | resulting in a static size_t -> index_t cast | 19:45 |
| @lambday | HeikoS: had I used CDynamicObjectArray, the **usual** way to access this does a SG_REF.. which, with the thread safety and all, is costly.. | 19:46 |
| @lambday | HeikoS: we gotta remove all those cast.. | 19:46 |
| @lambday | HeikoS: which can be done without getting rid of std::vector.. | 19:46 |
| @lambday | HeikoS: and also, the second way to access the element is CDynamicObjectArray::get_underlying_array (or a method whose name is similar to that) and then indexing that ptr... is slower than operator[] of std::vector.. even though not a bottleneck | 19:47 |
| @HeikoS | lambday: ok cool , thanks for the reminder | 19:48 |
| @HeikoS | so what do you suggest? | 19:48 |
| @HeikoS | as std::vector is not the solution unfortunately | 19:48 |
| @HeikoS | at least not as it is now | 19:48 |
| @lambday | HeikoS: I say, for internal purposes, we can rely on trustworthy std::vector.. as long as we don't do dangerous casting.. | 19:48 |
| @HeikoS | well | 19:49 |
| @HeikoS | we do | 19:49 |
| @lambday | it's fast.. and getting better | 19:49 |
| @lambday | main problem of std::vector is that it doesn't go well with our modular interfaces.. | 19:49 |
| @lambday | none of the templated methods can.. | 19:50 |
| @lambday | as long as it's not exposed, should be fine I think | 19:50 |
| @HeikoS | lambday: we can think about such things | 19:50 |
| @HeikoS | but for now, we need to fix that cast problem dont you think? | 19:50 |
| @lambday | casting down is dangerous I agree | 19:50 |
| @lambday | HeikoS: totally | 19:50 |
| @wiking | HeikoS, so u really want that test into unit test (serial) | 19:50 |
| @lambday | so first task should be to remove the castings | 19:50 |
| @lambday | let me check how many of these casting are left | 19:51 |
| @HeikoS | I casted most of them size_t guys to int64_t | 19:51 |
| @HeikoS | which is fine, no problem | 19:51 |
| @HeikoS | BUT | 19:51 |
| @HeikoS | in some cases you use size_t as a loop index | 19:51 |
| @lambday | HeikoS: in KernelManager only | 19:51 |
| @HeikoS | and then index SGVector | 19:51 |
| @HeikoS | and that is problematic | 19:51 |
| @lambday | HeikoS: yeah mixing is dangerous | 19:52 |
| @lambday | totally agree | 19:52 |
| @lambday | shouldn't do that | 19:52 |
| @lambday | if possible, will replace those with SGVector.. | 19:52 |
| @lambday | but don't want to use CDynamicObjectArray for vector<CSGObject*> | 19:52 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/statistical_testing/internals/KernelManager.cpp#L109 | 19:52 |
| @HeikoS | this one is a problem | 19:53 |
| @lambday | yeah grep shows only kernel manager | 19:53 |
| @lambday | shouldn't be too hard to fix that | 19:53 |
| @HeikoS | how can you fix it? | 19:53 |
| @HeikoS | only with runtime check | 19:53 |
| @HeikoS | like restricting the number of kernels added or so | 19:53 |
| @lambday | HeikoS: number of kernels will never be negative.. so uint should be a fine index for that | 19:54 |
| @lambday | let me check where this num_kernels() method is used | 19:54 |
| @HeikoS | lambday: think about it | 19:54 |
| @HeikoS | size_t is uint32 right? | 19:54 |
| @lambday | HeikoS: yeah | 19:54 |
| @lambday | no | 19:55 |
| @HeikoS | so it can store a larger positive number than index_t, which is int32_t | 19:55 |
| @HeikoS | so when that happens | 19:55 |
| @HeikoS | (index_t)m_kernels.size() will give you a negative | 19:55 |
| @lambday | HeikoS: yeah.. which is wrong.. so this method should return size_t | 19:56 |
| @lambday | without casting | 19:56 |
| @HeikoS | nope | 19:56 |
| @HeikoS | because you use it in a loop to index SGVector | 19:56 |
| @lambday | and the method looping through that should have a size_t iter var | 19:56 |
| @lambday | ugh | 19:56 |
| @HeikoS | and what happens with the indexing of SGVector? | 19:56 |
| @lambday | HeikoS: yeah that's bad | 19:56 |
| @HeikoS | yep its pretty bad | 19:56 |
| @HeikoS | I mean I have wanted to change index_t to 64 bit for a while | 19:57 |
| @HeikoS | but that is not the solution for this problem | 19:57 |
| @lambday | HeikoS: two ways (a) don't use SGVector where using index_t is mandatory (b) don't use std::vector where size_t is mandatory ... gotta think which one is better | 19:57 |
| @HeikoS | lambday: exactly | 19:57 |
| @HeikoS | so clearly, as this is shogun framework, which uses SGVector everywhere | 19:57 |
| @HeikoS | std::vector has to go | 19:57 |
| @HeikoS | that is the whole reason for the discussion | 19:58 |
| @lambday | HeikoS: technically it is correct.. any uint32_t should be comfortably casted to int64_t | 19:58 |
| @HeikoS | lambday: not should, it can be casted | 19:58 |
| @lambday | but can't rely on size_t always being uint32-t | 19:58 |
| @HeikoS | lambday: no exactly, we have our own type there | 19:58 |
| @HeikoS | and we need to respect that | 19:58 |
| @HeikoS | we can aim for changing things, but not as a solution for such problems here | 19:58 |
| @lambday | HeikoS: can't use SGVector<WhateverType> without having to specify the template instantiation in SGVector.cpp | 19:59 |
| @HeikoS | ? | 19:59 |
| @lambday | HeikoS: template specialization | 19:59 |
| @HeikoS | why would that help? | 19:59 |
| @lambday | SGVector<CKernel*> is not possible | 19:59 |
| @HeikoS | no | 19:59 |
| @HeikoS | this is why we have | 19:59 |
| @HeikoS | CDynamicObjectArray | 20:00 |
| @HeikoS | exactly this is the reason | 20:00 |
| @lambday | which is not that fast | 20:00 |
| @HeikoS | sure | 20:00 |
| @HeikoS | but the order to resolve things is to fix the messy/buggy stuff first and then fix the speed | 20:00 |
| @HeikoS | so why is there no const fast access operator in dynamic O array? | 20:01 |
| @lambday | HeikoS: so, ideally we should change it to CDynamicObjectArray (of CKernel*) and then try to improve the performance CDynamicObjectArray | 20:01 |
| @HeikoS | lambday: yes exactly | 20:01 |
| @HeikoS | then again, shogun would benefit | 20:01 |
| @HeikoS | while everything is clean | 20:01 |
| @lambday | HeikoS: my point : is CDynamicObjectArray needed for internal stuffs? If I understand correctly, it makes sure that everything works with modular interface.. you have a method that takes a CDynamicObjectArray as a param.. modular works.. but internally, is that the right data structure we should be working on? Why can't we have a DS that stays on stack.. | 20:02 |
| @lambday | like SGVector/SGMatrix | 20:03 |
| @HeikoS | lambday: it is modular exposed that is right | 20:03 |
| @lambday | for internal, we don't need the overhead | 20:03 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 20:03 | |
| @HeikoS | lambday: however, the kernel manager thing is something that should not be internal code in my eyes in the long run. It is something that can be used for example in the MKL framework parts | 20:04 |
| @lambday | if we can avoid the index shit, std::vector seems to be a good choice for internal API | 20:04 |
| @HeikoS | so we should put some effort in embedding it rather than attaching it | 20:04 |
| @lambday | HeikoS: hmm yeah in that case, we should use CDynamicObjectArray | 20:04 |
| @HeikoS | lambday: for now it is internal, so I take your point | 20:04 |
| @HeikoS | but how to resolve the index issue? | 20:04 |
| -!- travis-ci [~travis-ci@ec2-54-146-219-246.compute-1.amazonaws.com] has joined #shogun | 20:04 | |
| travis-ci | it's Pan Deng / Zora's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/208262199 | 20:05 |
| -!- travis-ci [~travis-ci@ec2-54-146-219-246.compute-1.amazonaws.com] has left #shogun [] | 20:05 | |
| @lambday | HeikoS: will have a look.. | 20:05 |
| @lambday | probably that's the last one of these left | 20:05 |
| @HeikoS | lambday: I think it cannot be done at compile time | 20:05 |
| @lambday | HeikoS: will check if I can change the DS | 20:05 |
| @HeikoS | lambday: only runtime, dfor example in the push_back | 20:05 |
| @HeikoS | DS? | 20:05 |
| @lambday | data structure :D | 20:05 |
| @HeikoS | which one? | 20:05 |
| @lambday | where SGVector loops through the index set specified by the std::vector<CKernel*>::size() ... | 20:06 |
| @HeikoS | lambday: so btw | 20:06 |
| @lambday | I agree that mixing data types is dangerous | 20:06 |
| @HeikoS | There is no way around this really | 20:07 |
| @HeikoS | it pops up somewhere | 20:07 |
| @HeikoS | statically typed language | 20:07 |
| @HeikoS | you could use iterator and then the index map somehow works differently | 20:08 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 20:08 | |
| @HeikoS | index map could be a map | 20:08 |
| @HeikoS | that gives you index_t | 20:08 |
| @HeikoS | but man | 20:08 |
| @HeikoS | I think it would be better to actually put effort into things that somehow have a positive backflow into the shogun framework | 20:09 |
| @HeikoS | thinking about something that can be applied shogun wide, and thus improving everything, not just the testing bits | 20:11 |
| @lambday | HeikoS: thinking along these same lines... I think making a separation on the outside API and the internal API shouldn't hurt... many CObject imps are good, but they are designed to work with every other language that are out there.. refactoring namespace shogun and namespace shogun::internal is what I think we can benefit the most from | 20:11 |
| @lambday | as long as we respect the type system | 20:12 |
| @HeikoS | lambday: yeah I agree | 20:12 |
| @HeikoS | but we also dont want to fragment the codebase too much | 20:12 |
| @HeikoS | the same is true for multiple inheritance btw | 20:12 |
| @HeikoS | cant do because of SWIG, creates a mess inside | 20:12 |
| @lambday | that's why we never use it | 20:12 |
| @HeikoS | libshogun and SWIG-API should be more apart from each other | 20:13 |
| @lambday | couldn't agree more | 20:13 |
| @HeikoS | lambday: ok, but this is general talking, no solution for now | 20:13 |
| @lambday | point is - we claim to be the fastest because we use c++... let's use it to its full potential :) | 20:13 |
| @HeikoS | lambday: yes i agree, but this comes after bug free | 20:14 |
| @HeikoS | and after messy convoluted code base | 20:14 |
| @lambday | HeikoS: yeah for now, I'll fix these downcasting thngs | 20:14 |
| @HeikoS | lambday: how? | 20:14 |
| @lambday | HeikoS: let me check the code | 20:14 |
| @lambday | KernelManager is the only place it is left | 20:14 |
| @HeikoS | lambday: well all other static casts are at least (hopefully) not dangerous | 20:15 |
| @HeikoS | (though they are not exactly nice) | 20:15 |
| @HeikoS | the ASSERT catches the critical one | 20:15 |
| @HeikoS | in practice, this will hardly hit | 20:15 |
| @HeikoS | but my point is: let's write nice code | 20:15 |
| @lambday | agreed | 20:15 |
| @HeikoS | so ideally, we want to get rid of all of them | 20:16 |
| @lambday | HeikoS: all of the downcasts I assume.. if it means to get rid of the std::vector, we should | 20:16 |
| @HeikoS | lambday: what about a read only operator for dynamoic O array? | 20:17 |
| @HeikoS | lambday: that is tread safe by default | 20:17 |
| @lambday | HeikoS: if you benchmark it, it's still gonna be slower man.. not claiming that it's gonna be bottleneck of any algorithm | 20:18 |
| @HeikoS | lambday: benchmarking what? | 20:18 |
| @HeikoS | the testing code? or a loop over accessing it many times? | 20:18 |
| @lambday | HeikoS: const CSGObject * CDynamicObjectArray::get_element_read_only() const and std::vector<CSGObject*>::operator[size_t] | 20:19 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 20:19 | |
| @HeikoS | lambday: the context matters | 20:19 |
| @lambday | HeikoS: agreed | 20:19 |
| @HeikoS | so in this context, you think that will change the runtime ? | 20:20 |
| @HeikoS | btw no need for read_only suffix or? | 20:20 |
| @HeikoS | const CSGObject * CDynamicObjectArray::get_element() should be ok? | 20:20 |
| @lambday | HeikoS: depends on how often you're making these calls... remember when we tried something where for each element of a matrix (..like thing) we had a virtual call... and it was shit? | 20:21 |
| @HeikoS | lambday: I remember, but this is a different context | 20:21 |
| @lambday | HeikoS: agreed.. in general, pointer dereferencing adds some overhead, forget virtual methods, if it's on stack, it's faster.. but whether it affects our code or not depends on how often we make that call | 20:22 |
| @lambday | so, for our purpose, this shouldn't make much of a difference | 20:23 |
| @lambday | but if we talk about designing general purpose data structures, we should keep it in mind.. | 20:23 |
| @HeikoS | lambday: what about doing it then, and then thinking about alternatives framework wide? | 20:23 |
| @HeikoS | imo this is something that would make sense to be changed at the roots, not the leaves of shogun | 20:24 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 20:24 | |
| @lambday | HeikoS: so replacing std::vector with CDynamicObjectArray for statistical_testing code | 20:24 |
| @lambday | can we have a dynamic sized array on stack? | 20:25 |
| @HeikoS | i dont know | 20:25 |
| @lambday | C** classes make it compulsory to allocate it on heap | 20:25 |
| @lambday | SG** classes don't | 20:25 |
| @HeikoS | lambday: how many times are these methods called then? | 20:26 |
| @HeikoS | do you have numbers? | 20:26 |
| @HeikoS | when running kernel selection day | 20:26 |
| @HeikoS | say | 20:26 |
| @HeikoS | N,num_folds,num_kernels | 20:26 |
| @HeikoS | as a function of those? | 20:26 |
| @lambday | for each kernel for each iteration, we call KernelManager::kernel_at(size_t) once.. | 20:27 |
| @lambday | shouldn't be a bottleneck | 20:27 |
| @lambday | there are other computationally intensive things going on | 20:27 |
| @lambday | which predominate | 20:27 |
| @lambday | well, maybe a constant factor of the number.. cause we also precompute the matrix... | 20:28 |
| @lambday | as long as the number is 10-20, shouldn't matter | 20:28 |
| @HeikoS | which number? | 20:29 |
| @HeikoS | so how many calls are we talking about | 20:29 |
| @HeikoS | num_kernels * num_folds? | 20:29 |
| @HeikoS | num_null_samples? | 20:29 |
| @lambday | let's see... num_folds = 10 (max), num_iterations = 50, num_kernels = 20.. so 10*50*20*(some const b/w 1~5).. | 20:30 |
| @lambday | HeikoS: actually this is very hypothetical way of saying :D | 20:31 |
| @lambday | I do have some benchmark.. | 20:31 |
| @lambday | let me run it, with and without std::vector.. then we can know | 20:31 |
| @lambday | if it's slow, will perf it.. | 20:31 |
| @HeikoS | lambday: wait | 20:31 |
| @HeikoS | lambday: I mean I was just after some gues | 20:31 |
| @HeikoS | but if you say this is not a bottleneck | 20:32 |
| @HeikoS | then fixing the casting has higher priority | 20:32 |
| @lambday | HeikoS: of course.. | 20:32 |
| @HeikoS | so first that, then some idea how to fix data structures to make them fast, then benchmark | 20:32 |
| @HeikoS | because the current thing has to go anyways | 20:32 |
| @lambday | that's anyway the highest priority.. question is, if we can manage to get rid of the downcasting without removing all the std::vectors, should we prefer to stay with std::vector | 20:33 |
| @HeikoS | I think it would be better to have something applied shogun-wide | 20:33 |
| @HeikoS | and follow our standards here | 20:34 |
| @HeikoS | I know you say it is internal | 20:34 |
| @HeikoS | but in fact it is not really, the kernel manager should be inside shoguns heart | 20:34 |
| @HeikoS | and be used in all multi-kernel stuff | 20:34 |
| @HeikoS | not an extension deep down some plugin | 20:35 |
| @HeikoS | my two cents | 20:35 |
| @lambday | HeikoS: if we expose it, then we **have** to stick with CDynamicObjectArray | 20:35 |
| @HeikoS | no need to expose to SWIG | 20:35 |
| @HeikoS | we can have libshogun data structures no? | 20:35 |
| @lambday | HeikoS: yeah | 20:36 |
| @HeikoS | I like your idea of having a proper C++ framework under the hood and some clean SWIG interface to the outside | 20:36 |
| @lambday | HeikoS: cool.. so how do we do it iteratively? for now, I can get rid of the casting business.. | 20:36 |
| @HeikoS | lambday: yeah get rid of the casts | 20:36 |
| @HeikoS | let me check poroject | 20:36 |
| @HeikoS | I think all the points in there would be good to solve before starting anything else | 20:37 |
| @lambday | HeikoS: yeah I like the under the hood nasty things and outsize polished (and agreeable to other langs) idea.. | 20:37 |
| @HeikoS | lambday: we can work on that in the detox project | 20:37 |
| @HeikoS | and beyond of course | 20:37 |
| @HeikoS | I wanted to bring that up in the hackathon as well | 20:37 |
| @HeikoS | but there is more pressing concerns right now actually ;) | 20:38 |
| @lambday | haha true taht | 20:38 |
| @lambday | that* | 20:38 |
| @HeikoS | lambday: and also | 20:40 |
| @HeikoS | I made some efforts towards bsd | 20:40 |
| @HeikoS | that is also around for ages | 20:40 |
| @HeikoS | and really needs to be resolved | 20:40 |
| @HeikoS | https://github.com/shogun-toolbox/shogun/commit/badc61c9a98d1bbc224b8abef8a9bbc4362e7ef3 | 20:41 |
| @HeikoS | if you got comments | 20:41 |
| @HeikoS | wiking, lisitsyn you around? | 20:42 |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 20:51 | |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Quit: Leaving.] | 20:52 | |
| -!- HeikoS1 [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has joined #shogun | 20:52 | |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has joined #shogun | 20:52 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 20:52 | |
| @HeikoS | lambday: I gotta go now | 20:52 |
| @HeikoS | lambday: let me know how things go | 20:52 |
| @HeikoS | thanks for the discussion | 20:53 |
| @HeikoS | lets turn this into something | 20:53 |
| @HeikoS | like linalg | 20:53 |
| @HeikoS | bye | 20:53 |
| -!- HeikoS1 [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has quit [Read error: Connection reset by peer] | 20:53 | |
| -!- HeikoS1 [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has joined #shogun | 20:53 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 20:55 | |
| @lambday | HeikoS1: will have a look... | 20:56 |
| @lambday | HeikoS1: see you! :) | 20:56 |
| -!- HeikoS [~heiko@untrust-out.swc.ucl.ac.uk] has quit [Ping timeout: 264 seconds] | 20:57 | |
| -!- HeikoS1 [~heiko@eduroam-int-pat-8-21.ucl.ac.uk] has quit [Ping timeout: 240 seconds] | 20:57 | |
| -!- lambday [6a3316ec@gateway/web/freenode/ip.106.51.22.236] has quit [Ping timeout: 260 seconds] | 21:00 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 21:23 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 21:27 | |
| -!- Jagpreet [2f0b83aa@gateway/web/freenode/ip.47.11.131.170] has joined #shogun | 21:32 | |
| Jagpreet | Thankyou. | 21:33 |
| Jagpreet | I want to learn more about Google Summer of Code. | 21:33 |
| Jagpreet | Actually, I am interested in participating in it | 21:34 |
| Jagpreet | I am a fast learner and a ML enthusiast. I am comfortable in working in Python and coding the ML problems | 21:34 |
| -!- Jagpreet [2f0b83aa@gateway/web/freenode/ip.47.11.131.170] has quit [Client Quit] | 21:35 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 21:54 | |
| -!- norpi [~norbert.b@540391D6.catv.pool.telekom.hu] has joined #shogun | 21:55 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 21:58 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 22:15 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 22:19 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 22:47 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] | 22:51 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #shogun | 23:19 | |
| -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] | 23:23 | |
| -!- suhas2go [uid201652@gateway/web/irccloud.com/x-uauhmkxdbtsokwjl] has quit [Quit: Connection closed for inactivity] | 23:56 | |
| --- Log closed Tue Mar 07 00:00:53 2017 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!
