rcurtin_irc changed the topic of #mlpack to: mlpack: a scalable machine learning library (https://www.mlpack.org/) -- channel logs: https://libera.irclog.whitequark.org/mlpack -- NOTE: messages sent here might not be seen by bridged users on matrix, gitter, or slack
<zoq[m]> Any reason why the parameter is called `no_shuffle` instead of `shuffle` - https://github.com/mlpack/mlpack/blob/master/src/mlpack/methods/preprocess/preprocess_split_main.cpp#L105
<zoq[m]> zoq[m]: I think it would be more consistent to use `shuffle`.
<jonpsy[m]> My guess would be: it's relative to the default behaviour. If we assume `shuffle` by default , then we should explicitly specify the opposite (in this case `no_shuffle`).
<jonpsy[m]> zoq: , can new mentor join still? I have a candidate
<jonpsy[m]> * zoq, rcurtin , can a new mentor join still? I have a candidate
<jonpsy[m]> * zoq, can a new mentor join still? I have a candidate
_slack_mlpack_13 has joined #mlpack
CaCode has joined #mlpack
CaCode has quit [Ping timeout: 256 seconds]
CaCode has joined #mlpack
CaCode has quit [Max SendQ exceeded]
CaCode has joined #mlpack
CaCode has quit [Quit: Leaving]
<rcurtin[m]> yeah, we chose `no_shuffle` because `shuffle` is the default
<rcurtin[m]> jonpsy: we should be careful to ensure that GSoC mentors for mlpack are already familiar contributors to the codebase, so at least personally I'd prefer to not add someone completely new
<ShubhamAgrawal[4> <rcurtin[m]> "yeah, we chose `no_shuffle..." <- But general code ideas say that tell users through about default value of parameter
<ShubhamAgrawal[4> and we should set parameter keeping in mind majority of users aren't gonna change it
<ShubhamAgrawal[4> <rcurtin[m]> "Shubham Agrawal: sure, feel free..." <- Can we take it as a medium size GSoC project?
M082AABMEB has quit [Quit: You have been kicked for being idle]
<jonpsy[m]> <rcurtin[m]> "jonpsy: we should be careful..." <- I can respect that. Of course, I wouldn't blindly bring in someone completely unfamiliar/has no experience to mentor.
<jonpsy[m]> I thought initially I'll just consult them when question arises for X, but a student may require more attention, and me consulting them back-n-forth will be a bottleneck. Besides, it will be unfair to extract this amount of work and not give them anything in return.
<jonpsy[m]> Anyway this is just a thought, but I am genuinely curious. Let me know what you think.
<jonpsy[m]> Let's say a person is specialized in X, but knows very less of the codebase. Could they team up with mentor who knows much of the codebase so they can together mentor a student who's work overlaps with X and the codebase? A collaboration , to put it plain.
<jonpsy[m]> > <@ryan:ratml.org> jonpsy: we should be careful to ensure that GSoC mentors for mlpack are already familiar contributors to the codebase, so at least personally I'd prefer to not add someone completely new... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/de1361372cbccff82095ede37a8c188ac948d786)
<jonpsy[m]> * I can respect that. Of course, I wouldn't blindly bring in someone completely unfamiliar/has no experience to mentor.
<jonpsy[m]> Let's say a person is specialised in X, but doesn't know much of the codebase. Could they team up with mentor who knows much of the codebase so they can together mentor a student who's work overlaps with X and the codebase? A collaboration , to put it plain.
<jonpsy[m]> I thought initially I'll just consult them when question arises for X, but a student may require more attention, and me consulting them back-n-forth will be a bottleneck. Besides, it will be unfair to extract this amount of work and not give them anything in return.
<jonpsy[m]> Anyway this is just a thought, but I am genuinely curious. If you think this could work, we could discuss it up over channel email, discuss the case. Lemme know.
<zoq[m]> <rcurtin[m]> "yeah, we chose `no_shuffle..." <- To make it easier to disable it on the cli, but in python it's different since it's a parameter that I set `split(data, no_shuffle=True)`.
<zoq[m]> > <@jonpsy:matrix.org> I can respect that. Of course, I wouldn't blindly bring in someone completely unfamiliar/has no experience to mentor.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/14cf37d2dc70d9d17304ab75c32f27e3bef9405e)
<jonpsy[m]> As a student?
<zoq[m]> yes
<jonpsy[m]> Sure, but who would mentor them? I have 0 experience in their field. And him not in mlpack, but if we mentor together those would cancel out.
<zoq[m]> jonpsy[m]: What project are we talking?
<jonpsy[m]> Remember the 2D Unity game we collaborated on?
<zoq[m]> jonpsy[m]: Yes, I saw your mail, btw. mlpack has no C# bindings.
<jonpsy[m]> zoq[m]: oh, I read it wrong somewhere I guess then.
<rcurtin[m]> jonpsy: thanks for the clarification---I think what you described is fine, we've done things like that in the past. 👍️ what I want to avoid is the situation where an unfamiliar mentor is suddenly solely responsible for a student's PRs, but doesn't have the knowledge of how things are generally done in the codebase, etc. :)
<jonpsy[m]> Okay sounding good! I'm not saying they should be member. I understand thats a separate privelege. I'm saying as a "hop-in professor" if you will
<rcurtin[m]> zoq: I see what you mean about `no_shuffle`, but it might be hard to come up with a solution... maybe it makes sense to open an issue and discuss possible solutions/workarounds there?
<jonpsy[m]> Great, I could put up a post in our github community channel? Put it to vote, that way everyone gets a say
<jonpsy[m]> * Great, I could put up a post in our github community channel? Put it to vote, that way every member gets a say
<zoq[m]> rcurtin[m]: I can do that, I don't think it's an issue, it's just another thing to keep in mind, that the C++ parameter can differ from the bindings/cli/
CaCode has joined #mlpack