ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
< rcurtin>
shrit[m]1: yeah, I guess for CLI11 we need to include the header or have an autodownloader
< rcurtin>
it doesn't seem to be available in debian
< shrit[m]1>
@rcurtin An autodownloader is already included in the pull request I am just going to create.
< shrit[m]1>
Even I prefer to have the header included as one file.
< rcurtin>
cool---personally, I don't have too much of an opinion. it doesn't seem like a problem to include the CLI11 source in our repository, but we should find some way to make sure it is updated reasonably often
< shrit[m]1>
That is true, but looking at the actual code for parsing command line, it is rarely updated, in this case, we can update it each time there is a new version of mlpack
< shrit[m]1>
mlpack 4, 5, or 6
< rcurtin>
that would seem reasonable to me; I certainly would hope that a command line parsing library is quite stable :-D
< shrit[m]1>
Or of course, if we have some kind of urgent modifications
< shrit[m]1>
That is good, once #2459 is full reviewed we can add the the CLI as one file, just to make review easy :D
< rcurtin>
:)
< shrit[m]1>
#2459 should be easy to review, but I am not sure about cereal #2458
< rcurtin>
the diffs are very big, it might take me a day or two :-D
< shrit[m]1>
There is one major diff is for CLI -> CMD (namespaces)
< shrit[m]1>
otherwise I have modified about 4 files for CLI11
< shrit[m]1>
I will have to go to sleep now, see you tomorrow
< rcurtin>
sounds good, talk to you then :)
< rcurtin>
hmmm, maybe this system is too old? the case has a Windows XP license on it...
< rcurtin>
an old core 2 system with 4GB RAM... I think it will work, but it won't be fast :)
< jonpsy[m]>
kartikdutt18: hi , sorry for the delayed response. Could you clarify the difference between the two Split methods in your model repository?
< jonpsy[m]>
From what I gather, they're both used for image type of dataset
< kartikdutt18[m]>
The difference is based on input template whether bounding boxes for images are same or not. If not, we need to use field type. I don't think the second implementation would be of any use for your PR.
< kartikdutt18[m]>
<zoq "kartikdutt18: Also, not sure if "> Hmm, Maybe there should be a paper for YOLOv5.
< jonpsy[m]>
i see
< jonpsy[m]>
btw, if we're working on image. There shouldn't be ```arma::field<arma:;vec>``` type of input, right?
< jonpsy[m]>
image are passed around as ```arma::field<arma::mat>``` here, right?
< kartikdutt18[m]>
That's for the bounding box. Also in mlpack images are expressed in columns.
< jonpsy[m]>
images are expressed as ```arma::field<arma::vec>``` only ? or both columns and mat, only columns kinda doesn't sound intuitive to me
< jeffin143[m]>
It will be nice to get some feedback/suggestions :)
< jeffin143[m]>
👌
< chopper_inbound[>
jeffin143: 🙂
< jeffin143[m]>
chopper_inbound (@chopper_inbound:matrix.org): you were using something similar to matplotlib for c++ , if I am not wrong ?
< chopper_inbound[>
in this project?
< jeffin143[m]>
No , while application period was ongoing , weren't you trying for visualisation tool ? chopper_inbound (@chopper_inbound:matrix.org)
< chopper_inbound[>
Naah... Maybe someone else.
< jeffin143[m]>
Oh 😂 sorry
< jeffin143[m]>
I have a very bad memory
< chopper_inbound[>
I think it's not your fault. I should change my username here :D
< rcurtin>
chopper_inbound[: thanks for the update, I enjoyed reading it :)
gtank___ has quit [Ping timeout: 256 seconds]
gtank___ has joined #mlpack
petris_ has joined #mlpack
petris has quit [Remote host closed the connection]
vansika__ has quit [Ping timeout: 256 seconds]
vansika__ has joined #mlpack
< chopper_inbound[>
rcurtin: 🙂
< shrit[m]1>
@rcurtin what is reference set is used in Knn? I undertand perfectly the query set, but if they are different what is the usage of reference set?
< shrit[m]1>
Suppose that the reference set is the dataset, It says If I did not specify a query the reference set is used as a query. Does that means that each line of the reference set will be used to find its neighbors and so on untill the end of the dataset?
pickle-rick[m] has quit [Quit: Idle for 30+ days]
robertohueso has left #mlpack []
hachifish[m] has quit [Quit: Idle for 30+ days]
robertohueso has joined #mlpack
hemal[m] has left #mlpack []
mlozhnikov[m] has left #mlpack []
Nakul[m]1 has quit [Quit: Idle for 30+ days]
abhisaphire[m]1 has left #mlpack []
srinivasyadav224 has quit [Quit: Idle for 30+ days]
< rcurtin>
shrit[m]1: the "reference set" is the set of points in which we are searching, and the "query set" is the points for which we want the nearest neighbor
< rcurtin>
i.e., if the reference set is R and the query set is Q, then mlpack_knn is finding the K nearest points in *R* to each query point in Q
< rcurtin>
if Q = R, then the problem reduces to "all-k-nearest-neighbor"
petris_ is now known as petris
< HimanshuPathakGi>
Hey @rcurtin I need to add an implementation for SMO in ensmallen for kernel_svm or Is there any other way I can do that
< rcurtin>
HimanshuPathakGi: I think SMO is specific to SVM, so probably adding something to ensmallen won't make sense since it is not general
favre49 has quit [Remote host closed the connection]
< HimanshuPathakGi>
> `rcurtin on Freenode` Himanshu Pathak (Gitter): I think SMO is specific to SVM, so probably adding something to ensmallen won't make sense since it is not general
< HimanshuPathakGi>
Ok I will try to implement it in the implementation of kernel_svm :+1:
< rcurtin>
correct me if I'm wrong about that---I'm not an SMO expert. but I don't think that we could optimize arbitrary objective functions with SMO
< HimanshuPathakGi>
Yes, it is used to solve quadratic problem in SVM
< HimanshuPathakGi>
I am also not expert in it but just started learning about it Sorry, if I am wrong. I think I should first read more about it I will ask for help if I got stuck.
< rcurtin>
zoq: question for you about the Lookup layer
< rcurtin>
in lookup_impl.hpp, line 37, it looks like this will only work for a batch size of 1
< rcurtin>
i.e., when we do `output = weights.cols(arma::conv_to<arma::uvec>::from(input) - 1);`, this can only work if input is a single column
< rcurtin>
would a more correct implementation be something like...
< rcurtin>
or... is the idea for the Lookup<> type that we pass in a single index and then get back an entire row?
< rcurtin>
so, e.g., the input should be 1-dimensional
ImQ009 has quit [Quit: Leaving]
mlozhnikov[m] has joined #mlpack
< zoq>
rcurtin: You are right this only works for batchsize=1 and yes the input is an index and it should return a row.
< zoq>
rcurtin: I guess this is one layer we missed in the transition.
< rcurtin>
hmmm, ok, so the shape of the input should be 1 row and batch_size columns, and the shape of the output should be weights.n_rows rows and batch_size columns?
< rcurtin>
I just posted an updated comment on #2434, I think actually if what I wrote in the last message is correct, then the implementation already supports large batches
< rcurtin>
but if the user passes in something that's higher than one-dimensional (like if they pass in a one-hot encoded representation), then the encoding will fail
< rcurtin>
maybe Ilias will tell us a bit more about his setup and it will be clearer what the issue is, we'll see
< rcurtin>
ok, I brought a new build slave online---bigglesworth.ratml.org (I decided to go with a different movie for hostnames this time)
< zoq>
:)
< rcurtin>
it's one of the few old systems I have from GT... an old i5 with 6GB RAM
< rcurtin>
I have another one to plug in too, but first I need to make sure that my little "network closet" isn't going to overheat :)
< zoq>
haha ... hopefully it's not too loud
< rcurtin>
nah, it's just a desktop, so no real noise at all
< rcurtin>
my "network closet" is quite literally a cupboard under the stairs
< rcurtin>
so I am a bit worried about airflow issues :)
< rcurtin>
in the worst case I'll just cut a hole in the drywall and put a vent there so it gets airflow, but I want to make sure that I need to before putting in the effort :)
AtharvaKhandaitG has quit [Ping timeout: 256 seconds]
AtharvaKhandait4 has joined #mlpack
NishantKumarGitt has quit [Ping timeout: 256 seconds]
NishantKumarGitt has joined #mlpack
< rcurtin>
zoq: is there any chance I could get a shell on polar to try and reproduce the valgrind issues?
< rcurtin>
actually, I suppose I can just use the jenkins account if that's okay with you
< zoq>
rcurtin: Sure, I can also create another account up to you.
< rcurtin>
nah, I can use the existing one, it should be ok
< rcurtin>
oh, actually, nevermind, the credentials are different---so probably setting up a new account is easiest
robotcatorGitte4 has joined #mlpack
RudraPatil[m]1 has joined #mlpack
Cadair has joined #mlpack
jonpsy[m] has joined #mlpack
jeffinsamGitter[ has joined #mlpack
abernauer[m] has joined #mlpack
UmarGitter[m] has joined #mlpack
AniThoGitter[m] has joined #mlpack
khimrajGitter[m] has joined #mlpack
DirkEddelbuettel has joined #mlpack
OmarWagih1Gitter has joined #mlpack
TrinhNgo[m] has quit [Ping timeout: 244 seconds]
benpa[m] has quit [Ping timeout: 240 seconds]
Manav-KumarGitte has joined #mlpack
AbhinavGudipati[ has joined #mlpack
TrinhNgo[m] has joined #mlpack
geek-2002Gitter[ has joined #mlpack
zoq has joined #mlpack
TanayMehtaGitter has joined #mlpack
SakshamRastogiGi has joined #mlpack
Param-29Gitter[m has joined #mlpack
Param-29Gitter[m has quit [Changing host]
Param-29Gitter[m has joined #mlpack
SriramSKGitter[m has joined #mlpack
DivyanshKumar[m4 has joined #mlpack
aoeuiiueoa[m] has joined #mlpack
nishantkr18[m] has joined #mlpack
EL-SHREIFGitter4 has joined #mlpack
kritika12298Gitt has joined #mlpack
AbdullahKhilji[m has joined #mlpack
Valliappan_CAGit has joined #mlpack
PulkitgeraGitter has joined #mlpack
birm[m]1 has joined #mlpack
maddogx[m] has joined #mlpack
JoelJosephGitter has joined #mlpack
RoHitRushilGitte has joined #mlpack
MrityunjayTripat has joined #mlpack
robotcatorGitte4 has joined #mlpack
RudraPatil[m]1 has joined #mlpack
jonpsy[m] has joined #mlpack
jeffinsamGitter[ has joined #mlpack
abernauer[m] has joined #mlpack
UmarGitter[m] has joined #mlpack
AniThoGitter[m] has joined #mlpack
khimrajGitter[m] has joined #mlpack
DirkEddelbuettel has joined #mlpack
OmarWagih1Gitter has joined #mlpack
benpa[m] has joined #mlpack
Cadair has joined #mlpack
< zoq>
chopper_inbound[: Thanks for the update, commented on #2404.