C5 W1 A2 (Dinosaur Island) - Grader Error on 'optimize' function (exercise 3)?

I am getting the following error from the Grader for the third graded function of the second coding assignment of Course 5, Week 1:

Code Cell UNQ_C3: Unexpected error (KeyError(‘da_next’)) occurred during function check. We expected function optimize to return Test 3 failed. Please check that this function is defined properly.

My code passes the test cell in the assignment, so I’m pretty stumped. Any advice?

EDIT: This post addresses the same question, but the comments there are still completely unclear to me. The variable “da_next” is not used in my own code whatsoever; it only appears in the premade “rnn_backward” function. So I don’t understand how that could be causing a problem.

Hello Geoffrey,

Can you please share the screenshot of your output.


Sure. I’ll include both the grader output and the code output.

I don’t know if it’ll help at all, but here it is:

is this week 1 first assignment. there are 3 assignments in week 1, please mention assignment name

Your screenshot does help a lot in finding the error in finding solution, thank you

For the record, it is Course 5 – Week 1 – Assignment 2 – Exercise 3, but I have now explicitly added the name of the assignment (Dinosaur Island) to the title of the thread.

EDIT: To clear up what seems to be some confusion, here is the prompt immediately before the code cell:


Please refer this post

If you are still not able to get from this hint, you are basically not defining one of your code with the right function. Let me know if still running into trouble.

P.S. note you need to define the forward and backward propagation accordingly in the both code lines.


I don’t see any explanation of the problem in that thread. The poster replies immediately to his own question by saying he needs help with a different problem than the one he started asking about.

I am also confused by your statement. I am pretty sure that I am defining the function correctly since it passes the test cell in the assignment. Besides, it is pretty obvious which one goes where since the forward and backward passes return vastly different outputs.

The problem must be kind of subtle since it passes the test cell but not the grader. The post that I link in the main question suggests that there might be a misuse of da_next or some other global variable, but I don’t see how that’s possible.

Most of this problem is due to code in the notebook using a global variable that isn’t supported by the grader.

Did you address this issue?

I hope you have an understanding of global variables. Check the below comment to make you more understand about where you could have gone wrong. and if you still not able to get, share your this part of code via DM.


I actually did just figure it out. The problem is that the ‘rnn_backward’ function uses a ‘gradients’ dictionary that includes more variables than the one in the actual assignment. Specifically, it includes ‘da_next’. Crucially, this means that it is possible to check whether during the ‘optimize’ function a person implements the ‘clip’ function (written earlier in the assignment) or uses np.clip to clip the gradients “by hand.”

Because the new ‘clip’ function re-defines the ‘gradients’ dictionary to only include the 5 gradients used in the actual assignment, the grader will notice the presence of ‘da_next’ if you don’t use it and know that you didn’t call your ‘clip’ function.

In other words, it is not really a global variable problem. The grader simply checks the ‘gradients’ dictionary at some point by iterating over its keys. If you didn’t use ‘clip’ (or specifically work around this by removing the extra dictionary items), then there will be extra keys in your ‘gradients’ dictionary and the grader will throw this exception when it compares it to its answer.

I have tested several cases and am quite certain that this is the problem. I would strongly suggest that this error actually be checked during the assignment’s test cell to avoid this confusion (or, if not that, then it should be more clearly documented in the error message).

good you got it, it basically it is not an error but the grader requires us to the function code the way they want and when it is not implemented that way, the grader cell does not pass even if you have got the expected output.

I am curious what you needed to change in your notebook to resolve the issue.

Originally, I had just sort of forgotten that we had implemented ‘clip,’ so I had used a dictionary comprehension to implement the clipping on everything in the original version of ‘gradients.’ As I describe above, that left some extra keys in the dictionary that the grader doesn’t want.

Based on the error message, I eventually figured out that something like this had to be the problem, so I edited the dictionary comprehension to only run over the 5 explicit gradients mentioned in the assignment. That fixed the error.

Having identified the problem, I went back and read the instructions again and noticed that they mention ‘clip’ (which I had previously thought was referring to np.clip) and realized that it was referring to a previous user-defined function. So the last thing I did was replace the comprehension with ‘clip’ and verify that it works.

Honestly, this entire assignment was a mess. There were a couple of other times when I had correct code, but had to restart the kernel to get it to run properly. It was a real pain.

That is just the way the Jupyter notebooks work. Typing new code in a function cell and then calling it again does nothing: it just runs the old code. To get the new code added to the runtime image, you need to click “Shift-Enter” to “compile” (well “interpret” really) the new code. You can easily demonstrate this to yourself now that I’ve pointed it out. Take a working function and intentionally break it by multipying the return value by 2. Now run the test cell again. It still passes, right? Now click “Shift-Enter” on the newly broken function and run the test again. “Kaboom!”, right?

Of course “Kernel → Restart” and “Cell → Run All” is one way to get everything in sync again. The point is you need to be very careful to be conscious of the actual runtime state of your notebook. WYS is not necessarily WYG. It’s been that way since Week 2 of Course 1. Sure you can argue it’s a nuisance, but it’s not anything new and shouldn’t be surprising by Course 5.

Thanks for the additional details.

This is common to the notebooks that make use of global variables that are modified as the notebook runs. Usually all you have to do is re-run all of the cells, not necessarily restart the kernel.