Expand the net.input list to all input layers #4344
Conversation
src/caffe/net.cpp
Outdated
| // Collect Input layer tops as Net inputs. | ||
| if (layer_param.type() == "Input") { | ||
| if (layer_param.type() == "Input" || | ||
| layer_param.type().find("Data") != std::string::npos) { |
There was a problem hiding this comment.
This check seems fragile. Wouldn't a more general definition of input be any layer that has a top but no bottom?
|
Updated the input check to be more robust: it checks that the layer has outputs but no inputs. |
|
Is there a particular reason why you want to do this? The only input layers should be layers of type "Input"... otherwise they are layers that compute something or read data from somewhere. One can have, e.g., random numbers which have no bottoms but are not inputs. |
|
Well, I came across quite a few uses of network analysis (e.g. feature visualization) that are scripts in python that just take the "normal" prototxt of the network and set the input by hand (because they are optimizing the input to maximize the activation of a certain neuron, for instance). The code of the input layers is not called here, and the solver cannot be used, of course. |
|
I don't agree with this patch. Input layers are exactly that: bare inputs w/o logic that merely hold data. A solver can have a training net with Closing, as I don't see what problem this solves. Thanks for thinking of potential interface improvements all the same. |
Currently, the input list of a network is only used (AFAIK) to provide a nice interface in python/caffe. However, it only includes the layers of type "Input", not all the input layers.
I understand that the idea was that the list is only the layers that need to be set by hand, but when manipulating a network by hand, having those layers in the input list is usually easier.
For instance, the
forwardmethod in python can only set the input data if the layer is in the input list.Moreover, it mirrors more closely the behaviour of the output list.