Add NeuralNet.partial_fit method that trains for only one epoch

[dnouri]

As suggested in Lasagne/Lasagne#12 (comment)

[BenjaminBossan]

An idea for discussion: fit could have a num_epochs keyword that allows to override the self.max_epochs if set to something other than None, which is the default. Although this is a departure from sklearn's way, it should not interfere and is a little bit more flexible. partial_fit would then just call fit(X, y, num_epochs=1).

On a more general note, is partial_fit the right term here? My understanding of sklearn's partial_fit is that it allows to learn on a subset of the total data (hence you have to explicitely pass the classes). This is not what is done here. fit already allows to train on part of the data and classes are defined by the architecture.

Finally, is this a good time to address #69 and #138?

[dnouri]

Good point about passing a epochs kwarg to fit. I've made the change.

I've also made it accept a classes argument just for API compatiblity, but it's ignored. I guess that's better than having no such argument?

The main idea here is to allow the user to "take control" of the training loop, e.g.

for X_epoch, y_epoch in generate_data(X, y):
    net.partial_fit(X_epoch, y_epoch)

(Of course you can set max_epochs=1 today and just use fit for that. (And now you can also pass epochs=1 to fit.) But I guess using partial_fit makes that more explicit and less hacky.)

I think this use case is pretty much in line with the kind of "online learning" that scikit-learn allows you to do with partial_fit: It will use the data that you pass it to fit, then returns for you to call it again with more data. You can also choose how often you'll pass the same data, knowing that you're using SGD under the hood, and that it makes sense to pass the same data more than once.

I'm not sure about the other issues you mention. I think this would solve #69 already, as I can now define the size of one epoch to be as small as I want, and thus get feedback much quicker. Let me know what you think.

[BenjaminBossan]

I see why partial_fit has its use, I was just worried that under the hood, it does not do the same thing as in sklearn. In stochastic_gradient.py, e.g., you can see that fit is a special case of partial_fit, whereas here, it is the opposite. When you use SGDClassifier's partial_fit, it also does not imply that only one epoch is trained, in contrast to how its done here. For the user, all that probably does not matter (except if there are some interactions with other sklearn functions that I'm not be aware of).

#69 is probably solved with this. I wondered whether it would be possible to somehow cram the issue with callbacks after epochs into this, but that is probably better left for another day.

[dnouri]

OK, thanks for the clarification. I get what you mean now.

I guess the fact that fit can already be called more than once and continues training isn't 100% in line with scikit-learn. Given that we have this fit behaviour already I think it makes sense to make use of it, rather than having fit call partial_fit, which would require bigger changes.

I'll make sure to point out in the docstring of partial_fit that it's training only for one epoch. This behaviour I think is the most sensible, and it allows you to put the epoch generation loop outside where you have total control of number of epochs.

[dnouri]

I wondered whether it would be possible to somehow cram the issue with callbacks after epochs into this, but that is probably better left for another day.

Can't this be solved by using a sufficiently small epoch size and partial_fit now? It does force you to move any data generation code from your batch iterator into your own loop; acceptable?

[BenjaminBossan]

Given that we have this fit behaviour already I think it makes sense to make use of it, rather than having fit call partial_fit, which would require bigger changes.

Definitely.

Can't this be solved by using a sufficiently small epoch size and partial_fit now? It does force you to move any data generation code from your batch iterator into your own loop; acceptable?

Yeah, its possible that way. If this were something that more people needed, I believe it would still make sense to implement something like an on_batch_finished, though.