Behavior when not specifying the blobs_lr in a layer

[tdomhan]

Is it intended, that the default behavior, when not specifying the blobs_lr in a layer, is to not use backpropagation on this layer?
I just spend a couple of hours trying to figure out why my network wasn't working until I realized that this was the cause.
I personally think this is a very dangerous behavior and the default should be to set the learning rate multiplier for this blob to 1. Only if someone explicitly sets the blobs_lr to 0, backpropagation should be deactivated.

[huangjunshi]

I think if the blobs_lr is 0, one can also set force_backward (the member of NetParameter) as true to operate back propagation in the training net.

[Yangqing]

@tdomhan That is indeed a bad design. Will change default to 1.

[Yangqing]

Fixed in a302daf. Congratulations! You filed issue #100.

[sguada]

Would that affect the Test phase? Or the finetuning?

Sergio
On Feb 12, 2014 5:32 PM, "Yangqing Jia" notifications@github.com wrote:

Closed #100 #100.

Reply to this email directly or view it on GitHubhttps://github.com//issues/100
.

[Yangqing]

My bad, fixing things in the afternoon droozy mode apparently is not the best. Just realized that the current fix has one caveat: when a layer has no trainable parameters, it will always trigger need_backwards. We will need to add functionality to also check if the layer has parameters to train.

Repoened and I will fix later.

[shelhamer]

Perhaps we should have a dev branch so we can keep master a little more stable #101

[Yangqing]

Fixed the bug in #103.

@sguada Testing phase will not be affected since backward won't be actually carried out. Finetuning will not be affected (if we set blobs_lr to be 0, we will still not do backpropagation, as intended).

I am going to abuse my power a little bit and simply merge that pull request...