05:48 < devang_2401_> hi I am Devang. I am a gsoc aspirant are there any beginner level projects i can work on?

08:31 < jenkins-mlpack2> Yippee, build fixed!

08:31 < jenkins-mlpack2> Project docker mlpack nightly build build #182: FIXED in 3 hr 17 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/182/

11:05 < zoq> devang_2401: Hello there, I think there are some issues on github which should beginner friendly.

12:27 < Alkyur> Hey, is anyone who have developed / is developing mlpack online?

12:31 < zoq> Alkyur: Hello there!

12:33 < Alkyur> zoq: I think that I might have found a bug. I am currently solving a nearest neighborhood problem, where I have points in 3D as query set and segments in 3D as refereceset (For every point I try to find closest segment). I use cover tree for this, with euclidean metric (closest point to a segment)

12:34 < Alkyur> However when I had dataset as queryset and its minimum spanning tree as reference set , then I found out that some of the nearest neighbors are incorrect (some distances are much larger than 0)

12:35 < Alkyur> I can send you my debug files if that helps you

12:35 < Alkyur> and I am using mlpack 3.0.4 , mst is also correct , as well as is my metric.

12:36 < Alkyur> It seems that also if all the points are on the same line , say (0,0,0) , (0,0,1) , (0,0,2) ... the output is correct

13:54 < rcurtin> Alkyur: I saw your email, I'll respond when I have a chance

14:40 < travis-ci> saksham189/mlpack#27 (rem - dee9460 : Saksham Bansal): The build passed.

14:40 < travis-ci> Change view : https://github.com/saksham189/mlpack/compare/69683b75f67f^...dee9460d27ef

14:40 < travis-ci> Build details : https://travis-ci.org/saksham189/mlpack/builds/477344569

15:13 < travis-ci> saksham189/mlpack#28 (rem - 3b02457 : Saksham Bansal): The build passed.

15:13 < travis-ci> Change view : https://github.com/saksham189/mlpack/compare/dee9460d27ef...3b024577bfbb

15:13 < travis-ci> Build details : https://travis-ci.org/saksham189/mlpack/builds/477346288

17:09 < manish7294> rcurtin:zoq: I was going through RL code and noticed that mountain_car environment does not employ goal position variable, instead terminal state is being bounded by max position. Though max position is being set to the 0.5, which openai uses for goal position. Is there any particular reason for not using goal position here?

17:16 < rcurtin> manish7294: hey there, hope you are doing well! I don't have any idea about the RL code (I haven't spent any time with it really) so I don't have a good answer for the question

17:16 < rcurtin> (LMNN is still on my list to debug, but it has been pushed further down by various things)

17:18 < manish7294> rcurtin: I hope you are doing well too. Sorry for the delay from my side. I got busy with other things, and hope to get hold of LMNN soon :)

17:18 < rcurtin> yeah, it sounds like we are both in the same situation :)

17:18 < rcurtin> I have to get lunch now, but maybe we can catch up later

17:18 < manish7294> sure, see you soon. I will wait for marcus. Maybe he can help me here with RL doubt.

18:07 < zoq> manish7294: Not sure it makes a difference maxPosition has to be greater than or equal to the goal position, and in each case we will return once we reached the maxPosition, maybe I missed something?

18:23 < manish7294> zoq: Right, I agree it doesn't make much of a difference. I just wanted to point out the difference in terminologies with reference to openai implementation. Here we will just have to accept that car will always stop at the max position (here the terminal state), which will give a positive reward and can never go beyond that terminal state.

18:25 < zoq> manish7294: I think the same appleis for openai since the position is clipped: position = np.clip(position, self.min_position, self.max_position)

18:26 < manish7294> zoq: But I guess, in openai we can move pass the terminal state which is marked by goal position.

18:27 < zoq> manish7294: Right, but only if max_position > goal_position?

18:28 < manish7294> zoq: right

18:28 < manish7294> which can't be possible in mlpack version

18:30 < zoq> I don't mind to change that part, if someone likes to take that up.

18:32 < manish7294> zoq: I guess that's not a big of an urgent issue. Maybe we can open a ticket as a starter task, if anyone may like to take it up?

18:32 < zoq> manish7294: Sounds like a good idea.

18:33 < manish7294> zoq: Then I will go ahead and open an issue.

18:33 < zoq> manish7294: Great :)

18:33 < manish7294> zoq: Thanks :)

19:54 < rcurtin> manish7294: if you have a few extra minutes to modify the description of #1647, I've definitely found that the more detail you can give for people to understand what to do, the quicker the change gets made :)