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/
< AyushSingh[m]>
I am now interested in adding Triplet Margin loss. Should I review and give comments in <https://github.com/mlpack/mlpack/pull/2208> or start afresh on it?
< AyushSingh[m]>
(edited) ... am now interested ... => ... am interested ...
ImQ009 has joined #mlpack
< zoq>
AyushSingh[m]: Would be great if you could leave a comment on the issue, that you are working on the loss function.
< NippunSharmaGitt>
The `InputSize()` function returns `inSize` but we know that `inSize` refers to the number of feature maps and not the total input size, which should be `inputHeight * inputWidth * inSize` .
< NippunSharmaGitt>
Is this a bug ?
< AvikantSrivastav>
What does `REQUIRE` function do, does it check if the two parameters are same? Or the have the same memory?
< NippunSharmaGitt>
@AvikantSrivastava i think it checks if two variables have same value
< AvikantSrivastav>
What if we pass memory address?
< AvikantSrivastav>
For writing test cases of layers, do I need to compile the layers into a model, or I can simply check by comparing forward pass outputs.
< zoq>
NippunSharmaGitt: InSize() is only there to get/modify the number of feature maps, what we do inside the layer itself should be independent. Maybe I didn't get the point?
< NippunSharmaGitt>
@zoq My Question is that, the comment above `InputSize()` says `Get the input size` which I think refers to the total size of the input ?
< zoq>
NippunSharmaGitt: I see, in this case the naming is just bad, it also refers to the number of input maps.
< zoq>
NippunSharmaGitt: The idea here is that we like to use the same names for each layer.
< zoq>
NippunSharmaGitt: For the Convolution layer that is confusing.
< zoq>
NippunSharmaGitt: Mainly each parameter that you see in the constructor is exposed as a method as well.
< NippunSharmaGitt>
Okay that clears it up. Thanks
ImQ009 has quit [Read error: Connection reset by peer]
< NippunSharmaGitt>
Yes. I observe that pattern in all the layer files I have seen
< zoq>
NippunSharmaGitt: To something that makes more sense.
< NippunSharmaGitt>
I see that the `predictors` parameter inside the `Train` function in `ffn.hpp` is supposed to be a `arma::mat`. But if we are loading images then would it not be a `arma::cube` ?
< NippunSharmaGitt>
> `zoq on Freenode` Nippun Sharma (Gitter): To something that makes more sense.
< NippunSharmaGitt>
Okay. I will open a PR for this
< zoq>
Thanks!
< zoq>
Good point, the idea here is that we like to use the same data type between methods, which is arma::Mat<eT>.
< zoq>
So to represent images we store each channel in it's own column.
< NippunSharmaGitt>
> I see that the `predictors` parameter inside the `Train` function in `ffn.hpp` is supposed to be a `arma::mat`. But if we are loading images then would it not be a `arma::cube` ?
< NippunSharmaGitt>
@zoq can you please explain this ?
< zoq>
Sure, so let's say you like to load an RGB image of size 10 x 10, so the matrix that holds that images is of size (10 * 10, 3)
< zoq>
matrix.col(0) has all the values for the R channel.
< zoq>
matrix(1) has all the values for the G channel.
< zoq>
matrix.col(1)
< zoq>
Ahh, forget what I said.
< zoq>
It's matrix(imageWidth * imageHeight * Channels, number of images)
< zoq>
so the image is vercorized and stored in a single column
< zoq>
So matrix.col(0) = [R values, G values, B values]
< zoq>
Does that make sense?
< NippunSharmaGitt>
Okay. So we are flattening each channel of an image into a single vector and then concatenating all the formed vectors and represent this as an image ?
< zoq>
Correct.
< NippunSharmaGitt>
the vectors are concatenated to form a single long vector. Did I get it right ?
< zoq>
yes
< NippunSharmaGitt>
Thanks for clearing this
ImQ009 has joined #mlpack
qur70 has joined #mlpack
qur70 has quit [K-Lined]
ImQ009 has quit [Read error: Connection reset by peer]