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/
manish7294 has joined #mlpack
< manish7294> rcurtin: Are you up?
< manish7294> rcurtin: Shall we start working on boostmetric as well? What do you think?
< rcurtin> manish7294: I am awake but I'm sorry, it's been a super busy day. it will have to be tomorrow until I can respond, sorry about that
< rcurtin> if you'd like to start on boostmetric that's ok, but I still have to open lots of LMNN optimization tickets, so we should still take some time on that
< manish7294> rcurtin: No problem, I was thinking to start as I have some time now.
< rcurtin> right, if you have nothing to do now, I see no reason not to get started
< manish7294> great, I will try looking into that, bye :)
manish7294 has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
< jenkins-mlpack> Yippee, build fixed!
< jenkins-mlpack> Project docker mlpack nightly build build #361: FIXED in 3 hr 52 min: http://masterblaster.mlpack.org/job/docker%20mlpack%20nightly%20build/361/
witness_ has quit [Quit: Connection closed for inactivity]
< rcurtin> hi everyone, I wanted to let everyone know that I've quit my job at Symantec and will start a new one at a startup that focuses on in-database machine learning
< rcurtin> the reason I mention it here is that it will affect our build server masterblaster (and the other systems), which are Symantec property
< rcurtin> we can still use them for now, but I'm not sure for how long---it may be two weeks, it may be much longer
< rcurtin> I'll be transitioning Jenkins to run on the domain name ci.mlpack.org, and physically the Jenkins master will be the same system that runs mlpack.org
< rcurtin> so, Jenkins will still run, but I suspect that there may be fewer build executors in the future to do things like the crazy nightly build and weekly builds
< rcurtin> though to be honest, maybe it is a good thing for the environment if we do fewer builds :)
< rcurtin> I'll make these changes over the next week
< zoq> rcurtin: Best of luck at the new position, and let me know if you need any help.
< rcurtin> sounds good, and I am looking forward to the new job... I think it will be a better fit where I can focus more on fast machine learning :)
< rcurtin> I may (but I am not sure yet) be writing Julia bindings for mlpack as a part of my first work there
< rcurtin> and I guess it goes without saying but I won't be disappearing from this community or anything :)
< zoq> rcurtin: Perhaps we could look into jenkins blue ocean :)
< rcurtin> that looks fine to me, do I understand correctly that it's mostly just a set of nice plugins for Jenkins?
< zoq> Yeah, that provides a modern interface.
< rcurtin> ah, ok, well once I move the Jenkins config we can overhaul it with the blue ocean plugins
< sumedhghaisas> rcurtin: Best of luck for the new position Ryan :)
< sumedhghaisas> although, what is in-database machine learning?
< ShikharJ> rcurtin: Congratulations on the new job!
ImQ009 has joined #mlpack
yaswagnere has joined #mlpack
manish7294 has joined #mlpack
< manish7294> rcurtin: Congrats! 👍
< rcurtin> thanks everyone!
< rcurtin> so the idea is this...
< rcurtin> normally you have all your data in some big set of SQL tables or whatever
< rcurtin> then you do some costly join operation across a bunch of tables to get your data matrix
< rcurtin> if you can do machine learning directly in the database you may be able to avoid some joins
< rcurtin> and this can result in large speedups
< rcurtin> anyway I don't know too much more quite yet
< rcurtin> but I do like accelerating things so it sounds good to me :)
manish7294 has quit [Ping timeout: 260 seconds]
zoq has quit [Remote host closed the connection]
zoq has joined #mlpack
< ShikharJ> zoq: Are you there?
< zoq> ShikharJ: I'm here now.
< ShikharJ> zoq: I think we can reuse the code for GAN by implementing just the specific Evaluate and Gradient routines, for different variants.
< ShikharJ> zoq: For GAN and DCGAN, the two policies are same. For WGAN, weight clipping only requires a couple lines of change inside the Gradient function.
< ShikharJ> zoq: For WGAN with Gradient Penalty, we would need to change both the Evaluate and Gradient (as far as I can think).
< zoq> ShikharJ: Sounds like a good idea to me, always nice to avoid code duplication, somehow.
< ShikharJ> zoq: We can keep the core structure similar, and create a separate folder for GAN Evaluate/Gradient policies.
< ShikharJ> zoq: Then, the task of implementing other variants of GAN would be a lot easier for new contributors, and implementing GAN variants can become a secondary priority for mlpack (and we can take up other avenues of work).
< zoq> ShikharJ: Agreed, that would allow us to provide an alias for the different models, so you could directly use GAN, DCGAN, etc.
< zoq> ShikharJ: I like the idea.
< ShikharJ> zoq: Alright, I'll refactor the codebase and push in a few hours then. I'll be off in a second (I have to go for dinner :) ).
< zoq> ShikharJ: Okay, I don't think we have to rush here, as you already said, once the code is refactored, it's a lot easier to add new models.
< ShikharJ> zoq: A few variants may still need a new structure (for example StackGAN), but then this would take care of a lot of variants :)
< ShikharJ> zoq: I've pushed in the changes, but I need a little help with debugging the issues. Could you help me out?
< zoq> ShikharJ: Sure, looks like it's not able to access some parameter.
< ShikharJ> zoq: I thought that declaring the policy classes as friend classes would take care of that problem.
< ShikharJ> Friends of gan.hpp class
< zoq> ShikharJ: Yes, let me comment on the PR.
< ShikharJ> zoq: How would the code-base have to change when someone wishes to add another policy to the GAN? Am I missing something?
< ShikharJ> zoq: I'm not sure I follow.
< zoq> ShikharJ; I would have to make the policy a friend of the GAN class.
< zoq> ShikharJ: So I can't just define my own policy and link against mlpack.
< ShikharJ> zoq: I see, this would come up while using mlpack as an external library right?
< zoq> ShikharJ: right
< zoq> ShikharJ: We could follow the current design, but I think it makes sense to keep that in mind.
< ShikharJ> zoq: So what solution would you propose as an alternative to that? It seems like a good feature to have.
< ShikharJ> zoq: We can try creating the Policy object and passing that directly, but I don't prefer that very much. Is there another way?
< zoq> ShikharJ: We could extend the Evaluate/Gradient function and pass the extra parameter, or as I said on the PR, we could pass the object, and access the Rest via function.Reset().
ImQ009 has quit [Quit: Leaving]
< ShikharJ> zoq: I'm not too positive about changing the existing API as well. What do you think about maybe creating individual classes and making the evaluate and gradient functions pure virtual?
< ShikharJ> zoq: Else we can also go with the current implementation.
< zoq> ShikharJ: Not really a fan of virtual, also not sure the modifications are that significant.
< zoq> ShikharJ: Don't mind to use the current design.
< ShikharJ> zoq: Do we provided that kind of flexibility anywhere else in the codebase? If there is such a pipeline, I have no issues in replicating it.
< zoq> ShikharJ: This is what the optimizer framework does, we just make sure every policy implements Update and pass the parameters, even if they are not used like in this case: https://github.com/mlpack/mlpack/blob/master/src/mlpack/core/optimizers/sgdr/cyclical_decay.hpp#L74
< ShikharJ> zoq: Isn't that the purpose of `virtual`? Why don't we use that? My guess is that would also lead to better compiler optimizations.
< Atharva> Sorry I haven't posted last week's updates. I will do it first thing tomorrow morning. From the next week I will post it on time.
< zoq> ShikharJ: I don't think it would be faster: https://github.com/mlpack/mlpack/wiki/DesignGuidelines#inheritance
< ShikharJ> zoq: Ah, I see, with templates it is probably not a good idea.
< ShikharJ> zoq: What do you have in mind regarding `extending the Evaluate/Gradient function and passing the extra parameter` as you mentioned?
< ShikharJ> Something similar to the cyclical_decay example above?
< zoq> ShikharJ: Yes, currently Evaluate takes: parameters, i, batchSize, but inside the policy we need reset and probably some other parameters, so we could do something like policy.Evaluate(parameters, i, batchSize, reset, ...), or we pass this, and provide some getter.
< ShikharJ> zoq: In that case, I'd vote to stick with the current implementation. If we get a user request for this feature, we can implement this in the future, for now it seems really untempting to extend the Evaluate and Gradient functions in such a manner. Your call?
< zoq> ShikharJ: Agreed, let's focus on the main part for now.
< zoq> ShikharJ: I'll see if I can put some time into the refactoring and if it turns out to be useful, we can merge the ideas.
< ShikharJ> zoq: I'm saying this because even if we modularise the getter into a single object and just extend the parameters by a single getter object, still that getter would lead to performance decrease, as a number of parameters are required. And I'm not too in favour of putting all the parameters directly into the function signature.
< zoq> ShikharJ: Good point, will write a simple benchmark to test the performance.
< ShikharJ> zoq: Evaluate and Gradient tend to access every member element inside the class.
< zoq> ShikharJ: Right, the signature would be huge, so probably not the best idea either.
< ShikharJ> zoq: Inheritance would be pretty tempting in such a scenario, but I see the concern regarding runtimes as well.
< zoq> ShikharJ: Perhaps it's an option here, since the major part is the matrix multiplications.
yaswagnere has quit [Quit: Page closed]