verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
keonkim has joined #mlpack
kris1 has joined #mlpack
kris1 has quit [Quit: kris1]
govg has joined #mlpack
partobs-mdp has joined #mlpack
< partobs-mdp> zoq: rcurtin: Right now migrating back to LayerTypes. To this end, I'm trying to merge Sumedh's code into my PR. However, I get this compilation error (from gru_impl.hpp):
< partobs-mdp> outputHidden2GateModule = new LinearNoBias<>(outSize, outSize);
< partobs-mdp> (weird stuff, only last line is there)
< partobs-mdp> Well, is just doesn't paste T_T
< partobs-mdp> I'll paste the gist in a minute
< partobs-mdp> The strange thing is that it crashes on LinearNoBias (complaining that it doesn't have all the template arguments) but doesn't crash on Linear
< partobs-mdp> Obviously, it just doesn't see LinearNoBias in using LayerTypes = boost::variant<...>, but why?
< zoq> partobs-mdp: How does layer_types.hpp look like?
< zoq> partobs-mdp: looks, good have to take a closer look into the issue
kris1 has joined #mlpack
< zoq> partobs-mdp: I can't test it right now, but what happens if you put 'template<typename InputDataType, typename OutputDataType> class GRU;' after the LSTM in layer_types.hpp?
< partobs-mdp> zoq: Didn't work :(
< zoq> partobs-mdp: Okay, I guess what you could do is to remove the GRU related code, I'll see if I can take a closer look into the issue in the next hours.
< zoq> partobs-mdp: Including "gru.hpp" after "lstm.hpp" in "layer.hpp", should solve the problem.
< kris1> lozhnikov: I think the orilley example that you mentioned used the batch norm layer.
< kris1> I don’t think we have that in mlpack right now.
< kris1> Should i skip that layer all together.
< zoq> kris1: You could test: https://github.com/mlpack/mlpack/pull/955
< zoq> Currently it does not work with the convolution layer.
< kris1> Hmmm well i needed it just for that……
< zoq> ah, okay, in this case you probably have to skip the layer for now
< partobs-mdp> zoq: That resolved the issue, but there is still a long way to go - I've got a huge compiler error message. The latest version is pushed.
< zoq> partobs-mdp: Sumedh used another approach to set the Rho: https://github.com/mlpack/mlpack/pull/1094
< zoq> Looks like you missed some files: 'visitor/reset_cell_visitor.hpp' file not found
< kris1> zoq: Do we have some equivalent of the reshape layer available.
< partobs-mdp> zoq: Added reset_cell_visitor and reset_cell_visitor_impl to CMakeLists, still getting error message - it's huge, but rather monotone (it mostly complains on some boost::variant issue)
partobs-mdp has quit [Remote host closed the connection]
< zoq> kris1: What does the reshape layer do?
< kris1> Well the example i am looking at is something like this. There is linear layer Whose output would column vector. Which is reshaped into 3d matrix where the channels = 1 to feed into a CNN. The parameters of the linear are being learned also.
< zoq> kris1: So you like to use Linear -> Conv?
< kris1> Yes exactly….
< kris1> Just look at the generator part
< zoq> kris1: You don't need a Reshape layer, the conv layer handles the reshape for you: take a look at the cnn test
< zoq> I see, so in mlpack you don't need a reshape layer
< kris1> I think i get it thanks...
< zoq> if you need help with the model definition let me know
< kris1> yup sure…
sheogorath27 has left #mlpack []
shikhar has joined #mlpack
< zoq> partobs-mdp: 'mlpack/methods/visitor/forward_with_memory_visitor.hpp' file not found we could just remove the header for now, it's only used by the NTM model
< zoq> or maybe not ...
< zoq> partobs-mdp: Looks like you missed to add FFN<NegativeLogLikelihood<>, RandomInitialization>*, in layer_types.hpp
< zoq> partobs-mdp: You should use: boost::apply_visitor(ForwardVisitor(std::move(h), std::move(searchOutput)), search); instead of boost::apply_visitor(ForwardVisitor(std::move(h), std::move(searchOutput), search));
< zoq> partobs-mdp: Also it looks like the TreeMemory uses the FFN class instead of LayerTypes.
< zoq> partobs-mdp: And you might need to switch to LayerTypes instead of LayerTypes&.
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
< rcurtin> just a heads-up: there will be some downtime for masterblaster probably late this week or next week; I've managed to convince some people to install a Titan X GPU
< rcurtin> it seems like no long-running benchmark jobs or anything are running, so I think this should be no problem
< zoq> no way ... awesome :)
< rcurtin> too early to celebrate yet, but it seems likely at this point :)
< rcurtin> a second Titan X should be able to be added a few weeks later, but we need to order some extra hardware and new power supplies for that
< rcurtin> it looks like our power usage for masterblaster is pretty serious already: http://ratml.org/misc/mb_power.jpg
< zoq> oh, wonder what the peaks are
< zoq> also, I forgot ... I'll keep my excitement low at least for the moment
< rcurtin> I guess the peaks are probably big jobs starting
< rcurtin> Erwan_: sorry for the slow response, I have been traveling
< rcurtin> I don't do anything special for deserialization, typically that is just used in the mlpack main programs with 'data::Load()' and 'data::Save()'
< rcurtin> Erwan_: if you want to open a bug report, at this point it sounds like what is going on in your case is a little complex, so maybe that is the easier way to solve it instead of over IRC
shikhar has quit [Quit: WeeChat 1.7]
vivekp has quit [Ping timeout: 248 seconds]
vivekp has joined #mlpack
govg has quit [Ping timeout: 240 seconds]
mikeling has joined #mlpack
vivekp has quit [Ping timeout: 248 seconds]
vivekp has joined #mlpack
< kris1> Hi, zoq there
< kris1> I have implmeented that example i am just having difficulty with generator part
< kris1> I am confused what should be the padding size for the generator network. Since the strategy is same padding that means the input and output dimension are same
< kris1> my calculation for padding show a very large value so i am confused could you take a look. I am using the formulas given here http://cs231n.github.io/convolutional-networks/#conv
< kris1> padding size is coming out be around 29 which seems wrong to me....
< kris1> lozhnikov: I also tried a classification test for GAN but the results were not good….. I used the gaussian(0, 1) as real dat aand uniform(-5. +5) as noise and trained the gan using that
< kris1> Then i generated further data using the same distribution and tried to predict their lables using the Discriminator. I was getting around 33% accruracy i don’t know why
< kris1> But i did not explore the idea further.
vivekp has quit [Ping timeout: 246 seconds]
vivekp has joined #mlpack
mikeling has joined #mlpack
vivekp has quit [Ping timeout: 260 seconds]
kris1 has joined #mlpack
vivekp has joined #mlpack
< kris1> Figured out the convlution part....
kris1 has quit [Quit: kris1]
kris1 has joined #mlpack
< rcurtin> zoq: as I go through the static analyzer output, I came across this one:
< rcurtin> the issue is that i isn't used in the inner loop, but I don't know enough about the test to know what the right solution is
< rcurtin> I think that you wrote the code, do you have an idea of what the right thing to do is?
< zoq> rcurtin: hm, I don't see any problem with the unused i, however we will rewrite the part anyway, once we implemented the field interface.
< zoq> kris1: The pad size should be < kernel size so unless your kernel size is > 29 I agree it's strange.
< zoq> kris1: Sounds like you figured it out?
< rcurtin> zoq: ok, then I guess it is just a training loop that will train a certain number of times
< zoq> rcurtin: right
< kris1> Well kinda but now there is no segmentation fault but the program still is not working. I used the calculations given here https://stackoverflow.com/questions/37674306/what-is-the-difference-between-same-and-valid-padding-in-tf-nn-max-pool-of-t
< kris1> The only confusion is that tensorflow is using 4 values for padding.
< zoq> different values?
< kris1> and if you go throgh the calculation you would see that pad_top = 1 pad_bottom = 1 - 1 ….
< zoq> Depending on the kernel it might sense to pad differently but it's uncommon, and the current conv layer does not support that.
< zoq> kris1: Looks good for me, if you say it's not working can you elaborate on that?
< kris1> Well i am digging into it but the program for some reasons loops around on the generator.Forward call….
< zoq> hm, I can't see anything right away, probably have to step through the code.
< zoq> btw. I'm curious, what is the status of the RBM code?
< kris1> Well from my side its done.
< zoq> nice
< zoq> excited to test it out
< kris1> Both the rbm and ssRBM. I think lozhnikov said that if he find something else he would comment there.
< kris1> I would not be able to complete the stacked GAN though it seems in the specified time.
< zoq> I see, I don't think that's a problem.
< rcurtin> I figured the parser was tripping over something; I'm not sure if that fixes it correctly
< kris1> The program causes seg fault somtimes but works perfectly other times.
< kris1> I better check with valgrind
< zoq> kris1: good idea
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
< kris1> Hmmm i tried to look at the valgrid message it does a invlid read of size 4 but other than that the error message is pretty obscure….
< kris1> Could you have a look at it i have updated the gist btw.
< zoq> Sure, I'll set it on my todo list for tomorrow.