DSL course 2 week 2 exercise 7.1 - TypeError: model() got an unexpected keyword argument 'decay'

Hi,

I am getting the following error in Exercise 7 - update_lr, specifically in the following call:

parameters = model(train_X, train_Y, layers_dims, optimizer = "gd", learning_rate = 0.1, num_epochs=5000, decay=update_lr)

TypeError                                 Traceback (most recent call last)
<ipython-input-25-af87c2613be9> in <module>
      1 # train 3-layer model
      2 layers_dims = [train_X.shape[0], 5, 2, 1]
----> 3 parameters = model(train_X, train_Y, layers_dims, optimizer = "gd", learning_rate = 0.1, num_epochs=5000, decay=update_lr)
      4 
      5 # Predict

TypeError: model() got an unexpected keyword argument 'decay'

This seems weird, as the model function in section 7 has a keyword argument decay:

def model(X, Y, layers_dims, optimizer, learning_rate = 0.0007, mini_batch_size = 64, beta = 0.9,
          beta1 = 0.9, beta2 = 0.999,  epsilon = 1e-8, num_epochs = 5000, print_cost = True, decay=None, decay_rate=1):

Does anyone know what’s going on here? Does this seem like a potential problem with how the course has defined the notebook?

Thanks in advance!

After about the fifth time running the code, it started working… :person_shrugging:
So I guess this issue is resolved?

Hello @be8r5,

Section 6 defined a model function, and section 7 defined a model function. If we run those cells in order and successfully, the second definition should overwrite the first one.

One way to reproduce your error is to run the cell that contains the first definition, skip the cell for the second definition, and then run the cell that gave you that error. Besides literally skipping the second definition, unsuccessfully running it (due to a bug) has the same effect.

Of course we cannot guess in your case what had been done and in what order, but at least it is possible.

Raymond

Hi Raymond,

Thanks for the response. I’m still not sure why this happened, but I think we can assume it was my error.

Cheers,
Ben

Just to restate Raymond’s point in a more general way:

The notebooks are stateful. In order to get consistent results, you need to execute all the code cells in the notebook in the same order. If you’re in a situation like this in which the results seem impossible, you can always get things back in a consistent state by doing:

  1. Kernel → Restart and Clear Output
  2. Cell → Run All Above
  3. Run the cell that was throwing the error before

If that sequence cures the problem, it means you either executed the cells out of order, skipped some (probably what happened in your case) or perhaps modified a cell but didn’t click “Shift-Enter” on that actual cell to get the new code loaded. You can easily demonstrate to yourself that changing code in a function and then calling the function again without clicking “Shift-Enter” on the actual changed cell does nothing: it just reruns the previous version of the function code:

Take a function that already works and break it in an obvious way, e.g. multiply the output value by 2 before the return statement. Now run the test call that calls the function and it still works. Then click “Shift-Enter” on the now broken function and then run the test again and “Kaboom!”

So the moral of the story is that you always need to be careful about the state of the notebook. Also note that anytime you close and reopen a notebook, you need to run all the cells again in the proper order. Just because you see written output in the UI does not mean the code and variables actually are loaded in the runtime image. You can easily demonstrate this to yourself also.

Thanks, Paulin. That was helpful advice.