verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
kris1 has quit [Quit: kris1]
sumedhghaisas has quit [Ping timeout: 260 seconds]
kris1 has joined #mlpack
sumedhghaisas has joined #mlpack
kris1 has quit [Quit: kris1]
partobs-mdp has joined #mlpack
sumedhghaisas has quit [Ping timeout: 260 seconds]
bvr has joined #mlpack
travis-ci has joined #mlpack
< travis-ci> mlpack/mlpack#3044 (master - 37be9f4 : Ryan Curtin): The build was broken.
travis-ci has left #mlpack []
sumedhghaisas has joined #mlpack
sumedhghaisas has quit [Client Quit]
sumedhghaisas_ has joined #mlpack
sumedhghaisas_ has quit [Client Quit]
sumedhghaisas__ has joined #mlpack
sumedhghaisas__ has quit [Client Quit]
sumedhghaisas_ has joined #mlpack
sumedhghaisas_ has quit [Client Quit]
sumedhghaisas_ has joined #mlpack
sumedhghaisas_ has quit [Ping timeout: 260 seconds]
kris1 has joined #mlpack
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
kris1 has quit [Quit: kris1]
kris1 has joined #mlpack
kris1 has quit [Quit: kris1]
kris1 has joined #mlpack
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
zoq has quit [Ping timeout: 268 seconds]
zoq_ has joined #mlpack
kris1 has quit [Quit: kris1]
zoq_ is now known as zoq
< partobs-mdp> Rebased my mlpack local repo with this command: git rebase upstream/master
< partobs-mdp> There is still a lot of merge conflicts, though - what have I done wrong?
kris1 has joined #mlpack
< rcurtin> partobs-mdp: depending on the code, maybe there is no way to avoid a merge
< rcurtin> in a desperate situation I guess you could take your old repo, export the commits as patches with 'git format-patch', and then apply them to a clean repo with 'git am'
< partobs-mdp> rcurtin: git merge upstream/master
< partobs-mdp> Already up-to-date.
< partobs-mdp> No idea how this could ever happen T_T
< partobs-mdp> Wow, something is wrong with me :'( Ran git pull upstream master, now there are a lot of conflicts
< rcurtin> ah so if you do 'git merge <remote>' without doing something like 'git fetch <remote>' or 'git pull <remote>' I think that it won't merge the latest remote branch
< rcurtin> maybe 'git fetch upstream' followed by 'git merge upstream/master' might help? I wonder if 'git pull upstream master' is doing something different than what is intended
< partobs-mdp> rcurtin: Read git docs. https://git-scm.com/docs/git-rebase states that git rebase checks out to the branch and merges from *local snapshot*
< partobs-mdp> Not what I was trying to achieve :)
< partobs-mdp> Git is just so weird sometimes - but it works ^_^
< rcurtin> yeah, I agree
< rcurtin> I spend too much time fighting git...
< rcurtin> but I still think it is better than the days when we used subversion
< rcurtin> or worse when I used cvs on some other projects years ago
< partobs-mdp> rcurtin: And, lo and behold, all merge conflicts are resolved! :)
< partobs-mdp> rcurtin: As a guy who has never used anything except git, could you describe the downsides of subversion and cvs
< partobs-mdp> ?
< rcurtin> (sorry for the slow responses, I am tabbing between this and reviewing code :))
< rcurtin> subversion makes merges a lot, lot harder; the tools are nowhere near as smart
< rcurtin> and subversion is also not distributed, so if I am going to make any commits at all, they are directly to the upstream subversion server (which also means I can't commit a bunch of stuff locally, then push it all at once, without the help of extra third-party tools)
< rcurtin> in addition, git is all about branching and merging all the time; in subversion... branches and merging are a much trickier and much more irritating affair
< rcurtin> cvs is a whole 'nother level of bad... you can't rename files (or directories) in cvs
< rcurtin> and the cvs utility itself is hopelessly primitive
< partobs-mdp> rcurtin: This should be horribly counter-productive oO
< rcurtin> just a few lines from this page give an idea: https://kb.wisc.edu/middleware/page.php?id=4087
< partobs-mdp> But there is yet another level - sending patches via email
< rcurtin> " FIRST CHECK TO SEE IF SOMEONE ELSE HAS MADE CHANGES If they have, it is beyond this simple tutorial to untangle the problems. Seek assistance from your local CVS Guru. "
< rcurtin> " FIRST CHECK TO SEE IF SOMEONE ELSE HAS MADE CHANGES If they have, it is beyond this simple tutorial to untangle the problems. Seek assistance from your local CVS Guru. "
< rcurtin> oops, double-pasted...
< rcurtin> "Even if you didn't get any conflicts, you have to verify that the CVS merge process didn't incorrectly merge your changes."
< rcurtin> yeah, patches by email... git actually works pretty well with that, you can just do 'git am <patches>' and it'll try to apply them
< rcurtin> doing the same with cvs or svn is... nowhere near as easy (:
< rcurtin> *:(
< partobs-mdp> Judging from the above, CVS looks like a tool which is more of an obstacle than of a help
< rcurtin> yes indeed
< rcurtin> but even it was an improvement over whatever came before (I can't remember the name... vcs? I never used it)
< zoq> Btw. nowadays you can use git-svn (bridge), which works quite good.
< rcurtin> zoq: I think you were doing that before we transitioned to git? it was probably so much nicer than svn :)
< rcurtin> but it took a long time before I 'took the plunge' and learned git
< rcurtin> I was apprehensive about git for a long time because it seemed needlessly complex compared to svn (since it's distributed, for instance)
< partobs-mdp> I just wonder: if git is such a radical improvement wrt svn (which has created 17 years ago), is there something developed right now that is a radical improvement over git?
< rcurtin> but really git is such a breath of fresh air, I only realized that once I started using it
< rcurtin> hmm... not sure
< partobs-mdp> I mean, not yet popular, but radical :)
< rcurtin> but if there is, it's definitely not perforce :)
< rcurtin> we use perforce at Symantec internally, it's... needlessly tricky and all the words perforce documentation uses are different than the rest of the world, so you basically have to learn a new language first to understand any of it...
< partobs-mdp> rcurtin: Perforce is proprietary (Stallman.jpg)
< zoq> there is git lfs which works with large files
< partobs-mdp> zoq: Thanks, never heard of that - I think I know how can I back up my ResNet :)
< rcurtin> truth, their marketing documents make it hard to understand too
< rcurtin> at another job I used a product called MKS SourceSafe (if I remember the name right), that was an awful disaster
travis-ci has joined #mlpack
< travis-ci> mlpack/mlpack#3046 (master - 4f313da : Marcus Edel): The build was fixed.
travis-ci has left #mlpack []
< rcurtin> partobs-mdp: fixed a few compiler warnings and style issues in d61183f, feel free to take a look and let me know if I screwed anything up
< zoq> rcurtin: We should think about runnung a matrix build on travis (Debug/Release).
< rcurtin> yeah, I was thinking the same
< zoq> Let's see if the runtime is going to be a problem...
< rcurtin> I am actually working on reducing the runtime of some tests now, maybe that can help also
< rcurtin> with the python bindings, the build will definitely take longer, so if the matrix build has to execute in the same time as the regular build, I think it will be a problem
< rcurtin> to me it's pretty clear at this point that build time + test time is a significant problem, so I am trying to see what I can do to help it, although I don't want to devote too much time there (I would rather spend it doing benchmarking, making parts of mlpack faster, etc.)
< rcurtin> from earlier investigations, I remember that the vast majority of compile time is actually the time it takes to parse all the included header files
< zoq> yeah, if we go with the two options, we can deactivate the python bindings if DEBUG=ON.
< rcurtin> so cutting down on necessary includes is really helpful
< rcurtin> yes, definitely that would be necessary
< zoq> Agreed
< rcurtin> yeah---thanks for getting that running
< partobs-mdp> zoq: rcurtin: I'm trying to get something going with the idea of the "blind" HAM (with constant SEARCH(x, y) = 1/3). I catch an error when I try to create such FNN models (more in the PR discussion: https://github.com/mlpack/mlpack/pull/1048) Can anyone take a look at the problem?
< partobs-mdp> As a follow-up, how do I set bias value for Linear layer?
< rcurtin> partobs-mdp: what is the error? I see the discussion about a blind HAM, but not any particular error message
< rcurtin> maybe I overlooked it?
< partobs-mdp> It's from the latest commit - it crashes on build
< partobs-mdp> There is a huge error message, I'll try to attach it to PR dicsussion
< rcurtin> got it
< rcurtin> travis will probably generate it too if you wait a little while
< rcurtin> but it is time for bed here, so I don't think I can manage to stay awake for that
kris1 has quit [Quit: kris1]
< zoq> partobs-mdp: Can you include '#include <mlpack/methods/ann/layer/layer.hpp>' instead of '#include <mlpack/methods/ann/layer/layer_types.hpp>' and test again?
< zoq> About the bias layer, you could set a value inside the layer itself, e.g.: bias.fill(..) inside of the Reset function, or if you know the layer size you could do model.Parameters().subvec(..., ...).fill(). In the future we should add layer.Bias().fill().
< partobs-mdp> zoq: Well, now it compiles :) However, when I run these: FFN<MeanSquaredError<> > embedModel; embedModel.Add<Linear<> >(nDim, nDim); std::cerr << embedModel.Parameters() << "\n"; I get that:
< partobs-mdp> [matrix size: 0x0]
< partobs-mdp> That's weird - what am I doing wrong?
< zoq> ah, right call model.ResetParameters() once before you call model.Parameters()
< partobs-mdp> zoq: Okay, now it works. It gives me a 20-dim vector ([4 inputs + bias] * 4 outputs). Where are bias values in that vector?
< zoq> submat(4 * 4, 0, 4 * 4 + 4 - 1, 0).fill(..) or you can use the index model.Parameters()(4 * 4) = ..., model.Parameters()(4 * 4 + 1) = ...
< zoq> The parameters for the linear layer are: inputSize * outputSize + inputSize
Erwan_ has joined #mlpack
< Erwan_> Hi Ryan, thanks for the answer
< Erwan_> I fixed my yesterday issue by making the serialize() method in the Serializable parent class non virtual (had a talk with boost irc guys)
< Erwan_> So I can use the templated version of the method, like in most of boost examples
< Erwan_> Then, I just loop on my map and call the CreateNVP wrapper that you provide and it does the job
< Erwan_> The problem was more likely related to boost (and bad design on my side)
< Erwan_> So now it's fine :)
< Erwan_> And thanks for your library by the way
< partobs-mdp> zoq: Implemented identity as a FFN. I'll disconnect here - if I manage to connect once again tonight, I'll finish off other transformations - that's going to be helpful for blind HAM (hopefully this one is straightforward)
< zoq> partobs-mdp: Okay, sounds good, I'll take a look at the existing code later today, thanks!
partobs-mdp has quit [Quit: Leaving]
Erwan_ has quit [Quit: Page closed]
kris1 has joined #mlpack
kris1 has quit [Quit: kris1]
kris1 has joined #mlpack
< ironstark> rcurtin: zoq: This is regarding your review on PR #98, out is a vector of matrices. How do I loop through it and change the values to square root of its present values. Suppose I iterate for(size_t i=0; i < out.size(); i++)
< ironstark> then out[i] will be a matrix<double, size, 1>. How do I change the values here using sqrt() from math.h
< kris1> Hi, lozhnikov were you able to look at my comments on Gan PR.
< kris1> What do you think about them.
< ironstark> rcurtin: zoq: This is my r_install script
< ironstark> These are the errors obtained
< ironstark> Looks like there are many dependencies which have to be installed
< kris1> zoq: I updated the Gan PR with your additions have a look…
< zoq> ironstark: Instead to loop over the output; I think it's cleaner to implement euclidean_distance inside the script; take a look at: https://github.com/davisking/dlib/blob/master/dlib/graph_utils/function_objects.h#L17
< zoq> ironstark: instead of using 'const double len = length_squared(a-b);' you can write: 'const double len = std::sqrt(length_squared(a-b));'
< zoq> ironstark: About the dependencies: We could save some time if we use 'sudo apt-get build-dep r-base' to install the necessary dependencies as suggested here: https://support.rstudio.com/hc/en-us/articles/218004217-Building-R-from-source
< zoq> kris1: Okay, let's see.
< rcurtin> Erwan_: ah, ok, that's a better solution, glad you got it figured out :)
< rcurtin> if you have more problems in the future feel free to get in touch