3
$\begingroup$

I'm looking at code from a Google course on how to use Tensorflow. When explaining how to specify the function for generating predictions from an already trained model, the function they define takes a data frame and a number of epochs:

def make_prediction_input_fn(df, num_epochs):
     return tf.estimator.inputs.pandas_input_fn(
     x = df,
     y = None,
     batch_size = 128,
     num_epochs = num_epochs,
     shuffle = True,
     queue_capacity = 1000,
     num_threads = 1
     )

This doesn't make sense to me: isn't the number of epochs something specific to the training phase of a neural network?

When you are predicting data, you just run the data set once through a network that has been already trained. Why would you need to specify a number of epochs?

$\endgroup$
  • $\begingroup$ @Sycorax this code is provided by Google themselves as part of a formal training course (Which my employer is paying good money for). I assume that's it was properly QA'd. $\endgroup$ – Skander H. Jun 7 '18 at 2:50
  • 9
    $\begingroup$ There is a German saying that can be translated as "Even smart people only cook with water." Plus, extremely competent people in domain A (e.g., software engineering) may have learnt all they know about domain B (e.g., statistics or ML) from Wikipedia or a MOOC and still believe they are qualified to teach domain B. So I'd say that @Sycorax' explanation has the highest a priori probability of being correct. $\endgroup$ – Stephan Kolassa Jun 7 '18 at 9:24
  • 1
    $\begingroup$ @Sycorax I don't see where a trained model is in this piece of code. My first guess is that this code actually does the training too. $\endgroup$ – amoeba Jun 11 '18 at 15:20
6
$\begingroup$

[I]sn't the number of epochs something specific to the training phase of a neural network?

You're correct -- the number of epochs is just the jargon describing how many total passes the model has made over the entire training data set. Purely in terms of mathematical terminology, an "epoch" is not really a relevant concept for the purposes of prediction, since at the time that you are obtaining predictions for some data, the model parameters are not changing. Purely in the abstract, you could, if you so desired, supply one sample at a time to the network to obtain a prediction, or all of them at once, or anything in between. Any of these configurations would yield the same results, since all parts of the model are fixed (i.e. it is not training).

Why would you need to specify a number of epochs?

I don't know. I've read the documentation for tf.estimator.inputs.pandas_input_fn. It's clear that this is just a convenience function used to make a function to supply data in a pandas format to TensorFlow; this is a function that makes functions. On the other hand

  • if this function is used for obtaining predicted values, why does it have parameters for epochs and shuffling the data? Training for some number of epochs and shuffling the data for training makes sense (cf stochastic gradient descent), but when I'm obtaining predictions, I'd like to know that the order of the input matches the order of the output (i.e., don't shuffle it!)

  • if this function is used for training (which could be appropriate given its argument set), why do the authors of this code snippet use it for prediction?

  • if this function can be used for both training and prediction, how does TensorFlow distinguish between the two modes? I don't want parameters to update after obtaining predictions, nor do I want dropout to be applied when I am acquiring predictions. But when I'm training, I do want parameters to update, and I do want dropout to be applied (if I'm using dropout). It appears that supplying y is optional, so perhaps TensorFlow infers not to train if there is no y (since you need y to compute the loss and update parameters), but that's not at all clear from the documentation.

  • Could it be that this function only populates tf.Tensors in the model, and computation is deferred until a specific operation on the computational graph is called at some later stage? Absolutely. But if that's true, why do we specify a number of epochs? I would expect the number of epochs to be determined by whatever later operation I call...

TL;DR - TensorFlow is poorly documented.

$\endgroup$
  • $\begingroup$ that part of the Tensorflow docs is automatically generated, but anyway, no one uses this function anymore just for prediction. I'd write an answer, but I'm convinced this question should have remained closed (even though I didn't actually vote to close it, because it was already closed when I saw it). It's not a statistics question at all, it's just a consequence of a choice that Google software engineers made in version 1.3 $\endgroup$ – DeltaIV Jun 12 '18 at 19:36
  • $\begingroup$ @DeltaIV I don't how the documentation was generated; what I care about is if it conveys useful information about how the function works. In this case, the documentation is worthless and the function's usage remains opaque. If it's true that "no one uses this function anymore" then that should make it a target for deprecation (which would, happily, obviate any one of having to describe how it works in the docs). $\endgroup$ – Sycorax Jun 12 '18 at 19:56
  • $\begingroup$ I never said that it was good, I was just explaining why it is so bad. The function will never be deprecated, because it's used not only for prediction but also for a lot of other stuff: it's just that today Tensorflow offers more aptly named methods for prediction, with a simpler API. Also, Google has clearly chosen the way of having many (too many) ways to do the same thing in Tensorflow. $\endgroup$ – DeltaIV Jun 12 '18 at 22:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.