| --- Log opened Tue Jun 07 00:00:29 2016 | ||
| -!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has quit [Quit: Page closed] | 01:34 | |
| shogun-buildbot | build #1015 of nightly_none is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_none/builds/1015 blamelist: Esben Sorig <esben@sorig.eu>, Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 03:04 |
|---|---|---|
| shogun-buildbot | build #13 of clang - thread analysis is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20thread%20analysis/builds/13 blamelist: Esben Sorig <esben@sorig.eu>, Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 03:44 |
| shogun-buildbot | build #12 of clang - undefined behaviour analysis is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/clang%20-%20undefined%20behaviour%20analysis/builds/12 blamelist: Esben Sorig <esben@sorig.eu>, Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 03:48 |
| shogun-buildbot | build #13 of memleak - valgrind is complete: Failure [failed memory check] Build details are at http://buildbot.shogun-toolbox.org/builders/memleak%20-%20valgrind/builds/13 blamelist: Esben Sorig <esben@sorig.eu>, Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 05:36 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 05:53 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 05:53 | |
| @wiking | Saurabh7: ping | 06:07 |
| Saurabh7 | wiking: hi | 06:20 |
| Saurabh7 | ah sent mail sry | 06:29 |
| shogun-buildbot | build #1145 of nightly_default is complete: Failure [failed test notebooks] Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1145 blamelist: Esben Sorig <esben@sorig.eu>, Heiko Strathmann <heiko.strathmann@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 06:32 |
| Saurabh7 | why does memcheck fail, works here on local | 06:33 |
| @wiking | lemme see | 06:33 |
| Saurabh7 | oh it must be opemp thing | 06:33 |
| @wiking | http://buildbot.shogun-toolbox.org/memcheck/20160607-0111.html | 06:33 |
| @wiking | all the generated ones leak | 06:34 |
| @wiking | so that should be fixed... :P i guess it's because of Some<> | 06:34 |
| Saurabh7 | oh yes | 06:34 |
| Saurabh7 | i was looking at the crossvalidation one | 06:34 |
| Saurabh7 | its potentail memmory leak shouldnt be shown failed actually | 06:35 |
| @wiking | mmm | 06:38 |
| @wiking | Saurabh7: what's your valgrind version? | 06:38 |
| Saurabh7 | 3.10.1 | 06:38 |
| Saurabh7 | wiking: i had sent a suppression for this | 06:39 |
| @wiking | valgrind-3.10.0 | 06:39 |
| Saurabh7 | https://github.com/shogun-toolbox/shogun/pull/3138/files | 06:39 |
| @wiking | ah yeah you did | 06:39 |
| @wiking | mmm shall we merge it? | 06:39 |
| @wiking | lemme check it again | 06:39 |
| @wiking | :0 | 06:39 |
| @wiking | ok lets' merge it :) | 06:40 |
| @wiking | boom | 06:40 |
| @wiking | nmmmm what's with our announcment bot | 06:40 |
| Saurabh7 | dont thnk its wokring | 06:41 |
| Saurabh7 | the bot | 06:41 |
| @wiking | mmm irker | 06:41 |
| shogun-buildbot | build #37 of xenial - libshogun is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/37 blamelist: Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 06:50 |
| shogun-buildbot | build #2899 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2899 blamelist: Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 06:50 |
| @wiking | oooh | 06:52 |
| Saurabh7 | xenials not happy :) | 06:52 |
| @wiking | yeah but for a while now... | 06:52 |
| Saurabh7 | fatal error: clapack.h: No such file or directory | 06:52 |
| @wiking | yeah just wondering wtf | 06:53 |
| @wiking | and why on xenial | 06:53 |
| shogun-buildbot | build #28 of FC23 - libshogun - aarch64 is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/28 blamelist: Viktor Gal <vigsterkr@gmail.com>, Saurabh7 <saurabh.mahindre@gmail.com> | 07:28 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 09:27 | |
| shogun-notifier- | shogun: Viktor Gal :develop * 0a829e0 / src/shogun/distributions/Gaussian.cpp,src/shogun/distributions/Gaussian.h: https://github.com/shogun-toolbox/shogun/commit/0a829e0f2080a621249eb62d516ea8e7f8983c59 | 09:27 |
| shogun-notifier- | shogun: Move lapack.h include into implementation | 09:27 |
| @wiking | heheh cool irker came back | 09:27 |
| @wiking | \o/ | 09:27 |
| -!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has quit [Quit: Page closed] | 09:35 | |
| shogun-buildbot | build #2900 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2900 blamelist: Viktor Gal <viktor.gal@maeth.com> | 09:36 |
| shogun-buildbot | build #38 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/38 blamelist: Viktor Gal <viktor.gal@maeth.com> | 09:38 |
| Saurabh7 | looks like somethings horribly worng with LARS | 09:50 |
| @wiking | why? | 09:50 |
| Saurabh7 | wiking: https://gist.github.com/Saurabh7/b0dbd19e9ab7ae06108f9e9b37430f69 | 09:50 |
| Saurabh7 | look at mse at bottom | 09:50 |
| @wiking | yep | 09:51 |
| @wiking | just saw it | 09:51 |
| @wiking | mm | 09:51 |
| @wiking | ok but wait | 09:51 |
| @wiking | Saurabh7: isn't the dataformat of scikit learn the transpose of what shogun expects? | 09:52 |
| @wiking | so like feat_shogun = feat_scikit^T | 09:52 |
| @wiking | ? | 09:52 |
| Saurabh7 | yes | 09:52 |
| @wiking | ah yeah | 09:52 |
| @wiking | i see | 09:52 |
| @wiking | you transpose it | 09:52 |
| Saurabh7 | I think i ran on develop, so its not me :) | 09:53 |
| @wiking | oh man | 09:54 |
| @wiking | this is starting scary | 09:54 |
| @wiking | (checking the implementation) | 09:54 |
| @wiking | // transpose(X) is more convenient to work with since we care | 09:54 |
| @wiking | // about features here. After transpose, each row will be a data | 09:54 |
| @wiking | // point while each column corresponds to a feature | 09:54 |
| @wiking | and there's a nested for loop | 09:54 |
| @wiking | for transposing a matrix | 09:54 |
| @wiking | :9 | 09:54 |
| @wiking | omfg | 09:54 |
| @wiking | Saurabh7: have you seen this? :) | 09:55 |
| @wiking | ok and have you checked the same with your implementation? | 09:56 |
| @wiking | i mean mse | 09:56 |
| Saurabh7 | sry lsot connection for a while | 09:56 |
| Saurabh7 | no i havent | 09:56 |
| @wiking | can u run the same on your own implementation | 09:57 |
| @wiking | ? | 09:57 |
| Saurabh7 | but I just replaced calss and polished a bit | 09:57 |
| @wiking | yep yep | 09:57 |
| Saurabh7 | ok | 09:57 |
| @wiking | and this matrix transpose in the train_machine | 09:59 |
| @wiking | should be replaced | 09:59 |
| @wiking | it's very inefficient | 09:59 |
| @wiking | especially | 09:59 |
| @wiking | that then you transpose it back | 09:59 |
| @wiking | :DDDD | 09:59 |
| @wiking | https://github.com/shogun-toolbox/shogun/pull/3243/files#diff-c0c82dce2edf38481495103b1ecc4174R154 | 09:59 |
| -!- sanuj [~sanuj@223.176.50.213] has joined #shogun | 09:59 | |
| @wiking | sanuj: sent an email | 10:00 |
| sanuj | wiking, yeah saw just now | 10:00 |
| sanuj | my internet is down | 10:00 |
| Saurabh7 | hmm yeah dunno why its transposed in loops | 10:00 |
| sanuj | using phone's internet | 10:00 |
| lisitsyn | wiking: well transpose in eigen3 doesn't transpose the matrix | 10:01 |
| @wiking | lisitsyn: even better :) | 10:01 |
| @wiking | but pluskid just did | 10:01 |
| @wiking | a for () for() transpose of the matrix | 10:01 |
| @wiking | i.e. copy & transpose | 10:02 |
| lisitsyn | wiking: I thought it was for a reason | 10:02 |
| @wiking | and then Saurabh7 now transposing that matrix | 10:02 |
| @wiking | so X^T^T | 10:02 |
| @wiking | yeah i guess it's a reason | 10:02 |
| @wiking | but X^T^T = X | 10:02 |
| @wiking | so we should just not do it :) | 10:02 |
| @wiking | especially not that way | 10:02 |
| @wiking | nested loop + copy | 10:03 |
| lisitsyn | ok ok | 10:03 |
| @wiking | i mean i dont see the point when you double transpose a matrix | 10:03 |
| @wiking | it's lik eNOP | 10:03 |
| @wiking | *like NOP | 10:03 |
| @wiking | or? | 10:03 |
| lisitsyn | y all math code has to be that unreadable :( | 10:03 |
| @wiking | dunno | 10:03 |
| @wiking | Saurabh7: maybe first try without transposing :)))) | 10:04 |
| @wiking | i mean put in the LARS the untransposed data | 10:04 |
| @wiking | like for scikit | 10:04 |
| @wiking | how's the mse then | 10:05 |
| Saurabh7 | wiking: you mean in the Feature object? | 10:08 |
| sanuj | wiking, sent you a mail | 10:09 |
| Saurabh7 | that doesnt work numvec!=num_labels | 10:09 |
| Saurabh7 | ok its the same thing in my implementation | 10:11 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 10:17 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 10:17 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Client Quit] | 10:21 | |
| shogun-buildbot | build #29 of FC23 - libshogun - aarch64 is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/29 blamelist: Viktor Gal <viktor.gal@maeth.com> | 10:21 |
| Saurabh7 | wiking: ha I think its a parameter issue | 10:34 |
| Saurabh7 | our lambda is something else entirely | 10:35 |
| Saurabh7 | sry :) | 10:35 |
| -!- sanuj [~sanuj@223.176.50.213] has quit [Ping timeout: 240 seconds] | 10:46 | |
| -!- sanuj [~sanuj@223.176.50.213] has joined #shogun | 10:59 | |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 11:06 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 11:06 | |
| -!- sanuj [~sanuj@223.176.50.213] has quit [Read error: Connection reset by peer] | 11:13 | |
| -!- sanuj [~sanuj@117.204.255.148] has joined #shogun | 11:28 | |
| sanuj | wohoo, internet is working again | 11:28 |
| sanuj | HeikoS, what's up | 11:28 |
| @HeikoS | sanuj: jo! | 11:30 |
| @HeikoS | sanuj: how are the cookbooks | 11:30 |
| @HeikoS | I fixed the ruby thing | 11:30 |
| @HeikoS | lua doesnt run cookbooks atm | 11:31 |
| @HeikoS | so travis should pass | 11:31 |
| sanuj | i'm mailing you the code for neural net cookbook | 11:31 |
| sanuj | HeikoS, ruby is still failing | 11:31 |
| sanuj | i had rebased and updated the PR a few hrs ago | 11:31 |
| @HeikoS | mmh | 11:32 |
| @HeikoS | link? | 11:32 |
| @HeikoS | can you maybe run it locally? | 11:32 |
| sanuj | HeikoS, okay, let me confirm if i rebased correctly | 11:32 |
| sanuj | yes i have rebased correctly | 11:33 |
| sanuj | HeikoS, https://travis-ci.org/shogun-toolbox/shogun/jobs/135805082 | 11:33 |
| sanuj | it fails for java also | 11:33 |
| @HeikoS | sanuj: ok I have to do more fixes then | 11:34 |
| @HeikoS | sanuj: will do in a bit, have to finish something | 11:34 |
| sanuj | sure | 11:34 |
| Saurabh7 | HeikoS: hi! | 12:00 |
| @HeikoS | Saurabh7: hi! | 12:00 |
| Saurabh7 | HeikoS: ok so I did some becnhmarks | 12:01 |
| Saurabh7 | HeikoS: turns out the paramters we use are really different | 12:01 |
| Saurabh7 | HeikoS: https://gist.github.com/Saurabh7/b0dbd19e9ab7ae06108f9e9b37430f69 | 12:02 |
| Saurabh7 | this is done similar way to the framework | 12:02 |
| @HeikoS | in the benchmark of zoq, we compared against skits lasso right? | 12:04 |
| @HeikoS | ehm | 12:04 |
| Saurabh7 | there are two | 12:04 |
| @HeikoS | the mse | 12:04 |
| @HeikoS | in the notebook | 12:04 |
| Saurabh7 | HeikoS: yes | 12:04 |
| @HeikoS | seems weird | 12:04 |
| Saurabh7 | its due to lambda1 | 12:04 |
| Saurabh7 | early stopping | 12:04 |
| Saurabh7 | when I disable everything | 12:04 |
| @HeikoS | doesnt skit have this? | 12:04 |
| Saurabh7 | N: 500 D: 200 shogun: 334.170427 , mse: 0.000000 | scikit: 2.653387 , mse: 10416.352846 | 12:04 |
| Saurabh7 | not in the interface | 12:05 |
| @HeikoS | we need to compare in a way that both algos make the same number of iterations | 12:05 |
| @HeikoS | (roughly) | 12:05 |
| @HeikoS | Saurabh7: is lars in skit using the same method as in shogun? | 12:05 |
| Saurabh7 | HeikoS: Lars yes | 12:05 |
| Saurabh7 | thehy have lasso which can do diferently | 12:06 |
| @HeikoS | Saurabh7: lets focus on lars | 12:07 |
| @HeikoS | liblinear can do a lasso later, but for now lars | 12:07 |
| Saurabh7 | HeikoS: ok then i will see what no of iters are | 12:08 |
| @HeikoS | Saurabh7: so LassoLars has alpha | 12:08 |
| @HeikoS | and sg has lambda | 12:08 |
| @HeikoS | do they have the same parametrization? | 12:08 |
| Saurabh7 | HeikoS: yes but its Lasso right ? | 12:08 |
| Saurabh7 | no i dont think its same | 12:09 |
| Saurabh7 | lars is this one http://scikit-learn.org/stable/modules/generated/sklearn.linear_model.Lars.html#sklearn.linear_model.Lars | 12:09 |
| @HeikoS | you took care that normalization is the same? | 12:10 |
| @HeikoS | so important are | 12:10 |
| @HeikoS | eps | 12:10 |
| @HeikoS | fit_path | 12:10 |
| @HeikoS | precompute | 12:11 |
| @HeikoS | and the regulariser interpretation | 12:11 |
| @HeikoS | gotta check that all is comparable | 12:11 |
| @HeikoS | and then compare the mse | 12:11 |
| @HeikoS | and only if this is very similar, the time comparison makes sense | 12:11 |
| lisitsyn | can one tl;dr me | 12:12 |
| lisitsyn | what's happening with lars | 12:12 |
| Saurabh7 | lisitsyn: just trying to make a fair comparison | 12:13 |
| lisitsyn | ok cool | 12:13 |
| Saurabh7 | with sickit implementation | 12:13 |
| lisitsyn | why patching it? | 12:13 |
| lisitsyn | is it slow? | 12:13 |
| Saurabh7 | upating with eigen | 12:14 |
| Saurabh7 | lisitsyn: not sure, the comparison itself wasnt fair | 12:15 |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has joined #shogun | 12:19 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 12:19 | |
| @HeikoS | lisitsyn: 1.) make code cleaner (using eigen or linalg) 2.) benchmark against sklearn (need to be fair) | 12:24 |
| @HeikoS | lambday: jo! | 12:24 |
| lisitsyn | HeikoS: thanks | 12:24 |
| @lambday | HeikoS: yo | 12:24 |
| sanuj | lisitsyn, i'm writing doc for Any | 12:27 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 12:27 | |
| lisitsyn | sanuj: ok | 12:27 |
| lisitsyn | cool | 12:27 |
| sanuj | shall i say how we are using it in shogun ? | 12:27 |
| lisitsyn | need help? | 12:27 |
| lisitsyn | no not really | 12:27 |
| sanuj | this should be shogun independent right? | 12:27 |
| sanuj | lisitsyn, and do i make Tag constructor explicit? | 12:27 |
| lisitsyn | yes explicit is better | 12:28 |
| lisitsyn | let me explain why | 12:28 |
| lisitsyn | we could miss some implicit conversion | 12:28 |
| lisitsyn | and it causes hashing | 12:28 |
| sanuj | okay | 12:28 |
| lisitsyn | so we can get some implicit hashing calls | 12:28 |
| lisitsyn | "invisible" for us | 12:29 |
| sanuj | i got it | 12:29 |
| sanuj | inline bool operator==(const BaseTag& first, const BaseTag& second) | 12:29 |
| sanuj | lisitsyn, do i implement it as friend ^ | 12:29 |
| lisitsyn | sanuj: yes maybe | 12:30 |
| lisitsyn | I have no strong opinion on that | 12:30 |
| lisitsyn | but lambday probably had some point ;) | 12:30 |
| sanuj | lisitsyn, okay so follow lambday except the spacing thing :) | 12:30 |
| @lambday | haha spacing should be uniform.. I prefer to follow what's written there in the coding style.. | 12:30 |
| @lambday | in my personal repositories, I *always* use space between operators and operands :D | 12:31 |
| sanuj | yeah | 12:31 |
| sanuj | haha | 12:31 |
| lisitsyn | lambday: sanuj: let me ask you to avoid that for now | 12:32 |
| lisitsyn | because I would get bloody eyes otherwise | 12:32 |
| sanuj | :D | 12:32 |
| sanuj | even i don't like x=y | 12:32 |
| @lambday | lisitsyn: let's update the coding style doc then | 12:32 |
| lisitsyn | lambday: yes pleasse | 12:32 |
| lisitsyn | lets revise it | 12:32 |
| lisitsyn | lambday: I'd suggest leaning towards google code style :D | 12:34 |
| @lambday | lisitsyn: the reason I think it is preferred to use the == operator as a friend is because it allows to do something like 42==the_answer; as well as the_answer==another_answer; | 12:34 |
| lisitsyn | isn't that we're looking to work in? hahah | 12:34 |
| @lambday | (for template <typename T> struct TheAnswer { TheAnswer(T_value) : value(_value) {} T value; }; ) | 12:34 |
| lisitsyn | lambday: ok cool | 12:35 |
| lisitsyn | I hate 42 == something though | 12:35 |
| lisitsyn | :D | 12:35 |
| @lambday | lisitsyn: no it's better.. :D | 12:35 |
| @lambday | if you miss one =, it won't compile :D | 12:35 |
| lisitsyn | it's compile job I believe | 12:35 |
| lisitsyn | compiler | 12:36 |
| @lambday | well, when writing a library we can't be sure about how the users are going to use it.. so better be flexible.. | 12:36 |
| lisitsyn | yes sure | 12:36 |
| sanuj | lambday, oh, so with non friend implementation i can't do "42 == blah" | 12:37 |
| sanuj | only "blah == 42" | 12:38 |
| @lambday | sanuj: compiler horror | 12:38 |
| sanuj | i see | 12:38 |
| @lambday | sanuj: yes | 12:38 |
| @lambday | it is supposed to be commutative | 12:38 |
| @lambday | so we should design it in such a way | 12:38 |
| sanuj | lambday, good point | 12:39 |
| sanuj | lambday, btw i got my passport :D | 12:39 |
| @lambday | sanuj: congratulations :) | 12:39 |
| sanuj | haha | 12:39 |
| @lambday | mithai khilao :P | 12:39 |
| lisitsyn | do you have two passports? | 12:40 |
| sanuj | haha | 12:40 |
| lisitsyn | like internal one and external one? | 12:40 |
| lisitsyn | we do | 12:40 |
| sanuj | lambday, that's what the courier guy said | 12:40 |
| @lambday | lisitsyn: how does THAT work? | 12:40 |
| sanuj | lisitsyn, we have only 1 passport | 12:40 |
| sanuj | thank god for that :P | 12:40 |
| @lambday | sanuj: did you have to bribe somebody? :D | 12:40 |
| lisitsyn | lambday: I use other one once I leave country | 12:40 |
| @lambday | lisitsyn: but it's still Russian passport, right? | 12:41 |
| lisitsyn | lambday: yes https://en.wikipedia.org/wiki/International_passport | 12:41 |
| @lambday | lisitsyn: aha! | 12:41 |
| sanuj | lambday, no :) but i had to spend useless hours in the passport office | 12:41 |
| lisitsyn | lambday: they also put different name for me haha | 12:42 |
| lisitsyn | due to transliteration issues | 12:42 |
| lisitsyn | we kinda don't agree how my name looks like in latin | 12:42 |
| lisitsyn | :D | 12:42 |
| @lambday | lisitsyn: neither do we :D | 12:42 |
| sanuj | lisitsyn, you have latin on your passport? | 12:42 |
| lisitsyn | sanuj: yes international one is in latin so others can read | 12:42 |
| @lambday | sanuj: English IS latin | 12:42 |
| @lambday | xD | 12:43 |
| sanuj | XD | 12:43 |
| lisitsyn | ah that's what you mean | 12:43 |
| lisitsyn | yes I mean latin letters | 12:43 |
| lisitsyn | not cyrillic ones | 12:43 |
| sanuj | lambday, latin is the language of ancient rome :P | 12:43 |
| @lambday | sanuj: haha yeah I know but he was talking about the alphabet I assume :D | 12:44 |
| @lambday | just like arabic numerals :D | 12:44 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 12:44 | |
| @lambday | nobody writes those in arabic | 12:44 |
| sanuj | haha | 12:44 |
| sanuj | correct | 12:44 |
| @lambday | I mean, some people do | 12:44 |
| @lambday | :/ | 12:44 |
| @lambday | arabs | 12:45 |
| sanuj | lambday, how to do the afk thing :P | 12:45 |
| sanuj | i know it has /away in it | 12:45 |
| @lambday | slash me <your status> | 12:45 |
| * lambday snores | 12:45 | |
| @lambday | no space between slash and me | 12:45 |
| sanuj | okay | 12:45 |
| * sanuj going to eat | 12:46 | |
| sanuj | cool! | 12:46 |
| @lambday | sanuj: chai pohey? | 12:46 |
| sanuj | lambday, fruits | 12:46 |
| @lambday | good habit | 12:47 |
| sanuj | :D | 12:47 |
| * sanuj back | 13:02 | |
| @lambday | sanuj: BTW please add documentation for the PR.. it's really important :) this stuff is all new.. | 13:26 |
| sanuj | lambday, yes i'm doing that | 13:26 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has joined #shogun | 13:33 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 13:33 | |
| @wiking | hey | 13:58 |
| @wiking | sanuj: i will check now | 13:58 |
| sanuj | okay | 14:00 |
| @wiking | sanuj: ok so why do you expect python3 work with the interface compiled for python2? | 14:05 |
| sanuj | wiking, because when i manually run them, they fail with python3 and run with python2 | 14:06 |
| sanuj | wiking, and the examples that fail with python3 are also the ones that fail with "make test" | 14:06 |
| @wiking | but helloooooooooooo | 14:08 |
| @wiking | why do you expect anything to work on python3 | 14:08 |
| @wiking | when you compile the interface for python2? | 14:08 |
| @wiking | it's not shogun's fault that python lacks any responsibility for compatibility | 14:08 |
| @wiking | (even amongst patches...) | 14:08 |
| @wiking | if you compile the modular interface for python2 | 14:09 |
| @wiking | you should use python2 for testing | 14:09 |
| @wiking | if you compile it for python3 | 14:09 |
| @wiking | you should use python3 (the very same interpreter, not any python3) for testing | 14:10 |
| -!- HeikoS [~heiko@host-92-0-162-192.as43234.net] has quit [Quit: Leaving.] | 14:10 | |
| sanuj | wiking, i'm just doing "make test" after building shogun | 14:10 |
| sanuj | why are they failing | 14:10 |
| sanuj | i haven't configured anything for it to use python3 (if it is indeed using) | 14:10 |
| sanuj | wiking, ? | 14:12 |
| @wiking | run ctest | 14:12 |
| @wiking | see what it does | 14:12 |
| @wiking | and if you type: python --version | 14:12 |
| @wiking | what's the output | 14:13 |
| sanuj | wiking, i have tried that, it also fails the same test | 14:13 |
| sanuj | output is python 2.7.6 | 14:13 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 14:15 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 14:15 | |
| @wiking | ok so still i dont get where python3 comes into action here | 14:15 |
| @wiking | sanuj: can you pastebin this to me: ctest -R PeriodicKernelTest -VV | 14:15 |
| @wiking | (i mean the output) | 14:15 |
| sanuj | okay | 14:15 |
| -!- besser82_ [~besser82@fedora/besser82] has joined #shogun | 14:17 | |
| -!- mode/#shogun [+o besser82_] by ChanServ | 14:17 | |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 260 seconds] | 14:19 | |
| sanuj | wiking, http://pastebin.com/kyLpUBca | 14:21 |
| -!- besser82_ [~besser82@fedora/besser82] has quit [Ping timeout: 250 seconds] | 14:22 | |
| -!- sanuj [~sanuj@117.204.255.148] has quit [Quit: Leaving] | 14:27 | |
| -!- sanuj [~sanuj@117.204.255.148] has joined #shogun | 14:27 | |
| sanuj | wiking, what do you think? | 14:27 |
| @wiking | mmm moading | 14:30 |
| @wiking | *loading | 14:30 |
| @wiking | mmm | 14:33 |
| @wiking | sanuj: ok so now try a simple python modular test | 14:33 |
| @wiking | any is good | 14:33 |
| @wiking | with -VV | 14:33 |
| -!- besser82_ [~besser82@fedora/besser82] has joined #shogun | 14:36 | |
| -!- mode/#shogun [+o besser82_] by ChanServ | 14:36 | |
| sanuj | wiking, i tried a test which was failing | 14:37 |
| sanuj | http://pastebin.com/Pvh4zRwN | 14:37 |
| sanuj | my PYTHONPATH=/home/sanuj/Projects/shogun_cb/buildpy/src/interfaces/python_modular | 14:38 |
| sanuj | and LD_LIBRARY_PATH=/home/sanuj/Projects/shogun_cb/buildpy/src/shogun | 14:39 |
| @wiking | ah ok | 14:39 |
| @wiking | have you done make install | 14:39 |
| @wiking | to those paths | 14:39 |
| @wiking | but yeah the thing is that in case of python modular | 14:39 |
| @wiking | i had to do make install | 14:40 |
| sanuj | i have done make | 14:40 |
| @wiking | to be able to test | 14:40 |
| @wiking | unfortunatley | 14:40 |
| @wiking | couldn't really hack the env vars in the right way | 14:40 |
| sanuj | okay, let me try make install | 14:40 |
| -!- besser82_ [~besser82@fedora/besser82] has quit [Ping timeout: 258 seconds] | 14:40 | |
| @wiking | but that'll install it to cmake_install_prefix | 14:40 |
| @wiking | that usually by default is /usr/local | 14:40 |
| sanuj | oh | 14:41 |
| @wiking | you can change that though | 14:41 |
| sanuj | but the above paths contains what is required | 14:41 |
| sanuj | _modshogun.so | 14:41 |
| sanuj | and libshogun.so | 14:42 |
| sanuj | so it should work right? | 14:42 |
| @wiking | mmm | 14:42 |
| @wiking | again as said | 14:42 |
| sanuj | wiking, i had done "make install" in a separate build, used it's env variables | 14:43 |
| @wiking | i've tried that way | 14:43 |
| sanuj | still gives the same error | 14:43 |
| @wiking | but for some reason couldn't do it | 14:43 |
| sanuj | wiking, but "make install" also will not work :/ | 14:44 |
| sanuj | wiking, okay so i was wrong about python3 | 14:47 |
| sanuj | only those tests pass which have something like "try: from modshogun import bla" | 14:48 |
| sanuj | i'll just let it be then :/ | 14:48 |
| @wiking | yes | 14:48 |
| sanuj | if "make install" is also not working then i don't see how else to make it work | 14:49 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 14:50 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 14:50 | |
| -!- besser82_ [~besser82@fedora/besser82] has joined #shogun | 14:53 | |
| -!- mode/#shogun [+o besser82_] by ChanServ | 14:53 | |
| -!- sanuj [~sanuj@117.204.255.148] has quit [Ping timeout: 264 seconds] | 15:09 | |
| -!- besser82_ [~besser82@fedora/besser82] has quit [Ping timeout: 258 seconds] | 15:09 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 15:36 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 15:36 | |
| -!- sanuj [~sanuj@117.204.255.148] has joined #shogun | 15:39 | |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 260 seconds] | 15:46 | |
| -!- HeikoS [~heiko@nat-162-194.internal.eduroam.ucl.ac.uk] has joined #shogun | 15:54 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 15:54 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 15:58 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 15:58 | |
| @HeikoS | sanuj: jo | 15:59 |
| @HeikoS | Saurabh7: jo | 15:59 |
| sanuj | hi | 16:00 |
| Saurabh7 | HeikoS: o | 16:00 |
| Saurabh7 | HeikoS: did you see the new results ? | 16:00 |
| @HeikoS | Saurabh7: no, where are they? | 16:00 |
| @HeikoS | sanuj: so I will check the meta example stuff now | 16:01 |
| Saurabh7 | HeikoS: I posted here https://github.com/shogun-toolbox/shogun/pull/3243 | 16:01 |
| sanuj | HeikoS, cool | 16:01 |
| @HeikoS | https://gist.github.com/Saurabh7/b07c65df21a4fe498284a8086fe617b8 | 16:03 |
| @HeikoS | Saurabh7: ^ this one? | 16:04 |
| Saurabh7 | HeikoS: yes | 16:04 |
| @HeikoS | ok | 16:04 |
| @HeikoS | mmh | 16:04 |
| @HeikoS | you know it is really hard to see patterns in this form of presenting in :) | 16:05 |
| @HeikoS | when does shogun loose? | 16:05 |
| Saurabh7 | HeikoS: ok i will clean it up in a bit | 16:05 |
| Saurabh7 | HeikoS: the mse is much better for som reason | 16:05 |
| @HeikoS | Saurabh7: what is the number of relevant features? | 16:05 |
| sanuj | lisitsyn, can you help me in documenting any by commenting in the PR | 16:05 |
| @HeikoS | Saurabh7: did you make sure the regularisation constant is the same? | 16:05 |
| sanuj | not sure what all to document in there | 16:06 |
| @wiking | Saurabh7: plz remove those transpose of a transpose | 16:06 |
| sanuj | and i think you would be able to explain stuff in a better way | 16:06 |
| @HeikoS | Saurabh7: also, does it compute the whole regularisation path? or just one solution? | 16:06 |
| Saurabh7 | HeikoS: I changed the epsilon adding new param | 16:06 |
| @HeikoS | Saurabh7: what makes me a bit suspicious is that the mse is not the same | 16:07 |
| @HeikoS | why would that be for same algorithm and same parameters? | 16:07 |
| @HeikoS | Saurabh7: wiking is right, you can just use eigen for that outer product | 16:08 |
| @HeikoS | Saurabh7: eigen transposes cost nothing | 16:08 |
| @HeikoS | Saurabh7: one more request, can you please in your weekly email say what cookbooks you will do next week in order to avoid conflicts with others? | 16:09 |
| Saurabh7 | yes i dont understand the mse, but the iter are almost the same | 16:09 |
| Saurabh7 | HeikoS: ok | 16:09 |
| @HeikoS | Saurabh7: sometimes people re-write the regularisation parameters | 16:09 |
| @HeikoS | like n*lambda | 16:09 |
| @HeikoS | 1/lambda | 16:09 |
| @HeikoS | n/lambda | 16:09 |
| @HeikoS | all common | 16:09 |
| -!- OXPHOS [9d8b131c@gateway/web/freenode/ip.157.139.19.28] has joined #shogun | 16:16 | |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 16:18 | |
| shogun-notifier- | shogun: Heiko Strathmann :develop * ae0e85a / examples/meta/generator/targets/ruby.json: https://github.com/shogun-toolbox/shogun/commit/ae0e85aef2c97c88c77453e80cfb0b3379c140e4 | 16:18 |
| shogun-notifier- | shogun: fix copy paste errors in ruby static calls | 16:18 |
| @HeikoS | sanuj: I just pushed | 16:18 |
| sanuj | okay | 16:18 |
| @HeikoS | sanuj: made stupid errors before, copy paste, now it should work | 16:18 |
| sanuj | HeikoS, did you see my mail regarding neural net cookbook? | 16:18 |
| @HeikoS | not yet | 16:19 |
| @HeikoS | checking | 16:19 |
| sanuj | okay | 16:19 |
| @HeikoS | OXPHOS: hi | 16:19 |
| @HeikoS | OXPHOS: just pushed another change to meta examples and static calls | 16:19 |
| @HeikoS | ruby should work now | 16:20 |
| OXPHOS | HeikoS: Hi thanks! | 16:20 |
| sanuj | HeikoS, did you merge your PR? | 16:20 |
| sanuj | or waiting for travis? | 16:20 |
| @HeikoS | sanuj: I pushed straight to develop | 16:21 |
| @HeikoS | so you can rebase | 16:21 |
| @HeikoS | works locally | 16:21 |
| sanuj | okay | 16:21 |
| @HeikoS | sanuj: ok | 16:22 |
| @HeikoS | so your listing | 16:22 |
| sanuj | yes | 16:22 |
| @HeikoS | is not swig compatible | 16:22 |
| @HeikoS | this is what I meant yesterday | 16:22 |
| @HeikoS | you cannot directly access members in swig | 16:23 |
| @HeikoS | you have to call methods | 16:23 |
| @HeikoS | i tranlsated the listing | 16:23 |
| @HeikoS | and the ruby version of it runs fine | 16:23 |
| @HeikoS | the commented out stuff doesnt make sense | 16:23 |
| @HeikoS | sanuj: comments? | 16:24 |
| sanuj | HeikoS, when you say listing, you are talking about adding layers to network? | 16:24 |
| @HeikoS | ? | 16:24 |
| @HeikoS | listing = the file you sent | 16:24 |
| @HeikoS | (as it is) | 16:24 |
| @HeikoS | sanuj: maybe lets start again | 16:24 |
| @HeikoS | sanuj: so I have the file, it works, what is the problem? | 16:24 |
| sanuj | HeikoS, how is it working? | 16:25 |
| @HeikoS | sanuj: (should always describe what is wrong "doesnt work" is not useful) | 16:25 |
| sanuj | the translation is fine | 16:25 |
| @HeikoS | sanuj: what doesnt work for you? | 16:25 |
| sanuj | i tried running it in python because cpp did not build(for some reason) | 16:25 |
| sanuj | it gives seg fault | 16:26 |
| sanuj | when i run it in python | 16:26 |
| @HeikoS | this doesnt make sense | 16:26 |
| @HeikoS | but lets start with cpp | 16:26 |
| @HeikoS | whats the problem there? | 16:26 |
| shogun-buildbot | build #2901 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2901 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 16:26 |
| sanuj | HeikoS, i was not able to build cpp so i only checked python | 16:26 |
| @HeikoS | dude, error message please ! | 16:27 |
| @HeikoS | :) | 16:27 |
| sanuj | but when i had tried it last week, i was getting problems with cpp also which i don't remember | 16:27 |
| shogun-buildbot | build #39 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/39 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 16:27 |
| @HeikoS | not sure how to get this across, but I can't help otherwise ;) | 16:27 |
| OXPHOS | lambday: hey thanks for the comments! | 16:27 |
| sanuj | HeikoS, i got "Segmentation Fault" when i ran it in python | 16:27 |
| @HeikoS | no python please | 16:27 |
| sanuj | HeikoS, can you try running it on your local? | 16:27 |
| @HeikoS | lets focus one thing after the other | 16:27 |
| OXPHOS | lambday: dunno where the indentation problems come from..I used tabs and they look just normal in Atom.. | 16:28 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 272 seconds] | 16:28 | |
| @HeikoS | sanuj: so building cpp fails | 16:28 |
| @HeikoS | sanuj: let's check why | 16:29 |
| sanuj | yeah | 16:29 |
| @HeikoS | sanuj: can you try that locally as well please? | 16:29 |
| @HeikoS | I want to show how to solve such problems | 16:29 |
| sanuj | i ran this last week so i don't remember the exact error | 16:29 |
| sanuj | yeah | 16:29 |
| @HeikoS | sanuj: compiler errors are the easiest to fix | 16:29 |
| @HeikoS | sanuj: run it now then | 16:29 |
| @HeikoS | and lets look at it together | 16:30 |
| OXPHOS | HeikoS: hey actually init_random() fails in java and r as well | 16:31 |
| OXPHOS | not sure whether you saw my comments | 16:31 |
| OXPHOS | https://github.com/shogun-toolbox/shogun/pull/3183 | 16:31 |
| sanuj | HeikoS, i did "make build_cpp_meta_examples" but feedforward_net_classification.cpp was not built | 16:31 |
| @HeikoS | sanuj: what does that mean? | 16:32 |
| @HeikoS | "not build" | 16:32 |
| @HeikoS | ? | 16:32 |
| @HeikoS | OXPHOS: will check in a sec | 16:32 |
| sanuj | HeikoS, it mean i don't see an executable with name "feedforward_net_classification" alongside "feedforward_net_classification.cpp" in "buildpy/examples/meta/cpp" | 16:33 |
| sanuj | means* | 16:33 |
| @HeikoS | sanuj: cmake tells which examples it builds | 16:34 |
| sanuj | yes | 16:34 |
| @HeikoS | is it in there or not? | 16:34 |
| sanuj | no it's not | 16:34 |
| sanuj | it got translated but didn't compile | 16:34 |
| sanuj | i'll share the output | 16:34 |
| @HeikoS | sanuj: nono | 16:34 |
| @HeikoS | re-run cmake | 16:34 |
| sanuj | okay | 16:34 |
| @HeikoS | look | 16:34 |
| @HeikoS | if cmake doesnt know it is there (for example you added the .sg listing after running cmake) then it will not attempt to build it (how could it) | 16:35 |
| @HeikoS | so that is not a random error | 16:35 |
| sanuj | okay | 16:35 |
| @HeikoS | when running cmake, it scans for all available meta example listings and adds the make targets | 16:35 |
| @HeikoS | so you have to re-run after adding meta examples | 16:35 |
| sanuj | alright, it's running | 16:36 |
| sanuj | Linking CXX shared library libshogun.so | 16:36 |
| @HeikoS | OXPHOS: I pushed another fix just a moment ago | 16:36 |
| @HeikoS | OXPHOS: this will resolve the ruby fail | 16:36 |
| @HeikoS | OXPHOS: java will still fail (sigh), I have to put a fix for that (working on it atm) | 16:37 |
| @HeikoS | sanuj: and? | 16:37 |
| sanuj | HeikoS, okay, it's build now :) | 16:37 |
| @HeikoS | really? | 16:38 |
| @HeikoS | I get a compile error | 16:38 |
| sanuj | yeah | 16:38 |
| @HeikoS | with the file you sent | 16:38 |
| sanuj | oh, let me update my file | 16:38 |
| OXPHOS | HeikoS: thx! we're making progress ;) | 16:38 |
| -!- arianepaola [~ariane@unaffiliated/arianepaola] has quit [Ping timeout: 258 seconds] | 16:39 | |
| sanuj | HeikoS, i'm also getting error | 16:39 |
| @HeikoS | sanuj: compile error? | 16:39 |
| sanuj | HeikoS, yes, error: no match for ‘operator=’ | 16:40 |
| @HeikoS | yes, so have a think what can cause that | 16:40 |
| @HeikoS | it is a mismatch between Some<X> and X | 16:40 |
| @HeikoS | lisitsyn: are you around? | 16:40 |
| lisitsyn | yes | 16:41 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 16:41 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 16:41 | |
| lisitsyn | whats up | 16:41 |
| @HeikoS | lisitsyn: so with your some | 16:41 |
| @HeikoS | I cannot do this: | 16:41 |
| @HeikoS | auto layers = some<CNeuralLayers>(); | 16:41 |
| @HeikoS | layers = layers->input(num_feats); | 16:41 |
| @HeikoS | where layers->input() returns CNeuralLayers* | 16:41 |
| lisitsyn | in C++? | 16:42 |
| -!- arianepaola [~ariane@unaffiliated/arianepaola] has joined #shogun | 16:42 | |
| @HeikoS | yep | 16:42 |
| sanuj | oh i see | 16:42 |
| OXPHOS | log: 6/6/16 cookbook - multiclass lr and multiclass linear machine - ready to merge. updated linalg benchmark. reloaded cereal save/load methods' names | 16:42 |
| @HeikoS | since Some overloads the = operator | 16:42 |
| lisitsyn | I thought should be possible? | 16:42 |
| lisitsyn | lemme check | 16:42 |
| @HeikoS | error: no match for ‘operator=’ (operand types are ‘shogun::Some<shogun::CNeuralLayers>’ and ‘shogun::CNeuralLayers*’) | 16:42 |
| @HeikoS | layers = layers->input(num_feats); | 16:42 |
| @HeikoS | OXPHOS: thanks ! :) | 16:42 |
| lisitsyn | hmmm | 16:43 |
| lisitsyn | should implement that then | 16:43 |
| @HeikoS | lisitsyn: yep, it is overwriting the old one | 16:43 |
| lisitsyn | can add in a minute | 16:43 |
| @HeikoS | lhs is Some<X>, rhs is X* | 16:43 |
| lisitsyn | yes I get it | 16:43 |
| @HeikoS | cool | 16:43 |
| lisitsyn | should I add one? | 16:43 |
| @HeikoS | lisitsyn: please do | 16:44 |
| sanuj | HeikoS, we should make this work too => network.l2_coefficient = 0.1 | 16:44 |
| @HeikoS | sanuj: you see, we digged a bit, found the error, and a solution is easy to add | 16:44 |
| @HeikoS | just requires a bit of care | 16:44 |
| sanuj | yeah | 16:44 |
| sanuj | okay, i'll record the error properly from next time | 16:45 |
| @HeikoS | sanuj: please try to do exactly this kind of approach when you have problems, just stating something doesnt work really doenst help | 16:45 |
| @HeikoS | cool | 16:45 |
| @HeikoS | sanuj: I am sure mostly you can fix things yourself (or ask for help in fixing them) | 16:45 |
| @HeikoS | especially compiler errors | 16:45 |
| @HeikoS | are really easy | 16:45 |
| @HeikoS | as it exactly tells you what is wrong | 16:45 |
| @HeikoS | OXPHOS: ^ this is also interesting for you | 16:45 |
| sanuj | HeikoS, alright :) | 16:45 |
| @HeikoS | sanuj: ok now for the other thing | 16:45 |
| @HeikoS | these commeted out lines | 16:46 |
| @HeikoS | network.l2_coefficient = 0.1 | 16:46 |
| @HeikoS | as I said, this doesnt work from any swig interface | 16:46 |
| OXPHOS | I see | 16:46 |
| @HeikoS | (or does it) | 16:46 |
| sanuj | HeikoS, what do you mean by swig interface? | 16:47 |
| @HeikoS | sanuj: shogun has two way it can be used in | 16:47 |
| sanuj | it works in target languages like python | 16:47 |
| @HeikoS | sanuj: 1. directly interface with c++ classes | 16:47 |
| @HeikoS | 2.) interface from the modular targets (python,octave,etc) | 16:47 |
| @HeikoS | 2. = swig interface | 16:48 |
| @HeikoS | swig interface = everything defined under "interfaces/modular/*.i" | 16:48 |
| @HeikoS | in particular, 1!=2 | 16:48 |
| sanuj | yeah i know that | 16:48 |
| @HeikoS | so the meta examples work on swig interface | 16:48 |
| @HeikoS | apart from cpp obviously | 16:48 |
| lisitsyn | mehh needs unittest | 16:49 |
| @HeikoS | sanuj: so in swig interface, you cannot directly access member variables | 16:49 |
| @HeikoS | so calls like network.l2_coefficient = 0.1 | 16:49 |
| @HeikoS | are not possible | 16:49 |
| @HeikoS | you can only do that in c | 16:49 |
| @HeikoS | c++ | 16:49 |
| sanuj | not even public member variables | 16:49 |
| @HeikoS | sanuj: so it doesnt make sense to have this in the meta example | 16:49 |
| lisitsyn | well swig can generate some stuff for that | 16:49 |
| sanuj | then we need functions to do it | 16:50 |
| @HeikoS | lisitsyn: do we have that? | 16:50 |
| lisitsyn | not sure | 16:50 |
| lisitsyn | probably disabled | 16:50 |
| @HeikoS | lisitsyn: we shouldn't anyways | 16:50 |
| lisitsyn | yes | 16:50 |
| @HeikoS | sanuj: did you find any modular example that does this? | 16:50 |
| sanuj | HeikoS, i don't think so | 16:50 |
| sanuj | can i add set/get for these variables in the code then? | 16:51 |
| @HeikoS | sanuj: how are things done in the modular example and the notebook? | 16:51 |
| @HeikoS | lisitsyn: let me know once you pushed | 16:51 |
| @HeikoS | sanuj: because that is something you can orient yourself at | 16:52 |
| lisitsyn | HeikoS: yeah finishing unit test | 16:52 |
| @HeikoS | sanuj: they are already using the swig interface | 16:52 |
| @HeikoS | sanuj: so should be translatable 1 to 1 to meta example | 16:52 |
| sanuj | HeikoS, https://github.com/shogun-toolbox/shogun/blob/develop/doc/ipython-notebooks/neuralnets/neuralnets_digits.ipynb | 16:53 |
| sanuj | it has stuff like "net_no_reg.epsilon = 1e-6" | 16:53 |
| @HeikoS | sanuj: aha, so we *do* have this in the python examples | 16:54 |
| @HeikoS | lisitsyn: ^ interesting isn't it? | 16:54 |
| @HeikoS | sanuj: ok, this is why you used it, right? | 16:55 |
| lisitsyn | HeikoS: yes so it works | 16:55 |
| lisitsyn | :D | 16:55 |
| @HeikoS | ok then, it seems our swig configuration actually generates this | 16:55 |
| lisitsyn | yes | 16:55 |
| @HeikoS | lisitsyn: but it shouldn't really | 16:55 |
| @HeikoS | lisitsyn: or do you think it should? | 16:55 |
| @HeikoS | why are these things public anyways? | 16:56 |
| lisitsyn | HeikoS: mistake | 16:56 |
| @lambday | OXPHOS: heya | 16:56 |
| @HeikoS | lisitsyn: ok | 16:56 |
| @lambday | OXPHOS: what's wrong with tabs :P | 16:56 |
| @HeikoS | sanuj: ok, so you stumbled over something that shouldnt be like this | 16:56 |
| @HeikoS | NeuralNetwork.h has its member variables set to public | 16:57 |
| OXPHOS | lambday: hey! no idea but they're just messed up :( | 16:57 |
| @HeikoS | sanuj: I suggest you create an issue "Make NeuralNetwork member varialbes private and fix notebook" | 16:57 |
| @HeikoS | sanuj: and then we need setters | 16:57 |
| @HeikoS | sanuj: should only take a few minutes to send a PR for this | 16:57 |
| @HeikoS | sanuj: but it needs to be separate from the meta example ok? | 16:58 |
| sanuj | alright | 16:58 |
| sanuj | yeah | 16:58 |
| @HeikoS | sanuj: this will all be a thing of the past with your tags btw ;) | 16:58 |
| @HeikoS | soo | 16:58 |
| @HeikoS | but for now we will just add setters | 16:58 |
| OXPHOS | lambday: should we do sg_linalg->set_cpubackend init.cpp? or can we? | 16:59 |
| @lambday | OXPHOS: this should already be done in the constructor of SGLinalg itself | 16:59 |
| @HeikoS | sanuj: btw, the reason why the meta examples dont translate here is that writing to member variables is not in the meta language grammar | 16:59 |
| @lambday | CPU backend should **always** be there | 16:59 |
| @HeikoS | sanuj: so it doesnt parse the .sg listing if you do that | 17:00 |
| OXPHOS | lambday: sure | 17:00 |
| @HeikoS | sanuj: the PR will: 1.) make the members private 2.) add setters for all of them 3.) adjust all unit tests/examples/notebooks to use the setters rather than direct access. | 17:00 |
| @HeikoS | sanuj: mostly copy paste and grep | 17:00 |
| @HeikoS | sanuj: ping me and I can merge it | 17:01 |
| @HeikoS | please check all NN notebooks for this so that we dont introduce more errors in the notebook build | 17:01 |
| sanuj | HeikoS, we just do it for NeuralNets right? | 17:02 |
| sanuj | not any other class? | 17:02 |
| lisitsyn | sanuj: well for any class with public members | 17:03 |
| @HeikoS | sanuj: do it for everything you need in the meta examples | 17:03 |
| lisitsyn | but neural nets is one we know about | 17:03 |
| shogun-buildbot | build #30 of FC23 - libshogun - aarch64 is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/30 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 17:03 |
| @HeikoS | lisitsyn, sanuj I think NeuralNet is fine for now | 17:03 |
| @HeikoS | if you find more (and need them) do them on the fly | 17:03 |
| sanuj | okay | 17:04 |
| @HeikoS | otherwise it is not worth the work now as tags are incoming | 17:04 |
| lisitsyn | we don't have many of these | 17:04 |
| lisitsyn | it happens when people ignore rules :D | 17:04 |
| @HeikoS | lisitsyn: I wonder who merged that class :D:D | 17:04 |
| lisitsyn | yes | 17:04 |
| lisitsyn | double fault | 17:04 |
| lisitsyn | it seems I was like ohh ok lets merge it now or never | 17:05 |
| @HeikoS | yeah | 17:05 |
| @HeikoS | which is good | 17:05 |
| @HeikoS | since otherwise it would not be there | 17:05 |
| lisitsyn | yeah tags are coming :D | 17:05 |
| @HeikoS | ok fixing java meta examples now | 17:05 |
| lisitsyn | I am checking tests now | 17:05 |
| lisitsyn | for = | 17:05 |
| @HeikoS | sanuj: can you do the PR now? | 17:05 |
| @HeikoS | then we can merge and proceed fast | 17:05 |
| sanuj | lisitsyn, can you help with writing doc for any by commenting in my PR | 17:05 |
| lisitsyn | yes | 17:06 |
| sanuj | lisitsyn, you would be able to explain better | 17:06 |
| sanuj | thanks | 17:06 |
| @HeikoS | sanuj: and make sure to start a new branch for it, so that the PR is nice and clean, makes everything go faster | 17:06 |
| sanuj | HeikoS, i'll do it before sleeping | 17:06 |
| sanuj | need to have dinner now | 17:07 |
| @HeikoS | sanuj: great! | 17:07 |
| @HeikoS | ok enjoy your dinner | 17:07 |
| sanuj | yeah | 17:07 |
| sanuj | bye | 17:07 |
| -!- sanuj [~sanuj@117.204.255.148] has quit [Ping timeout: 258 seconds] | 17:11 | |
| @wiking | hmmmz | 17:14 |
| @wiking | HeikoS: pingzoooo | 17:15 |
| shogun-notifier- | shogun: Sergey Lisitsyn :develop * ed0cc9e / src/shogun/base/some.h,tests/unit/base/Some_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/ed0cc9ecd8f3bd26581227827ff57526d34edef8 | 17:15 |
| shogun-notifier- | shogun: Support assignment in Some | 17:15 |
| lisitsyn | HeikoS: here you go ^ | 17:15 |
| @HeikoS | lisitsyn: thanks! | 17:15 |
| @wiking | btw lisitsyn any ideas about the leakage of Some? | 17:15 |
| @HeikoS | wiking: jo | 17:15 |
| lisitsyn | wiking: they can't leak! | 17:15 |
| lisitsyn | :D | 17:15 |
| lisitsyn | ookkk let me check while I am here | 17:16 |
| @wiking | lisitsyn: yeah i know but still | 17:16 |
| @wiking | just teach valgrind to ignore it then | 17:16 |
| lisitsyn | nonono | 17:16 |
| lisitsyn | valgrind is right | 17:16 |
| @wiking | HeikoS: so seems we have 2 new errors on aarch64 | 17:16 |
| @wiking | integration_meta_cpp-classifier-quadratic_discriminant_analysis | 17:16 |
| @HeikoS | wiking: ay | 17:16 |
| @wiking | integration_meta_cpp-regression-support_vector_regression | 17:16 |
| @wiking | i'm gonna see wtf | 17:17 |
| @wiking | in QDA do we use eigne? | 17:17 |
| @HeikoS | dont kno | 17:17 |
| @HeikoS | lemme check | 17:17 |
| @HeikoS | wiking: I mean this is good | 17:17 |
| @HeikoS | since now we catch the error ;) | 17:17 |
| @HeikoS | it was there before but just unnoticed | 17:17 |
| @HeikoS | meta example massively increase coverage | 17:17 |
| @HeikoS | wiking: checked, it is heavy eigen3 | 17:18 |
| lisitsyn | wiking: can you point me to valgrind log please | 17:19 |
| @wiking | lisitsyn: | 17:20 |
| @wiking | http://buildbot.shogun-toolbox.org/memcheck/20160607-0111.html | 17:20 |
| lisitsyn | thanks a lot | 17:20 |
| @wiking | nw | 17:20 |
| @wiking | HeikoS: ok so integration_meta_cpp-regression-support_vector_regression returns 1 | 17:20 |
| @wiking | lemme see the cookbook | 17:20 |
| lisitsyn | wiking: looks like not all objects are leaked.. | 17:21 |
| lisitsyn | intersting | 17:21 |
| @HeikoS | wiking: this is when produced output of cpp meta example doesnt match reference | 17:21 |
| @HeikoS | as in de-serialize reference and run equals() | 17:21 |
| @HeikoS | wiking: might be accuracy in equals | 17:21 |
| @wiking | ok i'll gdb it | 17:22 |
| shogun-buildbot | build #2902 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2902 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 17:23 |
| shogun-buildbot | build #40 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/40 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 17:24 |
| @wiking | btw you know what we should clean up a bit HeikoS & lisitsyn | 17:29 |
| @wiking | lines like these CDenseFeatures< float64_t >* rf = (CDenseFeatures< float64_t >*) m_features; | 17:29 |
| lisitsyn | meh | 17:29 |
| @wiking | i mean why do we care if it's like CDenseFeatures< float64_t > or CDenseFeatures< float32_t > | 17:30 |
| @wiking | ? | 17:30 |
| lisitsyn | yes | 17:30 |
| lisitsyn | wiking: I believe | 17:30 |
| lisitsyn | it should be Features | 17:30 |
| lisitsyn | that's it | 17:30 |
| @wiking | yes | 17:30 |
| @wiking | because like this | 17:30 |
| @wiking | our api allows CFeatures* | 17:31 |
| @wiking | but then actually a lot of preprocessors | 17:31 |
| @wiking | and models | 17:31 |
| @wiking | will only work with CDenseFeatures< float64_t > | 17:31 |
| @wiking | specifically | 17:31 |
| @wiking | not even allowing single precision | 17:31 |
| @wiking | which is like wtf? | 17:31 |
| @wiking | HeikoS: ? | 17:31 |
| @HeikoS | sorry | 17:31 |
| @HeikoS | was fixing stuff | 17:31 |
| @HeikoS | yeah | 17:32 |
| @HeikoS | agreed | 17:32 |
| @HeikoS | clean up needed | 17:32 |
| @HeikoS | and proper desin | 17:32 |
| @HeikoS | same with const actually | 17:32 |
| @HeikoS | preprocessors and const features | 17:32 |
| @HeikoS | we need readonly views on features | 17:32 |
| @HeikoS | that are thread safe | 17:32 |
| @HeikoS | and slicable | 17:32 |
| @HeikoS | in all directions | 17:32 |
| @HeikoS | and then preprocessors need to be readonly (or not) | 17:33 |
| @wiking | yeah but lets not mix that | 17:33 |
| @HeikoS | but currently its all a mix | 17:33 |
| @HeikoS | sure | 17:33 |
| @wiking | i just checked quickly | 17:33 |
| @wiking | there are 59 implementations (classes) | 17:34 |
| @wiking | that use this explicit class | 17:34 |
| @wiking | *cast | 17:35 |
| @HeikoS | wiking: I think we need to think of a proper way to do this | 17:35 |
| @HeikoS | not sure why we use float64_t explicitly everywhere | 17:36 |
| @HeikoS | should be T | 17:36 |
| @HeikoS | but then say eigen | 17:36 |
| @HeikoS | requires MatrixXd or MatrixXf | 17:36 |
| @wiking | yeah but that can be template tested -> generated | 17:36 |
| @wiking | :) | 17:36 |
| @wiking | ugly but works | 17:36 |
| @wiking | and would be better than now... i mean i really dont see the rational | 17:37 |
| @wiking | but many people followed this | 17:37 |
| @wiking | cast it to directly float64_t dense and bye bye | 17:38 |
| @HeikoS | yep | 17:38 |
| @HeikoS | I do that in my prototype code due to the lack of a principled way to solve this problem | 17:38 |
| @wiking | k | 17:39 |
| @HeikoS | templating eigen3 is a good idea | 17:39 |
| @wiking | so lets principalize it | 17:39 |
| @wiking | :D | 17:39 |
| @HeikoS | agreed! | 17:39 |
| @HeikoS | how? | 17:39 |
| @wiking | mmm just checking which pr could be the guinea pig for this | 17:40 |
| @wiking | hah perfecto! | 17:40 |
| @wiking | https://github.com/Saurabh7/shogun/blob/89343af72b5bbc8308d9430c1fbcd379398e037a/src/shogun/regression/LeastAngleRegression.cpp#L118 | 17:40 |
| @wiking | lARS | 17:40 |
| lisitsyn | i hate this boileplate checks | 17:41 |
| @HeikoS | lisitsyn: ? | 17:41 |
| @wiking | i guess he means this https://github.com/Saurabh7/shogun/blob/89343af72b5bbc8308d9430c1fbcd379398e037a/src/shogun/regression/LeastAngleRegression.cpp#L112-L115 | 17:41 |
| @wiking | and the rest aboe | 17:41 |
| lisitsyn | GOSHH | 17:41 |
| @wiking | *above | 17:41 |
| @HeikoS | haha | 17:42 |
| @HeikoS | ok so lets clean up lars | 17:42 |
| @HeikoS | it is being touched already anyways | 17:42 |
| @wiking | mmm btw | 17:42 |
| @HeikoS | though focus of Saurabh7 is performance | 17:42 |
| @wiking | heheh yeah but still | 17:42 |
| @wiking | there are lot of shit there | 17:42 |
| @HeikoS | not sure whether we should distract too much from original goal | 17:42 |
| @HeikoS | yeah I know | 17:43 |
| @wiking | okok let him finish with the fixes | 17:43 |
| @HeikoS | wiking: yeah definitely two step | 17:43 |
| @HeikoS | first: use eigen | 17:43 |
| @wiking | i'm just wondering if let say we could do this with this code | 17:43 |
| @HeikoS | make readable | 17:43 |
| @HeikoS | make fast | 17:43 |
| @wiking | as a guinea pig | 17:43 |
| @HeikoS | and then | 17:43 |
| @HeikoS | we can have macros for eigen types | 17:43 |
| @HeikoS | that are derived from T | 17:43 |
| @wiking | btw lars | 17:43 |
| @wiking | you could calculate the lars of an int32_T or int64_t no? | 17:44 |
| @wiking | i mean yeah you might need int32_t -> float | 17:44 |
| @wiking | but still | 17:44 |
| @HeikoS | for the features, yes | 17:44 |
| @HeikoS | not output | 17:44 |
| @HeikoS | w | 17:44 |
| @HeikoS | is float | 17:44 |
| @HeikoS | but then | 17:44 |
| @HeikoS | features have to be zero mean and unit std-dev | 17:45 |
| @HeikoS | so it doesnt really make sense on non floating point | 17:45 |
| @HeikoS | furthermore | 17:45 |
| @HeikoS | it is not really mem intense | 17:45 |
| @wiking | say if you wanna save memory :P | 17:45 |
| @HeikoS | much earlier the time is out of controll | 17:45 |
| @HeikoS | so 64 bit is fine in fact | 17:45 |
| @HeikoS | kernel algorithms would be better | 17:45 |
| @HeikoS | like nystrom PR | 17:45 |
| @HeikoS | but not sure | 17:46 |
| @wiking | i mean | 17:46 |
| @wiking | this is more in general | 17:46 |
| @HeikoS | yeah | 17:46 |
| @wiking | we could do many many things on integer features | 17:46 |
| @HeikoS | so this should allow for 32 bit at least | 17:46 |
| @HeikoS | i agree | 17:46 |
| @HeikoS | so we can use this as a case | 17:46 |
| @HeikoS | even though it doesnt need int | 17:46 |
| @wiking | yeah | 17:46 |
| @wiking | i mean just to allow it | 17:46 |
| @wiking | of course this is not the best usecase | 17:46 |
| @wiking | just that here we could start setting an example | 17:47 |
| @wiking | and later using the same thing | 17:47 |
| @wiking | eliminate the rest in shogun | 17:47 |
| @wiking | as there's really no need for this limitation in many cases | 17:47 |
| @wiking | (i.e. only dense float64_t features | 17:47 |
| OXPHOS | lambday: there? I have a question | 17:47 |
| @wiking | ) | 17:47 |
| @HeikoS | wiking: absolutely | 17:49 |
| OXPHOS | wiking HeikoS: or any of you is free? you seem to be in the middle of something | 17:50 |
| @HeikoS | wiking: at least it should be easy to switch between 64 and 32 bit | 17:50 |
| @HeikoS | OXPHOS: sure | 17:50 |
| @HeikoS | OXPHOS: just submitted a PR for you java problem | 17:50 |
| @wiking | wazaaaaaaaaaaaa | 17:50 |
| OXPHOS | HeikoS: what to pull? | 17:50 |
| @HeikoS | OXPHOS: not yet, I need to run this through travis first | 17:51 |
| @HeikoS | wiking: we also should do proper out of source builds | 17:51 |
| @HeikoS | this class list drives me mad | 17:51 |
| OXPHOS | HeikoS: ohh you meant you submitted. sry | 17:51 |
| OXPHOS | wiking HeikoS: so I have a method in Linalg, taking CPUbackend instance from outside and set the linalg.cpubackend | 17:51 |
| OXPHOS | void Linalg::set_cpu_backend(const CPUBackend* cpubackend) { m_cpubackend = const_cast<CPUBackend*>(cpubackend); } | 17:52 |
| OXPHOS | wiking HeikoS: is this the appropriate way to use const? | 17:52 |
| OXPHOS | I dont feel good about const_cast actually | 17:52 |
| @wiking | why did you want it to be a const? | 17:52 |
| lisitsyn | I realize this thing I wrote in some.h is absolute on-brainer | 17:52 |
| lisitsyn | :D | 17:52 |
| lisitsyn | no-brainer | 17:52 |
| @wiking | but then again if you want it | 17:52 |
| OXPHOS | wiking: because it should not be changed | 17:53 |
| @wiking | but which shouldn't be changed? :) | 17:53 |
| @HeikoS | lisitsyn: ? | 17:53 |
| OXPHOS | the cpubackend instance? | 17:53 |
| @wiking | but if you const cast it | 17:53 |
| lisitsyn | HeikoS: going to fix now | 17:53 |
| @wiking | then i dont get it... | 17:53 |
| lisitsyn | absolutely wrong | 17:53 |
| @wiking | lisitsyn: miju | 17:54 |
| @HeikoS | lisitsyn: ping sanuj when you pushed it, it will make his nn meta example easier | 17:54 |
| lisitsyn | hok | 17:54 |
| shogun-notifier- | shogun-data: OXPHOS :master * fdf7e4f / testsuite/meta/classifier/multiclass_linearmachine.dat: https://github.com/shogun-toolbox/shogun-data/commit/fdf7e4f7ad9304b1c46a54b1ae3a33b5c0fd0ee0 | 17:54 |
| shogun-notifier- | shogun-data: dataset | 17:54 |
| shogun-notifier- | shogun-data: Heiko Strathmann :master * 6cee872 / testsuite/meta/classifier/multiclass_linearmachine.dat: https://github.com/shogun-toolbox/shogun-data/commit/6cee872ceeca2882fd7e7a13570630371c80238d | 17:54 |
| shogun-notifier- | shogun-data: Merge pull request #97 from OXPHOS/mclm | 17:54 |
| shogun-notifier- | shogun-data: | 17:54 |
| @wiking | OXPHOS: i mean i guess you have Linalg | 17:54 |
| shogun-notifier- | shogun-data: integration dataset for multiclass linearmachine | 17:54 |
| OXPHOS | wiking: so adding a pointer to one instance is also defined "change"? | 17:54 |
| @wiking | which has a m_cpubackend | 17:54 |
| @wiking | that you want it to be changeable right? | 17:55 |
| OXPHOS | yes | 17:55 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has joined #shogun | 17:55 | |
| shogun-notifier- | shogun-data: OXPHOS :master * 14ade7e / testsuite/meta/classifier/multiclass_logisticregression.dat: https://github.com/shogun-toolbox/shogun-data/commit/14ade7e9c7e09b21308d938df69f1638da3e6b90 | 17:55 |
| shogun-notifier- | shogun-data: dataset | 17:55 |
| shogun-notifier- | shogun-data: Heiko Strathmann :master * 7d80262 / testsuite/meta/classifier/multiclass_logisticregression.dat: https://github.com/shogun-toolbox/shogun-data/commit/7d802620d7267d45d6db77f96e6dd5dcc3d5d320 | 17:55 |
| shogun-notifier- | shogun-data: Merge pull request #95 from OXPHOS/mclr | 17:55 |
| shogun-notifier- | shogun-data: | 17:55 |
| shogun-notifier- | shogun-data: integration test dataset for multiclass logistic regression | 17:55 |
| c4goldsw | Hello | 17:55 |
| @HeikoS | c4goldsw: hi there | 17:55 |
| OXPHOS | c4goldsw hi | 17:55 |
| @HeikoS | sorry I havent given feedback yet, still fighting with the weekend of emails (and necessary fixes for the gsoc guys) | 17:56 |
| c4goldsw | HeikoS It's fine, I just thought I'd pop on. Just spent the day finishing off a project. | 17:56 |
| c4goldsw | OXPHOS Hey | 17:56 |
| OXPHOS | wiking: the *cpubackend in param list should be something independent of linalg, maybe just a cpu algebra lib other than eigen3 | 17:57 |
| @HeikoS | c4goldsw: cool | 17:57 |
| @HeikoS | c4goldsw: btw, we might have another nice task to start with getting involved in shogun | 17:57 |
| @HeikoS | wiking: maybe c4goldsw can have a look at this casting thing | 17:57 |
| c4goldsw | Cool! | 17:57 |
| @wiking | HeikoS: heheh :) | 17:58 |
| @HeikoS | c4goldsw: there is a conversation between wiking and me about explicit numerical types and that we dont really want that | 17:58 |
| @wiking | OXPHOS: i mean i wouldn't do this const casting | 17:58 |
| @HeikoS | maybe read it and see whether you understand what we want | 17:58 |
| @wiking | just pass on the cpu backend and that's all | 17:58 |
| c4goldsw | Like having to specify types all the time such as float64_t? | 17:58 |
| -!- sanuj [~sanuj@117.204.255.148] has joined #shogun | 17:59 | |
| OXPHOS | wiking: then it gave error: assigning to 'shogun::CPUBackend *' from incompatible type 'const shogun::CPUBackend *' m_cpubackend = cpubackend; | 17:59 |
| @wiking | c4goldsw: do a git grep "(CDenseFeatures<float64_t>*)"|cut -d':' -f1|uniq | 17:59 |
| @wiking | in src/shogun | 17:59 |
| @wiking | i meant | 18:00 |
| @wiking | remove the const from the function arg as well | 18:00 |
| @wiking | so you have set_cpubackend(shogun::CPUBackend * backend) { m_cpubackend = cpubackend; } | 18:00 |
| c4goldsw | wiking I'm on Windows, I have to boot into Unix first to get to the source files. | 18:01 |
| c4goldsw | Ubuntu* | 18:01 |
| c4goldsw | brb | 18:01 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 18:01 | |
| OXPHOS | wiking: okay then. thanks! | 18:01 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has joined #shogun | 18:02 | |
| c4goldsw | wiking back, could you paste that command again please? | 18:02 |
| OXPHOS | HeikoS: thx for the merge! there's also R error caused by init_random() actually.. | 18:02 |
| @wiking | c4goldsw: if you use bash it shoudl be | 18:03 |
| @wiking | git grep "(CDenseFeatures<float64_t>*)"|cut -d':' -f1|uniq | 18:03 |
| @wiking | in src/shogun | 18:03 |
| c4goldsw | I do, typing it in. | 18:04 |
| @wiking | copypqste | 18:04 |
| @wiking | :> | 18:04 |
| @wiking | if it doesn't work | 18:04 |
| c4goldsw | (I meant that) | 18:04 |
| @wiking | espace the * | 18:04 |
| @wiking | so git grep "(CDenseFeatures<float64_t>\*)"|cut -d':' -f1|uniq | 18:04 |
| c4goldsw | I got a list of .cpp files | 18:04 |
| @wiking | yeah | 18:04 |
| @wiking | so here if you check the src | 18:05 |
| @wiking | you'll find similar lines like | 18:05 |
| OXPHOS | HeikoS: Error: unexpected '$' in "Math$$" Execution halted (R) | 18:05 |
| @wiking | SGMatrix<float64_t> feature_matrix = ((CDenseFeatures<float64_t>*)features)->get_feature_matrix(); | 18:05 |
| @wiking | or just like | 18:05 |
| @wiking | CDenseFeatures<float64_t>* lhs = (CDenseFeatures<float64_t>*)features | 18:05 |
| @wiking | so the problem with this | 18:06 |
| @wiking | that even though int he api of the function we claim it supports CFeatures* features | 18:06 |
| @wiking | that given class will only work with dense double features | 18:06 |
| @wiking | so not even dense float (single precision) features will work | 18:07 |
| @wiking | for no reason | 18:07 |
| c4goldsw | so only float64, right? | 18:07 |
| @wiking | yeah | 18:07 |
| @wiking | whereas whatever that supports float64_t | 18:07 |
| @wiking | should be able to be supported with float32_t | 18:07 |
| @wiking | and more | 18:07 |
| c4goldsw | Alright, that sounds like a reasonable task. | 18:08 |
| shogun-buildbot | build #31 of FC23 - libshogun - aarch64 is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/31 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 18:08 |
| @wiking | and of course | 18:08 |
| @wiking | even densefeatures<int**> would make sense | 18:08 |
| @wiking | sometimes | 18:08 |
| c4goldsw | In what cases? I was actually wondering when integers would be useful in ML. | 18:09 |
| @HeikoS | OXPHOS: solved the R problem | 18:09 |
| @wiking | and it should be checked whether really the same thing couldn't be done for sparse features? | 18:09 |
| @wiking | c4goldsw: from memory/speed point of view yes | 18:09 |
| @HeikoS | OXPHOS: pushing, just a sec | 18:09 |
| @wiking | integer arithmetic is faster than float | 18:09 |
| @lambday | OXPHOS: heya | 18:09 |
| c4goldsw | Makes sense - could there be imprecision though? | 18:09 |
| c4goldsw | wiking ^ | 18:09 |
| OXPHOS | HeikoS: thanks. no rush. just letting u know | 18:09 |
| @wiking | yeah | 18:10 |
| c4goldsw | precision loss* | 18:10 |
| @HeikoS | OXPHOS: I want to get these out of the way asap, so that you guys are not blocked | 18:10 |
| @wiking | but the user should be aware of that | 18:10 |
| @wiking | when he dfineds the feature to be | 18:10 |
| @wiking | int based | 18:10 |
| c4goldsw | Alright. And another question | 18:10 |
| c4goldsw | Did you meant int * or int ** ? | 18:11 |
| @wiking | i meant | 18:11 |
| @wiking | int8_t, int16_t, int32_t, uint8_t etc | 18:11 |
| @wiking | :) | 18:11 |
| c4goldsw | haha okay, makes sense. | 18:11 |
| @wiking | but of course as HeikoS mentioned | 18:12 |
| @wiking | sometimes it's tricky | 18:12 |
| OXPHOS | lambday: hey. im tryting the BaseVector<int32_t> const * const stuff | 18:12 |
| c4goldsw | wiking for what reasons? | 18:13 |
| @wiking | because we use eigne | 18:13 |
| OXPHOS | lambday: seems as linalg.dot takes non-const pointer, i cannot pass const stuff to it | 18:13 |
| @wiking | and there you have different name for the floating precision for example | 18:13 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 260 seconds] | 18:14 | |
| c4goldsw | wiking: ah, ok. Is this also an issue with the other linalg libraries (e.g. lapack)? | 18:14 |
| @wiking | yeah | 18:14 |
| @wiking | but this should be templated | 18:14 |
| @wiking | hopefully | 18:14 |
| c4goldsw | So that developers won't have to worry about the library being used, correct? | 18:15 |
| @wiking | well the thing is that currently this behaviour | 18:15 |
| @wiking | started from somwhere | 18:15 |
| @wiking | and it got copied to many places | 18:15 |
| @wiking | i.e. explicit casting to dense double features | 18:15 |
| @wiking | the idea is to change this | 18:16 |
| @wiking | at least support single precision floats | 18:16 |
| @wiking | but possibly other features | 18:16 |
| @wiking | woudl even make sense in some cases that to make it work with sparse features | 18:16 |
| c4goldsw | wiking: What do you mean by sparse features? | 18:17 |
| @HeikoS | wiking: yeah sparse +1, though this usually requires totally different algos | 18:17 |
| c4goldsw | as opposed to dense vectors? | 18:17 |
| @wiking | so we have spare features and dense features | 18:18 |
| @wiking | and even thouh say | 18:18 |
| @wiking | shogun/preprocessor/KernelPCA.cpp | 18:18 |
| @wiking | api claims | 18:18 |
| @wiking | that it do the kernel pca on any type of feature | 18:19 |
| @wiking | due to the explicit cast a line 132 | 18:19 |
| @wiking | CDenseFeatures<float64_t>* simple_features = (CDenseFeatures<float64_t>*)features; | 18:19 |
| @wiking | it will only do it with CDenseFeatures<float64_t> features | 18:19 |
| @wiking | it wont work with CDenseFeatures<float32_t> | 18:19 |
| @wiking | nor with CSpareFeatures<float64_t> | 18:20 |
| @wiking | although based on the api | 18:20 |
| @wiking | it should work | 18:20 |
| c4goldsw | That makes sense - I just wanted to clarify | 18:20 |
| @wiking | mmm no | 18:20 |
| @wiking | actually i just told something bs | 18:20 |
| @wiking | (but for GMM it is true) | 18:21 |
| @wiking | so in case of | 18:21 |
| @wiking | kernelPCA | 18:21 |
| @wiking | it is inherited from CDimensionReductionPreprocessor | 18:21 |
| @wiking | which is actually a CDensePreprocessor<float64_t> | 18:21 |
| @wiking | still i dont see the reason | 18:21 |
| @wiking | why a CDimensionReductionPreprocessor can only work on CDensePreprocessor<float64_t> | 18:21 |
| @HeikoS | lisitsyn: still there? | 18:21 |
| @wiking | and why couldn't it work at least on CDensePreprocessor<float32_t> | 18:21 |
| lisitsyn | HeikoS: yeah fixing that stuff :D | 18:22 |
| @HeikoS | lisitsyn: multiclass logistic regression, is that based on using a std logistic regression solver and then doing OvO using shogun? | 18:22 |
| @HeikoS | lisitsyn: or how does it work? | 18:22 |
| lisitsyn | uhmmm I think its OvR | 18:22 |
| @HeikoS | lisitsyn: ok | 18:22 |
| @HeikoS | but the slep solver doesnt do that right? | 18:23 |
| @HeikoS | but you do manually | 18:23 |
| @wiking | c4goldsw: same for shogun/preprocessor/SumOne.cpp | 18:23 |
| c4goldsw | wiking: Ok, this makes sense. With sparse features, I just wanted to clarify that you're suggesting that other less memory demanding data types (like int) are preferable because of the size of sparse vectors / matricies | 18:23 |
| lisitsyn | HeikoS: it is regularized to be 'true multiclass' | 18:23 |
| lisitsyn | like L1 over L2 | 18:24 |
| lisitsyn | IIRC | 18:24 |
| @wiking | c4goldsw: or like CChi2Kernel | 18:24 |
| @wiking | that one is as well tailored to be working only with CDenseFeatures<float64_t> | 18:24 |
| @wiking | c4goldsw: i meant that in many cases even though the api suggest that the method could work on any feature type | 18:25 |
| @wiking | dense or sparse | 18:25 |
| @wiking | it will only work with CDenseFeatures<float64_t> | 18:25 |
| @wiking | not even with a CSparseFeatures<float64_t> feature | 18:25 |
| @wiking | not of course that possibly the sparse version willr require a different implementation fo the method | 18:25 |
| @wiking | bus still it should be implemented -- one day | 18:26 |
| c4goldsw | Yes, that's clear - I just wanted justification as to why we would want use other datatypes in the case of sparse structures :) | 18:26 |
| @wiking | ah yeah well because we have those | 18:26 |
| @wiking | and maybe somebody some day would like to use those | 18:26 |
| @lambday | OXPHOS: do we ever modify the vector inside dot? | 18:26 |
| @wiking | and then he will hit the wall for no reason | 18:26 |
| @wiking | apart from that method being implemented in a shitty way | 18:27 |
| @lambday | OXPHOS: I think that should be const as well | 18:27 |
| lisitsyn | HeikoS: I've checked | 18:27 |
| lisitsyn | it is L1 over L2s | 18:27 |
| @HeikoS | do you have a reference | 18:27 |
| @lambday | but for now, for the benchmark, add what works | 18:27 |
| lisitsyn | https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/lib/slep/slep_mc_plain_lr.cpp | 18:27 |
| @lambday | OXPHOS: ^ | 18:27 |
| c4goldsw | wiking Okay, this all makes sense now. | 18:27 |
| lisitsyn | HeikoS: ^ I rewrote something from SLEP | 18:27 |
| @HeikoS | lisitsyn: as in a document | 18:27 |
| @HeikoS | with math | 18:27 |
| @HeikoS | or wiki | 18:28 |
| @HeikoS | whatever | 18:28 |
| @HeikoS | lisitsyn: just need something for OXPHOS for the cookbook | 18:28 |
| lisitsyn | oh ok | 18:28 |
| lisitsyn | http://yelab.net/software/SLEP/manual.pdf | 18:28 |
| c4goldsw | wiking: So, what's the desired timeline for getting this done? I'm going to be on holiday for three weeks between late June and mid-July, which will delay me a bit. I then resume school in September. | 18:28 |
| @wiking | lisitsyn: some or none? :) | 18:28 |
| lisitsyn | wiking: I rewrote it without std::shared_ptr | 18:28 |
| OXPHOS | lambday: sure | 18:29 |
| lisitsyn | but apparently STILL get memory leak :D | 18:29 |
| @HeikoS | lisitsyn: equation 17? | 18:29 |
| @wiking | c4goldsw: since it's opensource | 18:29 |
| @wiking | :) | 18:29 |
| @wiking | if anybody can spend time on this and doit it's great! | 18:29 |
| lisitsyn | HeikoS: you're fcking fast! | 18:29 |
| lisitsyn | yes | 18:29 |
| lisitsyn | 17 | 18:29 |
| lisitsyn | has anybody tried that? | 18:29 |
| lisitsyn | :D | 18:29 |
| c4goldsw | wiking fair enough! Where would you suggest starting then? | 18:30 |
| @HeikoS | lisitsyn: I havea time machine | 18:30 |
| lisitsyn | HeikoS: good catch in unknown document :D | 18:30 |
| @HeikoS | lisitsyn: wiking what do you guys think about this: | 18:31 |
| @wiking | c4goldsw: any class from those grep : | 18:31 |
| @wiking | :) | 18:31 |
| c4goldsw | HeikoS I'm sure you'd be a pretty popular person amongst Bitcoin miners ;) | 18:31 |
| @HeikoS | every class @brief gets some unified description, including objective functions, etc. | 18:31 |
| c4goldsw | With that machine. | 18:31 |
| @HeikoS | and then in cookbooks, we somehow include that | 18:31 |
| @HeikoS | rather than re-writing everything | 18:31 |
| @wiking | ++ | 18:32 |
| lisitsyn | HeikoS: yes every method should have | 18:32 |
| @HeikoS | and then all implementation specific details in the class docs go somewhere else | 18:32 |
| lisitsyn | float objective() | 18:32 |
| @HeikoS | like "you can overload this to do that" | 18:32 |
| @HeikoS | currently, we are kind of re-writing all the stuff in cookbooks, which I dont really like | 18:32 |
| @HeikoS | but I did not realise before | 18:32 |
| @HeikoS | question is: how to do that ;) | 18:32 |
| @HeikoS | lisitsyn: can we use sphinx for that somehow? | 18:32 |
| lisitsyn | not sure | 18:33 |
| lisitsyn | well we'd need some code I guess | 18:33 |
| @HeikoS | lisitsyn: writing cookbooks then could involve updating the @brief class docs | 18:34 |
| @HeikoS | lisitsyn: but it is a nightmare with references and stuff | 18:34 |
| @HeikoS | lisitsyn: as we currently use bibtex | 18:34 |
| @HeikoS | but if we had something like | 18:34 |
| lisitsyn | it could slow down pretty much | 18:35 |
| @HeikoS | @bla <--- tag to be extracted for cookbook | 18:35 |
| @HeikoS | and @bla always contains objective function | 18:35 |
| @HeikoS | and the basic math | 18:35 |
| @HeikoS | lisitsyn: it is *so* hard to keep the discipline to always ensure good cookbook math/test | 18:36 |
| @HeikoS | and same for the class docs in @brief | 18:36 |
| @HeikoS | so I wonder whether that would help removing redundant efforts | 18:36 |
| @HeikoS | but yeah not quite sure *how* exactly to do it | 18:36 |
| @HeikoS | wiking: any ideas? | 18:36 |
| @HeikoS | Saurabh7: around? | 18:39 |
| OXPHOS | lambday: BENCHMARK_P cannot have template<> | 18:45 |
| OXPHOS | lambday: but if Data is template, I need pass BENCHMARK_P(CPUVector, dot_eigen3, 10, 1000, (BaseVector<T> *A, BaseVector<T> *B)) | 18:46 |
| @lambday | OXPHOS: no.. you'll create the data with Data<float32_t> data; and then pass just as before | 18:48 |
| @lambday | OXPHOS: the point here is, when you need to change the data type, you just need to change one line in the code | 18:49 |
| @lambday | it's easier for you :P | 18:49 |
| OXPHOS | lambday: but I have to specify the datatype in BENCHMARK_P param list? | 18:49 |
| @lambday | OXPHOS: if you're using Data<float32_t>, just pass basevector<float32_t> | 18:50 |
| @lambday | better, have a typedef | 18:50 |
| @lambday | then it's truly just 1 line change | 18:50 |
| OXPHOS | lambday: actually for the typedef | 18:51 |
| OXPHOS | there's one ViennaCL stuff used in both Data and benchmark test | 18:51 |
| @lambday | OXPHOS: what do you mean? | 18:51 |
| @lambday | OXPHOS: you can create your own typedef, no? | 18:51 |
| OXPHOS | so i currently have it outside, like: typedef viennacl::vector_base<int32_t, std::size_t, std::ptrdiff_t> VCLVectorBase; | 18:51 |
| OXPHOS | there's a T in it actually | 18:52 |
| @lambday | OXPHOS: so you wonder what this might look like if int32_t is changed to, say, float32_t? | 18:52 |
| c4goldsw | wiking So, I'm interested. I've had a long day, so I'll start looking at this again tomorrow (I'll probably have a lot of question too). Take care. | 18:52 |
| @lambday | OXPHOS: you just typedef this using T | 18:53 |
| OXPHOS | yes..how can we use template here? | 18:53 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 18:53 | |
| @lambday | OXPHOS: something like | 18:53 |
| @lambday | typedef viennacl::vector_base<typename value_type, std::size_t, std::ptrdiff_t> VCLVectorBase; | 18:53 |
| @lambday | where value_type is your typedef | 18:53 |
| @lambday | OXPHOS: get it? | 18:53 |
| OXPHOS | cool...but no...what is value_type? | 18:54 |
| @lambday | OXPHOS: wait | 18:54 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has joined #shogun | 18:55 | |
| @lambday | OXPHOS: https://gist.github.com/lambday/e6067cc05e736bb300f8386d877156dc | 18:55 |
| @lambday | wait I didn't say what I meant by having your typedef | 18:56 |
| OXPHOS | lambday: oh i was saying this typedef is outside struct Data{}.. | 18:56 |
| OXPHOS | can i do template<T> typedef ... | 18:57 |
| OXPHOS | ? | 18:57 |
| OXPHOS | class T | 18:57 |
| @lambday | OXPHOS: no but you can do that with the using keyword in c++11 | 18:57 |
| @lambday | but you won't need that | 18:57 |
| @lambday | OXPHOS: check now | 18:57 |
| @lambday | OXPHOS: it should be something similar to this | 18:58 |
| OXPHOS | lambday: i see! thx! | 18:58 |
| @lambday | OXPHOS: nw | 18:59 |
| OXPHOS | lambday: and for the const - i tried in linalg.cpp - linalg.dot(const CPUVec *a, const CPUVec *b) | 18:59 |
| OXPHOS | the method calls a->onGPU() | 19:00 |
| OXPHOS | and then there's error: onGPU() is not const | 19:00 |
| @lambday | OXPHOS: onGPU should be const then.. it's just a read only operation | 19:00 |
| c4goldsw | wiking: Before I go: to summarze the task in a single line, it will involve templating all of the .cpp files that use CDenseFeatures<float64_t> to use CDenseFeatures<T> instead? | 19:00 |
| @lambday | OXPHOS: but we'll worry about that later | 19:01 |
| OXPHOS | so I added const in CPUVector, const bool onGPU() | 19:01 |
| @lambday | OXPHOS: what I wanted is to check the benchmark with ptrs :) | 19:01 |
| OXPHOS | still didnt work | 19:01 |
| OXPHOS | okay | 19:01 |
| @lambday | OXPHOS: no.. the method should be const.. | 19:01 |
| @lambday | bool onGPU() const.. | 19:01 |
| OXPHOS | ohhh | 19:01 |
| @lambday | so that it can be called on a const obj | 19:01 |
| @lambday | ref | 19:01 |
| OXPHOS | when i read the book it spent so much words talking about const and pointer/ref | 19:02 |
| OXPHOS | i was wondering who need this stuff | 19:02 |
| @lambday | OXPHOS: haha yeah | 19:02 |
| @lambday | OXPHOS: which book did you read? | 19:02 |
| OXPHOS | c++ primer | 19:02 |
| @lambday | :( I never read any books | 19:03 |
| OXPHOS | it's hard to learn from reading.. | 19:03 |
| @lambday | well, a bit of alexanrescu | 19:03 |
| @lambday | argh I f'kd up the name | 19:03 |
| @lambday | OXPHOS: yeah.. | 19:03 |
| @lambday | OXPHOS: anyway, make sure it works.. | 19:03 |
| OXPHOS | haha some fancy book | 19:04 |
| OXPHOS | sure i just need to add instance to those .cpp to allow float32 | 19:04 |
| @lambday | OXPHOS: https://www.amazon.co.uk/Modern-Design-Generic-Programming-Patterns/dp/0201704315 | 19:04 |
| @lambday | good one | 19:04 |
| @lambday | OXPHOS: yeah.. since your GPU ain't happy wiht double, float32_t would have to do | 19:05 |
| OXPHOS | bookmarked | 19:05 |
| lisitsyn | hahah BEGINNERS GUIDE TO C++ | 19:07 |
| lisitsyn | by alexandrescu | 19:07 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 19:07 | |
| @lambday | lisitsyn: _/\_ | 19:08 |
| shogun-notifier- | shogun: Sergey Lisitsyn :develop * 2dbcaa6 / src/shogun/base/some.h: https://github.com/shogun-toolbox/shogun/commit/2dbcaa612b917cec77c9347bacf2a18d4091ba1a | 19:12 |
| shogun-notifier- | shogun: Rework Some | 19:12 |
| shogun-notifier- | shogun: | 19:12 |
| shogun-notifier- | shogun: - Stop using std::shared_ptr at all | 19:12 |
| shogun-notifier- | shogun: - Don't reference raw pointers - this leads to memory leaks | 19:12 |
| shogun-notifier- | shogun: - Tabs to spaces | 19:12 |
| @lambday | lisitsyn: whoa! dropped std::shared_ptr? | 19:12 |
| @lambday | from some? | 19:12 |
| lisitsyn | HeikoS: wiking: ^ no more leaks I believe | 19:12 |
| lisitsyn | yes | 19:13 |
| @lambday | so we have our own shared_ptr now? | 19:13 |
| lisitsyn | it wasn't really used anyway | 19:13 |
| lisitsyn | well kind of | 19:13 |
| @lambday | I mean, some | 19:13 |
| @lambday | well then please add these | 19:13 |
| @lambday | shogun::make_some<T>(...) | 19:13 |
| lisitsyn | already | 19:13 |
| @lambday | xD | 19:13 |
| lisitsyn | some<T> | 19:13 |
| lisitsyn | check generated meta cpp examples | 19:13 |
| lisitsyn | they are already using that | 19:13 |
| @lambday | okay.. what about adding existing raw pts? | 19:14 |
| shogun-buildbot | build #697 of trusty - libshogun - viennacl is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/697 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 19:14 |
| lisitsyn | what do you mean? | 19:14 |
| lisitsyn | segfault?? | 19:14 |
| shogun-buildbot | build #3775 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3775 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 19:14 |
| @lambday | lisitsyn: T* nkd_ptr = new T(); ... auto ptr = some<T>(nkd_ptr); | 19:14 |
| lisitsyn | hahah ok I broke it | 19:15 |
| lisitsyn | let me fix | 19:15 |
| lisitsyn | lambday: you can do that | 19:15 |
| lisitsyn | it refs it | 19:15 |
| lisitsyn | it refs the pointer I mean | 19:15 |
| @lambday | lisitsyn: we gotta do that via ctor or there is a method for it? | 19:16 |
| lisitsyn | no function yet | 19:16 |
| @lambday | hm | 19:16 |
| lisitsyn | you can do that using ctor | 19:16 |
| @lambday | I see | 19:16 |
| @lambday | that's good enough then | 19:16 |
| @HeikoS | wiking: about aws | 19:17 |
| @HeikoS | wiking: would it make sense to move travis builds to aws? (or is that even possible) | 19:17 |
| lisitsyn | lambday: there is an ambiguity | 19:17 |
| @HeikoS | I am annoyed by the waiting time atm | 19:18 |
| lisitsyn | some<T>(...) | 19:18 |
| lisitsyn | in "…" you get ctor parameters | 19:18 |
| -!- sanuj [~sanuj@117.204.255.148] has quit [Ping timeout: 260 seconds] | 19:18 | |
| @HeikoS | so if we had our own, maybe we could always start PR builds straight away? | 19:18 |
| lisitsyn | so it is not really clear what you do when you call some<T>(naked_ptr) | 19:18 |
| @lambday | lisitsyn: true that | 19:18 |
| shogun-notifier- | shogun: Sergey Lisitsyn :develop * d6407a5 / tests/unit/base/Some_unittest.cc: https://github.com/shogun-toolbox/shogun/commit/d6407a5598f7ec34dda75f605d1b7c6d468cd663 | 19:20 |
| shogun-notifier- | shogun: Reference raw pointers in Some unit-tests | 19:20 |
| shogun-notifier- | shogun: | 19:20 |
| shogun-notifier- | shogun: This resolves segfaults that were introduced | 19:20 |
| shogun-notifier- | shogun: by API changes in 2dbcaa6. | 19:20 |
| lisitsyn | SORRY :D | 19:20 |
| -!- lisitsyn [~lisitsyn@37.139.2.75] has left #shogun [] | 19:20 | |
| -!- lisitsyn [~lisitsyn@37.139.2.75] has joined #shogun | 19:20 | |
| @HeikoS | lisitsyn: go away! | 19:21 |
| @HeikoS | lisitsyn: btw! | 19:21 |
| @HeikoS | lisitsyn: !!! | 19:21 |
| @HeikoS | when are you coming to London? | 19:21 |
| shogun-buildbot | build #698 of trusty - libshogun - viennacl is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/698 | 19:21 |
| lisitsyn | HeikoS: never! | 19:21 |
| lisitsyn | :D | 19:21 |
| shogun-buildbot | build #3776 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3776 | 19:21 |
| lisitsyn | I FIXED IT! | 19:22 |
| lisitsyn | ok lets see memory leaks | 19:22 |
| lisitsyn | HeikoS: do you remember we have range? | 19:23 |
| lisitsyn | if you see for loops with integers | 19:23 |
| lisitsyn | could you please enforce using range | 19:23 |
| @HeikoS | lisitsyn: never? :( | 19:23 |
| @HeikoS | lisitsyn: I in fact forgot that | 19:23 |
| @HeikoS | syntax? | 19:23 |
| lisitsyn | for (auto i : range(0, 10)) | 19:23 |
| lisitsyn | for (auto i : range(10)) | 19:24 |
| lisitsyn | both works | 19:24 |
| @HeikoS | lisitsyn: lovely | 19:25 |
| @HeikoS | will use it | 19:25 |
| lisitsyn | HeikoS: I want to also enforce using other thing | 19:25 |
| lisitsyn | for (auto iteration : iterations(100)) | 19:25 |
| lisitsyn | to replace SG_ITER thing | 19:26 |
| lisitsyn | (or how was it called?) | 19:26 |
| lisitsyn | I haven't implemented it yet | 19:27 |
| lisitsyn | but should be easy | 19:27 |
| @HeikoS | SG_PROGRESS | 19:27 |
| lisitsyn | yes yes | 19:27 |
| lisitsyn | SG_PROGRESS | 19:27 |
| @HeikoS | do we want that in every loop? | 19:27 |
| @HeikoS | lisitsyn: oh i have a question around that | 19:27 |
| @HeikoS | CSignal | 19:27 |
| @HeikoS | does that work | 19:27 |
| shogun-buildbot | build #2903 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2903 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 19:27 |
| @HeikoS | with openmp? | 19:28 |
| lisitsyn | I am not sure | 19:28 |
| shogun-buildbot | build #41 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/41 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 19:28 |
| @HeikoS | sonney2k_ sonne|work ^ | 19:29 |
| @HeikoS | lisitsyn: I realised that we really need to be able to break loops | 19:29 |
| @HeikoS | otherwise have to restart interpreters all the time when using swig interface | 19:29 |
| @HeikoS | lisitsyn: SG_PROGRESS everywhere? | 19:31 |
| @HeikoS | can you give me a tldr for it? | 19:31 |
| @HeikoS | I never used it | 19:31 |
| lisitsyn | HeikoS: what do you mean everywhere? | 19:31 |
| @HeikoS | all loops? | 19:32 |
| lisitsyn | no | 19:32 |
| lisitsyn | just the outer loop | 19:32 |
| OXPHOS | lambday: updated benchmark and linalg | 19:32 |
| lisitsyn | in iteration-based methods | 19:32 |
| @HeikoS | lisitsyn: ok so the big one | 19:32 |
| @HeikoS | lisitsyn: how to use it? | 19:32 |
| @lambday | OXPHOS: what's the result? | 19:32 |
| lisitsyn | well you tell it what's the current iteration | 19:32 |
| lisitsyn | and how many in total you need | 19:33 |
| @lambday | OXPHOS: can you share the results for a sample run? | 19:33 |
| lisitsyn | it outputs a progress bar for you | 19:33 |
| lisitsyn | WE NEED IT FOR IPYTHON!!!! | 19:33 |
| OXPHOS | lambday: on it | 19:33 |
| @HeikoS | lisitsyn: how to activate? | 19:33 |
| lisitsyn | activate what? | 19:33 |
| @HeikoS | lisitsyn: the progress bar | 19:33 |
| @HeikoS | is it MSG_INFO? | 19:33 |
| lisitsyn | sg_progress or so | 19:34 |
| lisitsyn | just a sec | 19:34 |
| @HeikoS | lambday: ^ | 19:34 |
| @HeikoS | would be good to have that for mmd stuff | 19:34 |
| OXPHOS | lambday: https://gist.github.com/OXPHOS/b1085451731f85f1aef27ae4a74fab00 | 19:34 |
| OXPHOS | lemme run a larger vector | 19:34 |
| lisitsyn | enable_progress | 19:34 |
| lisitsyn | HeikoS: ^ | 19:34 |
| lisitsyn | object->io->enable_progress(); | 19:34 |
| @HeikoS | lisitsyn: thanks! | 19:35 |
| @HeikoS | that is good! | 19:35 |
| @HeikoS | lisitsyn: | 19:35 |
| lisitsyn | HeikoS: but I want to replace it with pretty loop | 19:35 |
| @HeikoS | can we put that in range loop? | 19:35 |
| lisitsyn | yes | 19:35 |
| @HeikoS | lisitsyn: yes better | 19:35 |
| lisitsyn | easy peasy | 19:35 |
| @HeikoS | so lets not do it by hand then | 19:35 |
| @HeikoS | but use your loop | 19:35 |
| lisitsyn | I have to get back to work for a moment now :D | 19:36 |
| @HeikoS | lisitsyn: thats outrageous ! :) | 19:36 |
| lisitsyn | HeikoS: have you seen C5.0's code? | 19:36 |
| @HeikoS | lisitsyn: nope | 19:37 |
| @HeikoS | why? | 19:37 |
| OXPHOS | lambday: nooooo it is not getting close at all | 19:37 |
| lisitsyn | it is the most beautiful thing I've ever seen | 19:37 |
| @HeikoS | lisitsyn: link! | 19:37 |
| lisitsyn | https://www.rulequest.com/GPL/C50.tgz | 19:38 |
| lisitsyn | HeikoS: ^ | 19:38 |
| lisitsyn | check it | 19:38 |
| lisitsyn | it is the most readable machine learning code I've ever seen | 19:38 |
| lisitsyn | if it wasn't C and wouldn't bother with some memory | 19:38 |
| @HeikoS | intv; | 19:39 |
| @HeikoS | CaseNoi, j, Kp, Bp, Ap, Missing, SplitI; | 19:39 |
| @HeikoS | CaseCountw, LEErrs, GTErrs, KnownCases, SE; | 19:39 |
| @HeikoS | ClassNoRealClass; | 19:39 |
| @HeikoS | AttributeAtt; | 19:39 |
| @HeikoS | BooleanPrevUnitWeights; | 19:39 |
| @HeikoS | doubleFactor; | 19:39 |
| @HeikoS | /* Stop when get to a leaf */ | 19:39 |
| @HeikoS | if ( ! T->NodeType ) return; | 19:39 |
| @HeikoS | Kp = Group(0, Fp, Lp, T) + 1; | 19:39 |
| @HeikoS | Missing = Kp - Fp; | 19:39 |
| @HeikoS | Att = T->Tested; | 19:39 |
| @HeikoS | KnownCases = CountCases( | 19:39 |
| @HeikoS | ah niceness | 19:39 |
| @lambday | OXPHOS: lemme check | 19:39 |
| lisitsyn | I want to cry when I see that | 19:39 |
| lisitsyn | if it was C++ it could be even better | 19:39 |
| @lambday | OXPHOS: interesting | 19:41 |
| @lambday | OXPHOS: what was the size of the vector? | 19:41 |
| OXPHOS | 10 and 1e6, i wrote them in title | 19:42 |
| OXPHOS | seems like it is copying some stuff | 19:42 |
| @lambday | OXPHOS: I wonder why eigen is so slow | 19:42 |
| @lambday | OXPHOS: anyway.. please push your commits | 19:43 |
| @lambday | OXPHOS: we'll see what's wrong | 19:43 |
| OXPHOS | lambday: it was much faster without static_cast from base to cpuvec | 19:43 |
| lisitsyn | shogun-buildbot: | 19:43 |
| lisitsyn | shogun-buildbot: help | 19:43 |
| shogun-buildbot | Get help on what? (try 'help <foo>', 'help <foo> <bar>, or 'commands' for a command list) | 19:43 |
| @HeikoS | lisitsyn: | 19:43 |
| OXPHOS | pushed: benchmark: https://github.com/shogun-toolbox/shogun/pull/3247 | 19:43 |
| @HeikoS | for ( i = 0 ; i < 3 ; i++ ) | 19:43 |
| @HeikoS | { | 19:43 |
| @HeikoS | Sum[i] += Result[f][i]; | 19:43 |
| @HeikoS | SumSq[i] += Result[f][i] * Result[f][i]; | 19:43 |
| @HeikoS | } | 19:43 |
| @HeikoS | hahaha | 19:44 |
| lisitsyn | shogun-buildbot: commands | 19:44 |
| shogun-buildbot | buildbot commands: commands, dance, destroy, force, hello, help, last, list, mute, notify, shutdown, source, status, stop, unmute, version, watch | 19:44 |
| lisitsyn | shogun-buildbot: force "memleak - valgrind" | 19:44 |
| shogun-buildbot | try 'force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] <WHICH> <REASON>' | 19:44 |
| @lambday | OXPHOS: I'll be online in a while | 19:44 |
| @lambday | OXPHOS: going home :P | 19:44 |
| @HeikoS | lisitsyn: i recently reviewed a submission for jmlr mloss | 19:44 |
| lisitsyn | shogun-buildbot: force build memleak - valgrind because reasons | 19:44 |
| shogun-buildbot | no such builder 'memleak' | 19:44 |
| OXPHOS | lambday: linalg: https://github.com/shogun-toolbox/shogun/pull/3230 | 19:44 |
| @HeikoS | lisitsyn: that looked exactly the same | 19:44 |
| OXPHOS | lambday: i'll go get lunch :) | 19:44 |
| @lambday | OXPHOS: see you in an hour or so | 19:44 |
| @lambday | bye | 19:44 |
| lisitsyn | shogun-buildbot: force build "memleak - valgrind" "because reasons" | 19:44 |
| shogun-buildbot | Something bad happened (see logs) | 19:44 |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [] | 19:44 | |
| lisitsyn | what is wrong? | 19:45 |
| lisitsyn | shogun-buildbot: force build "memleak - valgrind" | 19:45 |
| shogun-buildbot | The build has been queued, I'll give a shout when it starts | 19:45 |
| lisitsyn | oh | 19:45 |
| lisitsyn | HeikoS: I started to like UpperCase things | 19:45 |
| lisitsyn | they look better for some reason | 19:45 |
| -!- HeikoS [~heiko@nat-162-194.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 19:54 | |
| shogun-buildbot | build #14 forced | 19:58 |
| shogun-buildbot | I'll give a shout when the build finishes | 19:58 |
| shogun-buildbot | build #32 of FC23 - libshogun - aarch64 is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/32 blamelist: Sergey Lisitsyn <lisitsyn.s.o@gmail.com> | 20:11 |
| -!- travis-ci [~travis-ci@ec2-54-160-241-98.compute-1.amazonaws.com] has joined #shogun | 22:05 | |
| travis-ci | it's Sergey Lisitsyn'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/135929601 | 22:05 |
| -!- travis-ci [~travis-ci@ec2-54-160-241-98.compute-1.amazonaws.com] has left #shogun [] | 22:05 | |
| -!- lambday [6d9941c0@gateway/web/freenode/ip.109.153.65.192] has joined #shogun | 22:12 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 22:12 | |
| @lambday | lisitsyn: why did you start liking upper-case naming? | 22:14 |
| @lambday | lower case is std:: ish :D | 22:14 |
| lisitsyn | lambday: std::ugly_thing | 22:14 |
| @lambday | OXPHOS: hola | 22:14 |
| @lambday | lisitsyn: you like CamelCase then? | 22:14 |
| lisitsyn | lambday: well yandex's code style (just like google one) is | 22:14 |
| lisitsyn | UpperCaseFunctions | 22:14 |
| @lambday | even for variable naming? | 22:14 |
| lisitsyn | no | 22:14 |
| lisitsyn | Members | 22:14 |
| lisitsyn | variable | 22:15 |
| lisitsyn | but TClass | 22:15 |
| @lambday | lisitsyn: you don't like std:: :'( | 22:15 |
| OXPHOS | lambday: hey | 22:15 |
| lisitsyn | underscores are unnatural in texts | 22:16 |
| @lambday | even for variable naming? | 22:16 |
| lisitsyn | minuses are better but we can't use them | 22:16 |
| @lambday | OXPHOS: let me find out your gist | 22:16 |
| @lambday | lisitsyn: I don't know, maybe I started disliking CamelCase because of java.. | 22:17 |
| OXPHOS | lambday: https://gist.github.com/OXPHOS/b1085451731f85f1aef27ae4a74fab00 | 22:17 |
| @lambday | and started liking underscore because of std:: | 22:17 |
| lisitsyn | it is more compact and in java they use quite long things | 22:17 |
| lisitsyn | AbstractFactoryFactory | 22:17 |
| lisitsyn | abstract_factory_factory | 22:17 |
| lisitsyn | it gets longer and longer when you compose more words | 22:17 |
| @lambday | well, when it's too many words, maybe we're not doing it right :D | 22:18 |
| lisitsyn | I can't agree | 22:18 |
| lisitsyn | it depends on what you're doing | 22:18 |
| @lambday | lisitsyn: I don't know, maybe I started disliking CamelCase because of java.. | 22:18 |
| lisitsyn | sometimes you can't name it in other words | 22:18 |
| @lambday | lisitsyn: actually, I have a class whose name is WithinBlockPermutationBatch.. so I kinda see your point | 22:19 |
| lisitsyn | you don't have any other name for some RemoteWorkflowDispatcher | 22:19 |
| lisitsyn | you can name it Kawabazinga but it won't help others and you to comprehend what's going on | 22:19 |
| lisitsyn | :D | 22:19 |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 22:20 | |
| @lambday | xD | 22:20 |
| @lambday | umm dunno.. I started to kinda root for Kawabazinga | 22:20 |
| @lambday | OXPHOS: so what's the story? | 22:20 |
| @lambday | linalg slow as hell? | 22:20 |
| OXPHOS | lambday: I would say it is proportional to vector length. | 22:21 |
| @lambday | OXPHOS: what do you mean? | 22:21 |
| @lambday | larger the vector, slower sg_linalg gets? | 22:22 |
| @lambday | linalg slow as hell? | 22:22 |
| lisitsyn | lambday: is it you sending some messages twice | 22:22 |
| lisitsyn | or me receiving me twice? | 22:22 |
| lisitsyn | receiving them* | 22:23 |
| OXPHOS | lambday: wait maybe not.. actually it is the same as my previous result. in last version, for the explicit Eigen3, I passed whole sgvector to benchmark | 22:23 |
| OXPHOS | not ref | 22:23 |
| OXPHOS | and it takes about 400ms for a vector of 1e6 | 22:24 |
| @lambday | OXPHOS: yeah.. very important that we ensure that there is no copying going on | 22:24 |
| @lambday | OXPHOS: let me check your benchmark patch and comment | 22:24 |
| @lambday | I wonder why GPUBackend is so much slower | 22:25 |
| OXPHOS | Yeah if I do BENCHMARK(SGVector &), the speed is independent of vector size | 22:25 |
| OXPHOS | however, BENCHMARK(SGVector vec) is proportional to vector size | 22:25 |
| @lambday | OXPHOS: oh one important thing.. The objects CPUVectors and GPUVectors are on stack.. | 22:27 |
| @lambday | OXPHOS: Make sure you use pointers.. that would be the use-case | 22:27 |
| @lambday | remember that we'll use them as | 22:27 |
| @lambday | BaseVector<T>* v = sg_linalg->get_factory()->get_gpu_type(SGVector<T> vec); | 22:28 |
| @lambday | and then sg_linalg->dot(v, v1).. | 22:28 |
| @lambday | OXPHOS: the code looks so much nicer :) | 22:29 |
| @lambday | clean.. nice to read :) | 22:29 |
| @lambday | OXPHOS: your benchmark code I mean | 22:29 |
| OXPHOS | lambday: thx! but for the CPUVector in benchmark, i dont need pointer right? | 22:30 |
| lisitsyn | I see pointers again | 22:31 |
| lisitsyn | this is pointer police this is your last warning call | 22:31 |
| @lambday | lisitsyn: we'll use auto v | 22:32 |
| lisitsyn | :P | 22:32 |
| @lambday | and get_cpu_type(...) will return a some<BaseVector<T>> | 22:32 |
| @lambday | lisitsyn: happy now? :D | 22:32 |
| OXPHOS | lisitsyn: there's a weird anime called Sushi Police | 22:33 |
| lisitsyn | lambday: yes | 22:33 |
| lisitsyn | OXPHOS: sushi pointer police! | 22:33 |
| @lambday | OXPHOS: yo | 22:34 |
| @lambday | OXPHOS: just added two minor comments | 22:34 |
| @lambday | OXPHOS: can you please change those and check? | 22:34 |
| @lambday | OXPHOS: oh and use std::unique_ptr<BaseVector<value_type> > for those vectors :P | 22:34 |
| @lambday | (sorry :P) | 22:34 |
| lisitsyn | lambday: OXPHOS: let me remind you just like I reminded HeikoS today | 22:34 |
| lisitsyn | if you have some for loops | 22:34 |
| lisitsyn | please start using range | 22:35 |
| lisitsyn | not in linalg for sure | 22:35 |
| lisitsyn | to avoid any overhead | 22:35 |
| @lambday | lisitsyn: range(1, 10) = [1,...,10] ? | 22:35 |
| lisitsyn | 1 to 9 | 22:35 |
| @lambday | ok | 22:35 |
| lisitsyn | #include <shogun/base/range.h> | 22:35 |
| @lambday | lisitsyn: what's the overhead for range? | 22:35 |
| lisitsyn | for (auto i : range(10)) | 22:35 |
| OXPHOS | whaaaat | 22:36 |
| lisitsyn | I believe negligible | 22:36 |
| @lambday | it does create a list for those numbers, right? | 22:36 |
| lisitsyn | no | 22:36 |
| lisitsyn | just iterator | 22:36 |
| @lambday | lisitsyn: I see.. cool then | 22:36 |
| lisitsyn | with -O3 it should be maybe a few instructions more on start | 22:36 |
| lisitsyn | I actually checked some code | 22:36 |
| lisitsyn | and didn't find range | 22:36 |
| lisitsyn | when used O3 | 22:36 |
| @lambday | awesome! | 22:37 |
| lisitsyn | so it is mostly optimized out | 22:37 |
| @lambday | lisitsyn: BTW is our version of shared ptr thread safe? | 22:37 |
| lisitsyn | but you like to benchmark things | 22:37 |
| lisitsyn | maybe you could check | 22:37 |
| lisitsyn | lambday: uhmm no | 22:37 |
| OXPHOS | lambday: so we keep SGVector the same? and it won't cause any similar trouble as GPUVector is now? | 22:37 |
| lisitsyn | lambday: ahh maybe yes | 22:38 |
| lisitsyn | :D | 22:38 |
| lisitsyn | it depends | 22:38 |
| @lambday | lisitsyn: we gotta check that actually.. | 22:38 |
| @lambday | OXPHOS: just allocate those objects on heap.. that's all I mean | 22:38 |
| @lambday | SGVector is supposed to be on stack | 22:38 |
| lisitsyn | lambday: SG_REF is atomic | 22:38 |
| lisitsyn | so it should be atomic as well | 22:38 |
| @lambday | lisitsyn: aha | 22:38 |
| OXPHOS | okay | 22:38 |
| lisitsyn | I would need to check if there is some happens-before discrepancy | 22:38 |
| lisitsyn | I think it should be quite sane | 22:39 |
| @lambday | lisitsyn: actually this is why I was in favor of using std::shared_ptr.. we can of course write our own.. but std:: things are already tested | 22:39 |
| lisitsyn | lambday: the thing is that it was actually wrong to rely on shared_ptr | 22:39 |
| lisitsyn | because what I did from the beginning | 22:40 |
| lisitsyn | was to unref in Deleter | 22:40 |
| @lambday | lisitsyn: why was that wrong? | 22:40 |
| @lambday | lisitsyn: I was more worried about the get() method.. does SG_REF every time | 22:40 |
| @lambday | IIRC | 22:40 |
| lisitsyn | because deleter is called once ref count is 0 | 22:41 |
| lisitsyn | lambday: yes that was wrong too | 22:41 |
| lisitsyn | lambday: we can switch to shared ptr | 22:41 |
| lisitsyn | but we have to get rid of sg_ref first | 22:41 |
| @lambday | lisitsyn: I see | 22:41 |
| lisitsyn | I mean drop all SG_REF and SG_UNREF from all the code | 22:41 |
| lisitsyn | other than some.h | 22:41 |
| lisitsyn | that's the only thing that is allowed to have SG_REF | 22:42 |
| lisitsyn | :) | 22:42 |
| @lambday | yeah | 22:42 |
| lisitsyn | then we can change to std::shared_ptr | 22:42 |
| lisitsyn | or boost::shared_ptr or whatever_shared_ptr | 22:42 |
| @lambday | lisitsyn: what should the API would look like? methods should always take naked ptr/return naked ptr? | 22:42 |
| @lambday | and for storage, we rely on the shared ptrs? | 22:43 |
| lisitsyn | no always some | 22:43 |
| @lambday | lisitsyn: typemap? | 22:43 |
| @lambday | does it work by implicit typecast to T* ? | 22:43 |
| lisitsyn | CLibSVM(some<CKernel>); | 22:43 |
| lisitsyn | it should work iirc | 22:43 |
| @lambday | lisitsyn: okay.. maybe we should check swig | 22:44 |
| lisitsyn | yes we should check | 22:44 |
| @lambday | if that works, awesome! | 22:44 |
| lisitsyn | lambday: I have some idea how | 22:44 |
| lisitsyn | going to try that soon | 22:44 |
| @lambday | till now, I have only been using shared_ptr in my code like the way I mentioned.. use only for storage.. pass as naked ptr | 22:44 |
| @lambday | but it's risky | 22:45 |
| lisitsyn | lambday: it is ok to pass them in internal methods | 22:45 |
| @lambday | bee are bee | 22:45 |
| * lambday goes for dinner | 22:45 | |
| lisitsyn | but I wouldn't like to see them in public API | 22:45 |
| @lambday | lisitsyn: me neither.. we need to make sure that it works from python | 22:46 |
| @lambday | okay now really going for dinner | 22:46 |
| * lambday brb | 22:46 | |
| shogun-buildbot | build #14 of memleak - valgrind is complete: Failure [failed memory check] Build details are at http://buildbot.shogun-toolbox.org/builders/memleak%20-%20valgrind/builds/14 | 23:07 |
| OXPHOS | not getting any faster with unique_ptr | 23:12 |
| OXPHOS | and I have to move the ptr around.. :( | 23:12 |
| OXPHOS | lisitsyn: do we have to use smart pointer everywhere? like in SGVector there's a member T* vector | 23:16 |
| OXPHOS | will it be turned into smart pointer? | 23:16 |
| * lambday re | 23:29 | |
| @lambday | OXPHOS: well the idea was to make the benchmark with actual use-case | 23:29 |
| @lambday | unique_ptr was just for making it easier. | 23:29 |
| @lambday | OXPHOS: did you push your code? | 23:29 |
| @lambday | as in, data on heap? | 23:29 |
| OXPHOS | lambday: yes | 23:30 |
| * lambday re | 23:30 | |
| @lambday | OXPHOS: superb! let me check | 23:30 |
| OXPHOS | https://github.com/shogun-toolbox/shogun/pull/3247 | 23:31 |
| @lambday | OXPHOS: err.. why did you have to move? just pass the underlying raw ptr to these methods.. | 23:31 |
| OXPHOS | lambday: thought we were not allowed to.. | 23:32 |
| @lambday | haha && | 23:32 |
| OXPHOS | lambday: but no diff in running time | 23:32 |
| OXPHOS | I tried | 23:32 |
| @lambday | hmm.. | 23:32 |
| @lambday | OXPHOS: can you just make those methods take BaseVector<T>* instead? just pass Ac.get() etc.. | 23:33 |
| @lambday | OXPHOS: we can merge it then | 23:33 |
| @lambday | OXPHOS: also, let me have a look at the dot patch | 23:33 |
| OXPHOS | sure. the same for gpu vector right? | 23:33 |
| @lambday | OXPHOS: yes.. don't move the ownership.. let it be there with struct Data | 23:34 |
| @lambday | OXPHOS: did you update the gist with the latest run-time as well? | 23:35 |
| OXPHOS | you mean this pointer? no. the time is 27s vs 21s (slower) i can update if necessary | 23:35 |
| @lambday | OXPHOS: direct eigen3 call : Average time: 1.696 us, sg_linalg Eigen3 backend call : Average time: 21.982 us | 23:36 |
| @lambday | that doesn't sound right :( | 23:36 |
| @lambday | oh wait this is the small vector | 23:36 |
| OXPHOS | larger is worse | 23:36 |
| OXPHOS | direct eigen3 call just stays the same | 23:37 |
| OXPHOS | less than 2us for a 1e6 size vector | 23:37 |
| @lambday | OXPHOS: for 1e6, direct eigen3 : Average time: 1.533 us, sg_linalg : Average time: 422745.336 us | 23:37 |
| OXPHOS | YES | 23:37 |
| @lambday | wtf! :D | 23:37 |
| OXPHOS | I can try remove part in CPUVec-linalg and see | 23:37 |
| @lambday | maybe something funny is going on | 23:38 |
| OXPHOS | the most suspicious part is static cast, because nothing else looks suspicous | 23:38 |
| @lambday | OXPHOS: could you please change the raw ptr thing and update the results? | 23:39 |
| OXPHOS | lambday: on it | 23:39 |
| @lambday | we should profile about which part takes up all this time | 23:40 |
| OXPHOS | I swear I tried with * and it worked.. | 23:45 |
| OXPHOS | now Im getting error: unterminated function-like macro invocation BENCHMARK_P_INSTANCE(CPUVector, dot_eigen3, (data.Ac.get(), data.Bc.get()); | 23:45 |
| OXPHOS | lambday ^ | 23:46 |
| lisitsyn | lambday: no! we don't need shared_ptrs in sgvector I believe | 23:46 |
| lisitsyn | but we don't need pointers in say multiclass logistic whatever | 23:46 |
| @lambday | OXPHOS: you missed one closing paranthesis | 23:46 |
| @lambday | lisitsyn: yeah SGVector's T* should stay the same | 23:47 |
| OXPHOS | lambday ..ur right | 23:47 |
| OXPHOS | why can't it speak english?! | 23:48 |
| @lambday | OXPHOS: trust me, that's what we're trying to build here ;) | 23:48 |
| @lambday | anyway, works now? | 23:48 |
| OXPHOS | lambday: yes | 23:49 |
| OXPHOS | so i'll push and update output? | 23:49 |
| @lambday | OXPHOS: yo | 23:50 |
| * lambday brb | 23:50 | |
| OXPHOS | done. u want to checkout one more time? I can fix indentation and squash then.. | 23:53 |
| --- Log closed Wed Jun 08 00:00:30 2016 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!