mlpack IRC logs, 2017-10-03

Logs for the day 2017-10-03 (starts at 0:00 UTC) are shown below.

October 2017
--- Log opened Tue Oct 03 00:00:01 2017
--- Day changed Tue Oct 03 2017
00:00 -!- kaushik_ [uid193796@gateway/web/] has quit [Quit: Connection closed for inactivity]
01:44 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
01:46 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
04:15 -!- govg [~govg@unaffiliated/govg] has joined #mlpack
11:49 -!- kaushik_ [uid193796@gateway/web/] has joined #mlpack
13:26 -!- mikeling [uid89706@gateway/web/] has joined #mlpack
13:29 < rcurtin> kaushik_: check out commit 623813ab on my branch, that has some further improvements for tree serialization you can incorporate
13:42 < kaushik_> rcurtin: ok, will look into it. I am done with methods/ but need to fix few things I missed.
14:16 < rcurtin> kaushik_: sounds good; when you push that, I can fix the other files that won't currently compile
15:27 -!- govg [~govg@unaffiliated/govg] has quit [Ping timeout: 246 seconds]
15:29 -!- govg [~govg@unaffiliated/govg] has joined #mlpack
15:33 -!- govg [~govg@unaffiliated/govg] has quit [Ping timeout: 240 seconds]
15:36 -!- mikeling [uid89706@gateway/web/] has quit [Quit: Connection closed for inactivity]
16:26 < rcurtin> zoq: I spent a while thinking about how we can avoid duplicating work in calls to Evaluate() and Gradient()
16:27 < rcurtin> I think, the best solution I can come up with, is to add a function 'double EvaluateWithGradient(const arma::mat& parameters, const size_t start, arma::mat& gradient, const size_t batchSize)'
16:28 < rcurtin> and then adapt the optimizers to use that
16:30 < zoq> rcurtin: Sounds reasonable to me, not sure I would go with EvaluateWithGradient, we could just name it Evaluate which takes the gradient as another parameter?
16:30 < rcurtin> yeah, I was wondering about the name
16:30 < rcurtin> if you think just Evaluate() is fine, I'll go with that
16:31 < rcurtin> I think that as a result of Shikhar's project we have a lot of different FunctionType implementations that each need somewhat different signatures
16:31 < rcurtin> I was thinking that also, it could be possible to make an "adapter" so that any FunctionType can be used with any optimizer
16:31 < rcurtin> i.e. if the FunctionType supplies only Evaluate() with a gradient calculation, it is possible to write an adapter that provides both an Evaluate() and a Gradient() call
16:32 < rcurtin> similarly if the function takes a sparse matrix for Gradient(), we can provide an adapter to convert back and forth (although we should issue a warning in a situation like that)
16:32 < rcurtin> and in this way each optimizer could be used with each function type, without requiring the user to write tons of different methods for the FunctionType to make it all work
16:33 < rcurtin> I think that idea might need some more thought, so I'll keep thinking about it... in some cases it would be such a slowdown to do automatic type conversion that it's not even worth doing
16:33 < zoq> Sounds like a good idea, would simplify the overall optimizer classes.
16:33 < rcurtin> yeah, they are a bit overcomplex right now I think
16:33 < rcurtin> but it seems like the complexity is absolutely necessary for speed
16:35 < zoq> So what is the plan, I think it's reasonable to finish #1073 first before implementing the EvalauteWithGradient idea.
16:36 < rcurtin> yeah, I agree, I think what I will do is focus my efforts on fixing the rest of the batch support for #1073, then I can help Rajiv through the process of incorporating those changes
16:37 < zoq> I was planing the same, maybe we can split the work.
16:47 < rcurtin> yeah, sounds good
16:47 < rcurtin> do you want to handle ann/ and I'll take the rest? I think there are only a few function types left
17:08 < zoq> sounds good
17:26 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
17:30 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
17:51 -!- govg [~govg@unaffiliated/govg] has joined #mlpack
20:25 -!- keonkim [keonkim@gateway/shell/panicbnc/x-eiqyncqcwieuvbru] has quit [Quit: PanicBNC -]
21:45 -!- keonkim [keonkim@gateway/shell/panicbnc/x-pkpuenfxamcokdgw] has joined #mlpack
22:39 -!- kaushik_ [uid193796@gateway/web/] has quit [Quit: Connection closed for inactivity]
--- Log closed Wed Oct 04 00:00:52 2017