| --- Log opened Fri Jun 16 00:00:15 2017 | ||
| -!- olinguyen [81615ad9@gateway/web/freenode/ip.129.97.90.217] has quit [Quit: Page closed] | 00:47 | |
| -!- TingMiao [uid229534@gateway/web/irccloud.com/x-nkuhyptdjjkmkseh] has quit [Quit: Connection closed for inactivity] | 01:42 | |
| -!- mikeling [uid89706@gateway/web/irccloud.com/x-eslhbcvcdmsjzmai] has joined #shogun | 03:08 | |
| shogitter | (iteachmachines) Hello everyone i'm priyam and i am interested in contributing to shogun as i am new in the field of open source software,can anyone guide me please? | 03:17 |
|---|---|---|
| mikeling | shogitter: Hey, I guess read this https://github.com/shogun-toolbox/shogun/wiki/Getting-involved is a good start to contribute :) | 03:27 |
| -!- olinguyen [488ddefa@gateway/web/freenode/ip.72.141.222.250] has joined #shogun | 04:29 | |
| -!- olinguyen [488ddefa@gateway/web/freenode/ip.72.141.222.250] has quit [Client Quit] | 04:29 | |
| -!- TingMiao [uid229534@gateway/web/irccloud.com/x-zthrpfylkpsrvdcd] has joined #shogun | 04:29 | |
| mikeling | wiking: ping | 05:14 |
| mikeling | After register std::vector by add_vector, what's the m_parameter for? https://pastebin.mozilla.org/9024845 | 05:16 |
| mikeling | wiking: I found we have this problem https://pastebin.mozilla.org/9024846 is because m_parameter is actually point to nothing https://pastebin.mozilla.org/9024847, so it can't be warp as CSGObject** | 05:20 |
| mikeling | wiking: forget it, I was wrong | 06:40 |
| mikeling | sorry | 06:40 |
| -!- geektoni [~geektoni@93-34-234-212.ip52.fastwebnet.it] has joined #shogun | 08:26 | |
| -!- geektoni [~geektoni@93-34-234-212.ip52.fastwebnet.it] has quit [Remote host closed the connection] | 08:34 | |
| -!- wiking_mob [~Mutter@203.142.35.186] has joined #shogun | 09:38 | |
| -!- wiking_mob [~Mutter@203.142.35.186] has quit [Quit: Mutter: www.mutterirc.com] | 09:49 | |
| -!- geektoni [~Mutter@62.18.91.240] has joined #shogun | 10:27 | |
| -!- geektoni [~Mutter@62.18.91.240] has quit [Client Quit] | 10:27 | |
| -!- wiking_mob [~Mutter@203.142.35.186] has joined #shogun | 10:45 | |
| -!- wiking_mob [~Mutter@203.142.35.186] has quit [Remote host closed the connection] | 10:50 | |
| -!- wiking_mob [~Mutter@203.142.35.186] has joined #shogun | 11:11 | |
| -!- wiking_mob [~Mutter@203.142.35.186] has quit [Client Quit] | 11:14 | |
| shogitter | (iteachmachines) @bazdmeg Thank you! | 11:45 |
| -!- TingMiao [uid229534@gateway/web/irccloud.com/x-zthrpfylkpsrvdcd] has quit [Quit: Connection closed for inactivity] | 14:20 | |
| -!- TingMiao [uid229534@gateway/web/irccloud.com/x-xbcsnzdqkuwblyri] has joined #shogun | 15:10 | |
| -!- mikeling [uid89706@gateway/web/irccloud.com/x-eslhbcvcdmsjzmai] has quit [Quit: Connection closed for inactivity] | 15:26 | |
| -!- mikeling [uid89706@gateway/web/irccloud.com/x-rovmvjrxlvkouswc] has joined #shogun | 15:42 | |
| @iglesiasg | TingMiao: hey | 15:58 |
| TingMiao | hi! | 15:58 |
| @iglesiasg | how's it going? | 15:58 |
| @iglesiasg | TingMiao: so, let's see how are the features you are using built (the ones you mentioned in the e-mail) | 16:00 |
| -!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun | 16:02 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 16:02 | |
| TingMiao | https://github.com/tingpan/shogun-data#play-type-statsmost-important-stats-in-this-project these are features I am using for clustering | 16:03 |
| @iglesiasg | TingMiao: in the kmeans notebook, you found out a reasonable number to cluster players into different groups. That number was 13 | 16:03 |
| TingMiao | Yes, and I have validated players are similar in each group | 16:03 |
| @iglesiasg | yep | 16:03 |
| TingMiao | 13 is reasonable for clustering players into different types | 16:03 |
| @iglesiasg | so far so good | 16:04 |
| TingMiao | I was wondering if their types are important to game winning | 16:04 |
| @iglesiasg | now, you mention something about the team score and player total scores | 16:04 |
| TingMiao | It may only similar, but do not influence game result:( | 16:04 |
| TingMiao | yes | 16:04 |
| @iglesiasg | so, where do these player scores come from? | 16:04 |
| TingMiao | player scores = time * efficiency of scoring | 16:05 |
| @iglesiasg | mmm ok so that only takes into account the number of points they score, right? | 16:05 |
| @iglesiasg | it does not use the play types you used in the clustering | 16:06 |
| TingMiao | actually I represent each team with the average score(which is the player score) and played-time percentage for each type. | 16:06 |
| TingMiao | so every team has 2 * 13 feature | 16:07 |
| TingMiao | 13 is number if types | 16:07 |
| @iglesiasg | that is not clear to me | 16:07 |
| @iglesiasg | so | 16:08 |
| TingMiao | Each team would have 13 types of player | 16:08 |
| @iglesiasg | yeah | 16:08 |
| TingMiao | I am not using score of each player | 16:08 |
| @iglesiasg | ok | 16:08 |
| TingMiao | I use score of each type of player, so that each team would have 13 types and each types would have percent and scores | 16:08 |
| @iglesiasg | all right | 16:09 |
| TingMiao | Is this clear enough? Sorry for previous description I think I missed some important points:( | 16:09 |
| @iglesiasg | not yet | 16:10 |
| @iglesiasg | it is fine, that's why we are talking about it now :) | 16:10 |
| @iglesiasg | so right now I would understand that a team has a score that consists of 13 numbers | 16:11 |
| @iglesiasg | one for each of the player types | 16:11 |
| TingMiao | yes | 16:12 |
| @iglesiasg | where does the 2*13 or 2*2*13 come from? | 16:12 |
| TingMiao | I used other attribute called 'time percent of type' so each type would have two features | 16:13 |
| TingMiao | this shows how much time one type of player plays in one team | 16:13 |
| TingMiao | this is 2*13 | 16:13 |
| @iglesiasg | got it | 16:13 |
| TingMiao | and 2*2*13 because there are 2 teams in one game | 16:13 |
| @iglesiasg | \o/ understood | 16:13 |
| TingMiao | so every game would have 52 features, is this too many? | 16:14 |
| @iglesiasg | no, it is not | 16:14 |
| TingMiao | prediction of training set is good(around 90%) but prediction of test set is only 67%. That's why I want to find out some way to fix the overfited | 16:15 |
| @iglesiasg | 52 features is not really even high-dimensional data | 16:15 |
| @iglesiasg | this type of high/low dimensional classification is always a bit relative; but yeah, 52 features it not that many, don't worry about that for the moment | 16:16 |
| @iglesiasg | yeah, that gap between train set and test set looks like there could be some overfitting | 16:16 |
| @iglesiasg | but before getting into how we can address that | 16:16 |
| @iglesiasg | first, let me understand a bit more how do you come up with the team scores | 16:17 |
| @iglesiasg | you mentioned: player scores = time * efficiency of scoring | 16:18 |
| @iglesiasg | does that mean that the played time (by a player) is considered twice? | 16:18 |
| TingMiao | yes, and I will add up this score of players of each types so this is the 'player type score' | 16:19 |
| TingMiao | yes | 16:19 |
| TingMiao | I try only use percent but result was not good as well | 16:19 |
| TingMiao | percent I mean played time | 16:19 |
| @iglesiasg | ok, I see. We could revisit this thing of using the time twice later | 16:20 |
| @iglesiasg | the played time is different for each match, right? | 16:21 |
| @iglesiasg | so that the feature vector corresponding to Team A is different in say Match 1 and Match 2 | 16:21 |
| @iglesiasg | let me put that a bit more detailed | 16:21 |
| @iglesiasg | Match1: Team A - Team B | 16:21 |
| @iglesiasg | Match2: Team A - Team C | 16:21 |
| TingMiao | I will use the total play time of a season and convert it to percent of total team play time | 16:21 |
| @iglesiasg | oh I see | 16:22 |
| TingMiao | because I could not get the play time of a game before it start:( | 16:22 |
| @iglesiasg | I don't really understand why that is an issue | 16:22 |
| @iglesiasg | let me think about it | 16:23 |
| TingMiao | thanks for your time:) | 16:23 |
| @iglesiasg | sure, np | 16:23 |
| @iglesiasg | mm ok | 16:24 |
| @iglesiasg | so, right now a certain Team always gets the same features for every match it participates in | 16:24 |
| @iglesiasg | TingMiao: yes ^? | 16:26 |
| TingMiao | yes since they are all history data | 16:26 |
| @iglesiasg | ok ok, that's good | 16:26 |
| @iglesiasg | that could be something that could be done differently when applying this approach to predict the results of future matches | 16:27 |
| TingMiao | yes | 16:27 |
| @iglesiasg | as you said, it is not reasonable to assume we know the time each player will play in a match beforehand | 16:27 |
| TingMiao | if I am predicting future games | 16:27 |
| @iglesiasg | but it is reasonable to assume which players will play a match | 16:27 |
| TingMiao | I would update feature of each team before every game basic on recent games | 16:27 |
| @iglesiasg | but for the time being it is ok | 16:27 |
| TingMiao | base not basic | 16:28 |
| @iglesiasg | got it | 16:28 |
| @iglesiasg | now we focus on this exercise of predicting match results for the previous season using the data for the complete season, that's good | 16:28 |
| @iglesiasg | so, how is the score of a player computed? | 16:29 |
| TingMiao | yes and currently I am using 90% of games in one season as training set and 10% for test. | 16:29 |
| TingMiao | score is time * efficiency. Actually it is total points that a player get. | 16:30 |
| -!- olinguyen [81615ad9@gateway/web/freenode/ip.129.97.90.217] has joined #shogun | 16:30 | |
| @iglesiasg | TingMiao: all right, so it is only based on the number of points the player scored | 16:30 |
| TingMiao | yeah | 16:30 |
| @iglesiasg | ok, I think the full picture is clear to me now | 16:31 |
| TingMiao | :) | 16:31 |
| @iglesiasg | I think it will be a good idea to add cross-validation to make a good selection of the parameters you mentioned in the e-mail | 16:33 |
| @iglesiasg | TingMiao: I think this is a good video introducing the concept: https://www.youtube.com/watch?v=hihuMBCuSlU | 16:34 |
| TingMiao | oh thanks I will check this:) | 16:35 |
| @iglesiasg | that is only a bit in general to get familiar with the concept | 16:35 |
| @iglesiasg | I am looking for an example so you can see how to do this in Shogun | 16:35 |
| @iglesiasg | also what are the parameters that could be interesting tuning for you random forest | 16:36 |
| TingMiao | maybe i could read this one http://www.shogun-toolbox.org/notebook/latest/xval_modelselection.html | 16:37 |
| @iglesiasg | yes | 16:38 |
| @iglesiasg | HeikoS: ping | 16:39 |
| @HeikoS | iglesiasg: jo | 16:40 |
| @iglesiasg | HeikoS: the num_bags of CRadomForest is automagically tuned internally? | 16:43 |
| @iglesiasg | "The feature for calculating out-of-box error is also provided to help determine the | 16:43 |
| @HeikoS | I dont know | 16:43 |
| @iglesiasg | * appropriate number of bags. | 16:43 |
| @iglesiasg | ok oko | 16:43 |
| @HeikoS | iglesiasg: you mentored parijat :D | 16:43 |
| @iglesiasg | HeikoS: it fallsback to bagging :P | 16:44 |
| @HeikoS | kk | 16:44 |
| @iglesiasg | CRandomForest is actually quite barebones | 16:44 |
| @HeikoS | iglesiasg: if you find problems, please open issues | 16:44 |
| @iglesiasg | I didn't ask the question very well | 16:44 |
| @HeikoS | so we can fix things | 16:44 |
| @iglesiasg | I meant more from a conceptual point of view if that makes sense | 16:44 |
| @iglesiasg | or perhaps from a practical point of view actually | 16:44 |
| @iglesiasg | when using RandomForest for classification in general (let's now not say only in Shogun) | 16:45 |
| @HeikoS | iglesiasg: I think it follows sklearns basic implementation now? | 16:45 |
| @iglesiasg | is the number of bags / weak classifiers / trees selected by the algo | 16:45 |
| @iglesiasg | or is something normally chosen with xval? | 16:45 |
| @HeikoS | ah | 16:48 |
| @HeikoS | number of trees is set to "large" | 16:48 |
| @HeikoS | since they usually dont overfit | 16:48 |
| @HeikoS | number of bags I dont know, I think there are heuristics | 16:48 |
| @HeikoS | but yeah x-validation | 16:48 |
| @HeikoS | but the algorithm is very robust e.g. for the number of trees used | 16:48 |
| @iglesiasg | mmm I think in at least CRandomForest #trees=#bags | 16:49 |
| @iglesiasg | TingMiao: what is the subset size you mentioned in the e-mail? | 16:51 |
| TingMiao | 7 | 16:51 |
| TingMiao | 52 ^ 0.5 | 16:52 |
| olinguyen | HeikoS: is there a way to get probability scores/confidence values from RandomForest in shogun? | 16:54 |
| @HeikoS | olinguyen: RF are quite bad in their confidence estimates | 16:54 |
| olinguyen | what's the better way to compute the auROC for RandomForest? | 16:54 |
| @HeikoS | olinguyen: I dont know, but if they did, I wouldnt trust them ;) | 16:54 |
| @iglesiasg | TingMiao: so, I think it is worth to experiment a bit with these two parameters to get a feeling how they impact the performance | 16:55 |
| @HeikoS | olinguyen: check the "get_values" of the labels produced by the RF | 16:55 |
| @HeikoS | they dont have scores? | 16:55 |
| olinguyen | they seem to be null after .apply | 16:56 |
| @iglesiasg | TingMiao: using the extra validation set should anyway help a bit with the overfitting | 16:56 |
| olinguyen | but the get_labels have values | 16:56 |
| @HeikoS | ok | 16:57 |
| olinguyen | HeikoS: https://gist.github.com/olinguyen/ade8e2bd0899b2ec9bee00d03fbb5172 | 16:57 |
| olinguyen | reproduced here | 16:57 |
| @HeikoS | olinguyen: then I guess we currently dont output that | 16:57 |
| @iglesiasg | TingMiao: so, my suggestion is first fix one of those two (#bags, subset size) parameters and make a small sweep in the other parameter using the x-val framework. | 16:58 |
| @HeikoS | olinguyen: then you need to do accuracy | 16:58 |
| @HeikoS | olinguyen: Ill open an issue | 16:58 |
| olinguyen | alright | 16:59 |
| @HeikoS | olinguyen: maybe another voting strategy allows it? | 17:00 |
| @HeikoS | Im just checking | 17:00 |
| olinguyen | i'll check | 17:00 |
| @iglesiasg | TingMiao: get a feeling of how each of them affects the performance. And then we can make x-val choosing both or so | 17:00 |
| @HeikoS | olinguyen: you could try the "MeanRule" and see what happens (but also make sure you understand what that changes ;) ) | 17:01 |
| @iglesiasg | TingMiao: the goal here is to reduce the gap between test and train accuracy | 17:01 |
| olinguyen | kk | 17:01 |
| @iglesiasg | TingMiao: you could include this type of an analysis in an upcoming blog post too | 17:02 |
| @iglesiasg | TingMiao: Does this all make sense to you? | 17:02 |
| @sukey | Issue #3850 "Random forest probability output " karlnapf added label: "development tasks" - https://github.com/shogun-toolbox/shogun/issues/3850 | 17:02 |
| @sukey | Issue #3850 "Random forest probability output " karlnapf added label: "entrance" - https://github.com/shogun-toolbox/shogun/issues/3850 | 17:02 |
| @sukey | Issue #3850 "Random forest probability output " opened by karlnapf - https://github.com/shogun-toolbox/shogun/issues/3850 | 17:02 |
| TingMiao | I made plot of accuracy when num_of_tree or subset_size changing https://usercontent.irccloud-cdn.com/file/kFruerWE/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202017-06-16%20%E4%B8%8B%E5%8D%8810.59.34.png https://usercontent.irccloud-cdn.com/file/t4I7JQ86/%E5%B1%8F%E5%B9%95%E5%BF%AB%E7%85%A7%202017-06-16%20%E4%B8%8B%E5%8D%8810.55.00.png | 17:03 |
| TingMiao | yes I will try | 17:03 |
| TingMiao | these images are produced in my previous experiment | 17:04 |
| @iglesiasg | ok | 17:04 |
| @iglesiasg | TingMiao: give it a shot using the validation set, that might help a bit | 17:05 |
| @HeikoS | olinguyen: check the last two issues I opened | 17:05 |
| @sukey | Issue #3851 "Implement a probability calibration scheme" karlnapf added label: "entrance" - https://github.com/shogun-toolbox/shogun/issues/3851 | 17:05 |
| @sukey | Issue #3851 "Implement a probability calibration scheme" opened by karlnapf - https://github.com/shogun-toolbox/shogun/issues/3851 | 17:05 |
| @sukey | Issue #3851 "Implement a probability calibration scheme" karlnapf added label: "development tasks" - https://github.com/shogun-toolbox/shogun/issues/3851 | 17:05 |
| TingMiao | got it | 17:05 |
| @HeikoS | olinguyen: we should at some point look at some of those, and maybe plan for you to implement the most important ones, so you can get some C++ into GSoC :) | 17:05 |
| olinguyen | sure! | 17:06 |
| @iglesiasg | TingMiao: cool cool | 17:06 |
| @HeikoS | olinguyen: depends a bit on you and what you are most interested in, but I would be excited about improving Shogun in an application driven way | 17:06 |
| @HeikoS | micmn: jo | 17:17 |
| @HeikoS | nice blog post! | 17:17 |
| @HeikoS | TingMiao, olinguyen, micmn, mikeling, did Gina get back to you guys about the numfocus feature? | 17:17 |
| micmn | HeikoS: thx! | 17:18 |
| micmn | no.. | 17:18 |
| @sukey | Issue #3849 "Pickle on a BinaryLabels object does not save the values parameter " karlnapf added label: "entrance" - https://github.com/shogun-toolbox/shogun/issues/3849 | 17:21 |
| @sukey | Issue #3849 "Pickle on a BinaryLabels object does not save the values parameter " karlnapf added label: "BUG" - https://github.com/shogun-toolbox/shogun/issues/3849 | 17:21 |
| @HeikoS | micmn: ok stay tuned | 17:21 |
| @HeikoS | micmn: re the un-templated linalg stuff | 17:21 |
| @HeikoS | micmn: I think what we should do is to start a feature branch where we play that thing through for a simple example case | 17:21 |
| @HeikoS | micmn: like linalg::dot(Matrix m, Vector v) | 17:22 |
| @HeikoS | or even better | 17:22 |
| @HeikoS | linalg::dot(Matrix, Matrix) | 17:22 |
| @HeikoS | so we just need to draft one | 17:22 |
| micmn | yeah :P | 17:22 |
| @HeikoS | and then think how the linalg::dot would look like (i.e. how it determines the type to call dot_impl(SGMatrix<T>, SGMatrix<T>) | 17:23 |
| @HeikoS | make it work, think a bit about scalability | 17:23 |
| @HeikoS | and then iterate | 17:23 |
| @HeikoS | and then add it to the current interface | 17:24 |
| @HeikoS | so that we can start using it, but also still have the old methods (so we can continuously move to the new system) | 17:24 |
| @HeikoS | micmn: do you want to take a lead on this? Or are you currently busy with another thing? | 17:24 |
| @HeikoS | micmn: I can start a feature branch that you can send PRs against | 17:24 |
| @HeikoS | OXPHOS might also be able to get involved with this stuff, she wrote most of the linalg | 17:25 |
| micmn | it's fine with me | 17:25 |
| @HeikoS | olinguyen: could you start your doc soon and put the github issues that you and me created in there? | 17:26 |
| @HeikoS | micmn: ok | 17:26 |
| @HeikoS | micmn: so let me create that branch | 17:26 |
| olinguyen | HeikoS: will do | 17:26 |
| @HeikoS | micmn: keep in mind this is drafting only, so doesnt have to be super clean, nor the most beautiful, it is really about the concept | 17:26 |
| @HeikoS | micmn: so rather update often and discuss often | 17:26 |
| micmn | speaking of the Matrix class | 17:27 |
| @sukey | New Commit "Merge pull request #3846 from micmn/feature/linalg-refactor | 17:27 |
| @sukey | Split Eigen3's linalg backend into header and implementation." to shogun-toolbox/shogun by karlnapf: https://github.com/shogun-toolbox/shogun/commit/3b35df370192d734e19c90305e4b69e8142de31b | 17:27 |
| @sukey | New branch feature/linalg_untemplated created on shogun-toolbox/shogun | 17:27 |
| @HeikoS | micmn: here is your branch | 17:28 |
| micmn | awesome :D | 17:28 |
| @HeikoS | micmn: about the Matrix class? | 17:28 |
| micmn | how do we memorize the data? I mean just a void* pointer? | 17:29 |
| mikeling | HeikoS: hey | 17:29 |
| micmn | and cast it as needed? | 17:29 |
| @HeikoS | micmn: good question :D | 17:29 |
| @HeikoS | micmn: void pointer would be the bare bones approach, yes | 17:29 |
| mikeling | Had you see the email? | 17:29 |
| @HeikoS | mikeling: was just about to answer | 17:29 |
| mikeling | HeikoS: Oh, thank you | 17:30 |
| @HeikoS | micmn: I think maybe something like the CSGObject::add_vector does, it stores the void pointer, and enums for the type | 17:30 |
| @HeikoS | micmn: for runtime type information, we enum is the bare bones approach | 17:30 |
| @HeikoS | not sure whether c++11 can do something for us there? | 17:30 |
| @HeikoS | some reflection? | 17:30 |
| @HeikoS | mikeling: I am not sure I get your question ;) | 17:31 |
| micmn | not sure yesterday I was doing some reasearch into stuff like type erasure but didn't find anything useful for now | 17:31 |
| @HeikoS | micmn: first draft could use enums | 17:32 |
| @HeikoS | micmn: which will result in more MACRO HACKS (tm) | 17:32 |
| micmn | :) | 17:32 |
| @HeikoS | micmn: so there might be another option | 17:32 |
| @HeikoS | which is registering function pointers | 17:33 |
| @HeikoS | not totally sure if/how that would work | 17:33 |
| @HeikoS | but here is the idea in a nutshell: | 17:33 |
| @HeikoS | 1. algorithm tells linalg that it will call dot 1000 times with float64 | 17:33 |
| mikeling | HeikoS: Actually I and wiking are talking about which length should been used for the second parameter of add_vector | 17:33 |
| @HeikoS | 2. linalg internally registers the corresponding (typed float64) function for dot | 17:34 |
| mikeling | you know, we have two length in DynamicArray | 17:34 |
| mikeling | one is the number of elements | 17:34 |
| @HeikoS | 3. the dot call from the algorithm than is just forward to that registered function | 17:34 |
| @HeikoS | micmn: see what I mean? | 17:34 |
| @HeikoS | micmn: you kind of have a global state of linalg that remembers the word-length, and all subsequent calls will just static cast | 17:34 |
| @HeikoS | micmn: but not too sure about that, I think a first draft would use enums and switches | 17:35 |
| mikeling | the other is the array size, which include the number of elements been used and not used | 17:35 |
| micmn | mmm I'll think about it | 17:35 |
| @HeikoS | mikeling: yes I know what you mean | 17:35 |
| @HeikoS | mikeling: we in fact fixed that recently | 17:35 |
| @HeikoS | for DynArray | 17:35 |
| @HeikoS | micmn: the thing here is that the size of the allocated memory is not registered | 17:35 |
| @HeikoS | only the number of used elements | 17:35 |
| @HeikoS | so then you have a vector of size 10, but only 5 elements are filled, then serialization only stores the 5 values to disk, and de-serializing allocated a new vector with 5 elements | 17:36 |
| @HeikoS | and clone in fact ignores the "allocated size" parameter | 17:36 |
| @HeikoS | because it is not registered | 17:36 |
| @HeikoS | mikeling: that is how it currently works | 17:36 |
| mikeling | HeikoS: ok, so we only need use add_vector(&(m_array.data()), &num_elements)? | 17:37 |
| @HeikoS | yep that is OK | 17:37 |
| @HeikoS | loading into the std::vector might be more tricky | 17:37 |
| @HeikoS | since de-serialization currently works like this | 17:37 |
| @HeikoS | 1. allocate memory of appropriate size (as read from file) | 17:38 |
| @HeikoS | 2. load elements one-by one | 17:38 |
| @HeikoS | 3. update the pointer in the class | 17:38 |
| @HeikoS | mikeling: does that help? | 17:38 |
| mikeling | HeikoS: mmm, yeah. But I found we have a m_parameter in the m_parameters like here https://pastebin.mozilla.org/9024845 | 17:40 |
| mikeling | line 19 | 17:40 |
| mikeling | it's a void pointer | 17:41 |
| @HeikoS | sure | 17:41 |
| mikeling | but I don't know where it been init? and which parameter it will been pointer to | 17:42 |
| mikeling | HeikoS: mmm, so here is my issue actually | 17:42 |
| @HeikoS | mikeling: I dont understand what you are asking | 17:43 |
| @HeikoS | mikeling: can you explain again? | 17:43 |
| mikeling | I replace DynArry with std::vector, and register things like https://pastebin.mozilla.org/9024922 | 17:44 |
| mikeling | sure, I'm typing | 17:44 |
| mikeling | :) | 17:44 |
| mikeling | but I got https://pastebin.mozilla.org/9024846 | 17:45 |
| mikeling | it seems like the m_parameter point to somewhere haven't been allocated | 17:46 |
| @HeikoS | when does it happen? | 17:47 |
| @HeikoS | loading? | 17:48 |
| mikeling | ./bin/shogun-unit-test | 17:48 |
| @HeikoS | which test? | 17:49 |
| @HeikoS | which exact case? | 17:49 |
| mikeling | DynamicObjectArray.clone | 17:49 |
| mikeling | so it actually error out immediately | 17:50 |
| mikeling | HeikoS: Do you want me update the pr so you can check the issue locally? | 17:53 |
| @HeikoS | mikeling: can you run only that test, and then put the full valgrind output somewhere, along with the source code of your changed SG_ADD ? | 17:53 |
| mikeling | sure | 17:54 |
| @HeikoS | thx | 17:54 |
| mikeling | HeikoS: Oh, for now I can't run valgrind locally, due to I'm using osx. Sorry | 17:55 |
| mikeling | I could push it to remote and fetch it to my server(I got a remote server running Ubuntu 16.04 with valgrind) | 17:56 |
| mikeling | and then build and debug it | 17:56 |
| @sukey | Pull Request #3824 "Replace DynArray with std::vector" synchronized by MikeLing - https://github.com/shogun-toolbox/shogun/pull/3824 | 17:58 |
| shogun-buildbot | build #754 of cookbook - PR is complete: Failure [failed shell] Build details are at http://buildbot.shogun-toolbox.org/builders/cookbook%20-%20PR/builds/754 blamelist: MikeLing | 18:00 |
| mikeling | HeikoS: I'm building it :) | 18:03 |
| -!- iglesiasg [~iglesiasg@217.119.234.214] has quit [Quit: leaving] | 18:04 | |
| @HeikoS | mikeling: whatever works | 18:06 |
| @HeikoS | I just want to see the valgrind output | 18:06 |
| @HeikoS | and the code you changed | 18:06 |
| @HeikoS | micmn: just had another thought | 18:08 |
| @HeikoS | micmn: I think we should actually keep both the templated and the untemplated linalg interface for now (as said before) | 18:09 |
| @HeikoS | micmn: so the best thing was if we could just generate the method for the untemplated ones using a similar mechanism as for the templated ones | 18:09 |
| @HeikoS | micmn: so that we only have to "add" the method ones, and then it is available for all SGMatrix<T> and Matrix | 18:10 |
| micmn | right | 18:11 |
| @HeikoS | micmn: was just going through all your linalg adds btw, love them, finally we see something moving there | 18:12 |
| micmn | glad to hear that :) | 18:13 |
| @HeikoS | mikeling: and? | 18:24 |
| mikeling | 23% :( | 18:24 |
| -!- travis-ci [~travis-ci@ec2-54-162-244-111.compute-1.amazonaws.com] has joined #shogun | 18:24 | |
| travis-ci | it's Viktor Gal's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/243710903 | 18:24 |
| -!- travis-ci [~travis-ci@ec2-54-162-244-111.compute-1.amazonaws.com] has left #shogun [] | 18:24 | |
| @HeikoS | mikeling: are you using ccache? | 18:24 |
| @HeikoS | with a large cache size? | 18:25 |
| @HeikoS | because that makes compiling very fast | 18:25 |
| @HeikoS | see DEVELOPING.md | 18:25 |
| mikeling | yeah, I do install CCache | 18:25 |
| mikeling | but I don't know how to check the config | 18:25 |
| @HeikoS | ccache -s | 18:33 |
| @HeikoS | https://ccache.samba.org/manual.html#_cache_size_management | 18:33 |
| @HeikoS | mikeling: google is your friend :D | 18:33 |
| mikeling | HeikoS: What's the time in your there? BTW | 18:41 |
| mikeling | I will cc you the result after things done :) | 18:42 |
| @HeikoS | 1740 | 18:43 |
| @HeikoS | mikeling: cool thx | 18:43 |
| @HeikoS | mikeling: btw just sent another email | 18:43 |
| -!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Quit: Leaving.] | 19:34 | |
| -!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has joined #shogun | 19:35 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 19:35 | |
| -!- HeikoS [~heiko@host-92-0-178-129.as43234.net] has quit [Client Quit] | 19:35 | |
| @sukey | Pull Request #3843 "Add linalg methods needed by FisherLDA and KernelPCA (CPU-only)" synchronized by micmn - https://github.com/shogun-toolbox/shogun/pull/3843 | 20:01 |
| shogun-buildbot | build #755 of cookbook - PR is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/cookbook%20-%20PR/builds/755 | 20:02 |
| @sukey | Pull Request #3843 "Add linalg methods needed by FisherLDA and KernelPCA (CPU-only)" - https://github.com/shogun-toolbox/shogun/pull/3843 | 20:03 |
| shogitter | (iteachmachines) Hey why am i seeing only @bazdmeg your messages? | 20:37 |
| @sukey | Pull Request #3843 "Add linalg methods needed by FisherLDA and KernelPCA (CPU-only)" synchronized by micmn - https://github.com/shogun-toolbox/shogun/pull/3843 | 20:47 |
| -!- HeikoS [~heiko@78.40.158.50] has joined #shogun | 21:39 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 21:39 | |
| @HeikoS | mikeling: updates? | 21:39 |
| @HeikoS | micmn: there? | 21:42 |
| -!- olinguyen [81615ad9@gateway/web/freenode/ip.129.97.90.217] has quit [Quit: Page closed] | 21:54 | |
| @HeikoS | rcurtin: how are things going gsoc wise? | 21:54 |
| rcurtin | HeikoS: I'd say things are going quite well, but maybe not so well for my free time! :) | 21:58 |
| @HeikoS | haha | 21:58 |
| @HeikoS | cool! good to hear | 21:58 |
| rcurtin | lots of nice work on the benchmarking system | 21:58 |
| rcurtin | we are running the shogun benchmarks now (I think 5.0, but we'll have to upgrade and run again) | 21:58 |
| rcurtin | once those are done, we can deploy the new database to the website, and then we can see all the things that the benchmarking scripts did wrong :) | 21:58 |
| -!- HeikoS [~heiko@78.40.158.50] has quit [Read error: Connection reset by peer] | 22:05 | |
| -!- HeikoS [~heiko@78.40.158.50] has joined #shogun | 22:08 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 22:08 | |
| -!- HeikoS [~heiko@78.40.158.50] has quit [Quit: Leaving.] | 22:25 | |
| -!- HeikoS [~heiko@78.40.158.50] has joined #shogun | 22:25 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 22:25 | |
| @HeikoS | lisitsyn: you around? | 22:30 |
| -!- mikeling [uid89706@gateway/web/irccloud.com/x-rovmvjrxlvkouswc] has quit [Quit: Connection closed for inactivity] | 22:46 | |
| -!- TingMiao [uid229534@gateway/web/irccloud.com/x-xbcsnzdqkuwblyri] has quit [Quit: Connection closed for inactivity] | 23:30 | |
| -!- HeikoS [~heiko@78.40.158.50] has quit [Ping timeout: 255 seconds] | 23:31 | |
| --- Log closed Sat Jun 17 00:00:16 2017 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!
