01:00 < KimSangYeon-DGU> zoq: The issue of compatibility with OpenAI gym seems to be resolved. :) A pull request for solving the problem will be made.

01:12 < KimSangYeon-DGU> in gym_tcp_api

03:38 < akfluffy> Hey, I have a question. I'm doing a simple FFNN and I was wondering if each data point had to have a label? What if I wanted to predict time series

03:39 < akfluffy> Nevermind, that was a stupid question. I think I can just add rows onto the matrix for multiple data points in one label

04:46 < KimSangYeon-DGU> When using `for` loops, which one would be more preferable in an aspect of design for mlpack between `for (size_t i = 0; i < 10; i++)` and `for (size_t i = 0; i < 10; ++i)`?? it would be a fussy question.

04:49 < heytitle> Hi, I've made a first Dockerfile of mlpack's benchmarks.

04:49 < heytitle> https://github.com/mlpack/benchmarks/pull/135

04:49 < heytitle> could you please give me comments?

04:50 < heytitle> currently, it only works with Shogun.

07:03 < ayesdie> KimSangYeon-DGU: in one of the code snippet in the Design Guidelines, the for loop have ,15++i, so I think it should be the answer to your question (I may be wrong, so I would like to know about that too).

07:09 < ayesdie> It don't show the highlighting on logs correctly, so I'll correct it, `++i`was what I meant.

07:10 < picklerick> @rcurtin any resource on how knn works with spill tree ...

07:18 < KimSangYeon-DGU> ayesdie: Yeah, thanks!! :)

07:26 < KimSangYeon-DGU> I think it is a bit fussy but interesting.

07:31 < ayesdie> Yea, I've also seen `i++` being used at many places in the already existing code.

07:34 < KimSangYeon-DGU> Yes, So I was curious that other developers thought about that like me.

09:01 < jenkins-mlpack2> Project docker mlpack nightly build build #246: STILL UNSTABLE in 3 hr 47 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/246/

11:44 < sumant> I would like to contribute to mlpack. I am thinking about implementing capsule networks and data augmentation techniques. I would also like to implement gradient boosting as it is one of the most widely used algorithms out there.

11:45 < sumant> I'm fairly new to the codebase, so I'll start contributing right after I become familiar with it. Can anyone let me know what you thing about this idea?

11:57 < zoq> sumant: Hello, I would recommend to focus on a single idea, writing meaningful tests takes time.

11:57 < zoq> heytitle: Thanks will take a look once I have a chance.

11:58 < zoq> KimSangYeon-DGU: Great!

11:59 < zoq> KimSangYeon-DGU: From my side it's fine to use both forms.

12:20 < travis-ci> Soonmok/models#1 (master - 405f85c : Soonmok): The build failed.

12:20 < travis-ci> Change view : https://github.com/Soonmok/models/compare/d81c59e2b019...405f85cb50ba

12:20 < travis-ci> Build details : https://travis-ci.com/Soonmok/models/builds/102313550

12:47 < travis-ci> Soonmok/models#1 (master - c9bc2da : Soonmok): The build failed.

12:47 < travis-ci> Change view : https://github.com/Soonmok/models/compare/d81c59e2b019...c9bc2da4f539

12:47 < travis-ci> Build details : https://travis-ci.com/Soonmok/models/builds/102317118

13:10 < sumant> @zoq thankyou for your advice. I'll focus only on capsule network.

14:03 < KimSangYeon-DGU> zoq: Thanks!! :)

14:34 < rcurtin> picklerick: see this paper for knn with spill trees: http://papers.nips.cc/paper/2666-an-investigation-of-practical-approximate-nearest-neighbor-algorithms.pdf

14:35 < rcurtin> heytitle: thanks for opening the PR with the Dockerfile; I'll try to look at it when I have a chance

14:35 < rcurtin> KimSangYeon-DGU: I don't have a strong preference between ++i and i++; both work, but personally I'd typically write '++i'

14:37 < KimSangYeon-DGU> Okay!! :)

15:55 < mulx10> Hello!

15:56 < mulx10> zoq: Please review my PR (https://github.com/zoq/gym_tcp_api/pull/13)

15:56 < mulx10> Thank you!

16:25 < rcurtin> mulx10: there is no need for a reminder, there are tons of open PRs that we have to review and we're aware of each of them :)

16:59 < Hemal> @shardulparab97, saw your message now. About the status of triplet loss function, I've completed the 'forward()', working on backward()

17:18 < Hemal> @zoq, For backward pass of Triplet Loss function, I've saw https://stackoverflow.com/questions/33330779/whats-the-triplet-loss-back-propagation-gradient-formula which says that there would be 3 different losses to be calculated and sent to the output , (all the other loss functions return only 1 float value in backward). So am I going right by returning an arma::mat having 3 losses ?

21:00 < picklerick> in spill tree traversal we are actually implementing hybrid spill trees ??

21:02 < rcurtin> picklerick: I believe that is correct, but I don't remember exactly for sure

21:02 < rcurtin> what we have implemented doesn't look *exactly* the same as in the paper, since we built it on mlpack's dual-tree framework

21:02 < picklerick> well if we are only doing spill tree traversal we would have only done defeatist search

21:02 < rcurtin> and that paper I linked you to didn't consider dual-tree algorithms, just single-tree

21:02 < rcurtin> right---so you can do defeatist search with it, but you can also do search with backtracking

21:03 < rcurtin> (which one you use depends on the SingleTreeTraverser and DualTreeTraverser that's used)

21:03 < rcurtin> oh, and also, we are accepted into GSoC this year :)

21:03 < rcurtin> https://summerofcode.withgoogle.com/organizations/5868789747417088/

21:04 < picklerick> i considered singletreetraverser and looked through the code so if defeatist is true and it is overlapping too then we are doing defeatist tree search

21:05 < picklerick> in the paper we are doing the same i guess for hybrid spill tree

21:06 < rcurtin> I believe so, yeah---but it has been a long time, so I am not 100% sure

21:06 < rcurtin> what you wrote sounds about right though :)

21:06 < picklerick> also i think we are optimizing it further by pruning it too right by not considering farther nodes

21:06 < rcurtin> trust the code more so than me though :)

21:06 < rcurtin> right, but pruning is only needed if we're doing any backtracking (i.e. if we are not doing defeatist search)

21:07 < picklerick> yea and the error is being occured due to that i guess i am thinking of commenting out backtracking and looking into it

21:08 < picklerick> any other suggestions to looking for the bug ??

21:09 < picklerick> @rcurtin for neat idea would we have to implement hyperneat or just neat algorithm also i think it was implemented in previous year gsoc too ??

21:10 < rcurtin> I don't know anything about NEAT or HyperNEAT so I can't say about that

21:10 < rcurtin> but if I'm remembering right, basically what we need to do to fix the issue where we don't get enough results from the spill tree when using defeatist mode,

21:10 < zoq> picklerick: The focus is on NEAT, there is an unfinished PR, which kinda worked.

21:10 < rcurtin> is that we need to stop descending the tree and do BaseCase() on all point pairs before node.NumPoints() < k

21:11 < picklerick> yea the tree isn't encountering enough nodes

21:11 < rcurtin> another way would be to descend to the leaf, run the base cases, then do a little backtracking

21:11 < rcurtin> i.e. backtrack to other nodes until the total number of points encountered is >= k

21:12 < rcurtin> heh, I see that TensorFlow got accepted to GSoC... but their Ideas list is literally just a link to their github issues page

21:13 < picklerick> instead of running the basecase to node.Numpoints we can do like min(node.numPoints(),k) like this ??

21:16 < picklerick> @rcurtin thanks for the pointers i will look into it and work on it :)

21:18 < zoq> interesting

21:21 < rcurtin> picklerick: sorry for the slow response---I stepped out for a minute

21:22 < rcurtin> I'm not sure what you mean by 'running the basecase to node.Numpoints', but I think if you terminate the defeatist search early it can work

21:22 < rcurtin> one tricky part is, the defeatist traversal rules don't know anything about k

21:22 < rcurtin> so you may have to add some member to NeighborSearchRules or something like this that specifies the minimum number of BaseCase() calls that are needed

21:22 < rcurtin> (and you may need to specify that in the other Rules classes too?)

21:23 < rcurtin> I'm not totally sure. try it and see what happens :)