I am having an issue with the first graded programming assignment. I have implemented the propagate() and tests are passing.

However, after implementing the optimize() I get the following failure in optimize_test() AssertionError: Wrong values for costs. [array(5.80154532), array(0.58923175)] != [5.80154532, 0.31057104]

I’m not sure where my problem could be. I feel like my updates to w and b are correct.

Hello @maoritz. Note that your computed cost is 2-dimensional. The actual cost is real-valued, i.e. a scalar. There is but one cost. You say that your propagate() function passed with cost equal to a scalar. Have you implemented that function in your optimize() function?

@kenb There is only one implementation of the propogate() which is reused by the optimize()

The propagate_test() passes with the following output:

dw = [[0.99845601]
[2.39507239]]
db = 0.001455578136784208
cost = 5.801545319394553
All tests passed!

I implemented a second way of calculating the cost using np.sum() which does result in a scalar output but the result from the optimize_test() is the same

5.801545319394553
w = [[0.17998823]
[0.07550727]]
b = 0.8098329520228539
dw = [[0.61299061]
[1.31774648]]
db = 0.0633680265420237
Costs = [array(5.80154532)]
5.801545319394553
0.5892317480074818

~/work/release/W2A2/public_tests.py in optimize_test(target)
61 assert type(costs) == list, “Wrong type for costs. It must be a list”
62 assert len(costs) == 2, f"Wrong length for costs. {len(costs)} != 2"
—> 63 assert np.allclose(costs, expected_cost), f"Wrong values for costs. {costs} != {expected_cost}"
64
65 assert type(grads[‘dw’]) == np.ndarray, f"Wrong type for grads[‘dw’]. {type(grads[‘dw’])} != np.ndarray"

AssertionError: Wrong values for costs. [array(5.80154532), array(0.58923175)] != [5.80154532, 0.31057104]

Thee short answer to the question that I think that you are asking: Yes, the associative property holds everywhere and always! That is

a + b + c + d = (a + b) + (c +d)

As you are aware a dot product on two vectors is multiplies element-by-element and sums the result. In other words, the cost functionJ = ... in the third bullet in the intro to Exercise 5 can be written as the sum of two sums. To me, whichever way the code turns out to be more readable is preferred. In this case, I prefer using two np.dot() functions, i.e. the cost is the sum of two sums.

Also, when using the function np.sum(...) instead of np.dot remember to sum across the proper axis. Suppose that A is an n x m matrix. To sum across columns you will use np.sum(A, axis=1, keepdims=True). If you wanted instead to sum across rows, you would use the axis=0 option. The keepdims=True setting makes sure that the dimensions of your result are of the same “rank” (1, not 0) as thaose of the more “native” np.dot formulation. If your are unsure of this last point, hit the NumPy documentation for the np.sum function and use your Google-Fu more generally.

Sorry to ask something so trivial but I am really at a loss for what could be wrong in this case. It still isn’t passing.

So, focusing on the dot product version.
The shape of each of the two dot products turns out to be (1,1) and the type is a numpy.ndarray.

You mentioned previously that it should be a scalar which I agree with and the docs seem to say that the output should be a scalar in this case given the shapes of the inputs. Would there be something that needs to be done to fix the output shape from the np.dot() call?

Short answer: No. The cost function J is single-valued. Now when you report that the shape of the two dot products are (1, 1), then good! They are scalars. Summing will be likewise.

I am guessing that you are using a format like

cost = (1/m) * (-np.dot( ., .) - np.dot( ., . ))

That would be my route too! When an expression is failing you, check the validity of it’s arguments–A and Y in this case–making sure that they are properly dimensioned, and of course, the expression itself. There are no other alternatives. That’s the good news.

It is hard for me to guess at what can be going wrong. Just keep at it! These are the necessary struggles that one must endure. It’s OK; it’s a big club!

The cost value from each iteration is a scalar, although they have written the code here in propagate to format it as a 1 x 1 ndarray. But the point is that optimize returns an array of costs, right? The logic in optimize saves the current cost value every 100 iterations into the costs array, which is what is returned. If you check the test case in public_test.py, you’ll see that they specifically use 101 iterations, so that they get two cost values returned. So what the failing test shows is that while your cost value is correct at 0 iterations, it is wrong at 100 iterations. In fact it has actually increased! Eeeek! So what could cause that? We can conclude that your basic cost logic in propagate is correct, since a) you passed the test case there and b) the cost at iteration 0 is correct. So there must be a bug (or bugs) in your optimize logic. E.g. maybe your “update” logic is wrong. Perhaps you used the wrong learning rate? Or added instead of subtracting?

I was so focused on the harder equation that I didn’t realize the easiest ones were where the problem was even though the tests were screaming at me to do so!

I was updating the bias with the bias itself instead of the derivative!

Cool! Glad to hear that you found the solution. It’s nice when the answer turns out to be pretty easy, but the hard part is always knowing where to look.

Hello, I was reviewing this post carefully since i’m having the same issue (or at least something similar). I’m getting this values + this error:
w = [[0.9910139 ]
[1.97844435]]
b = 1.999986899796769
dw = [[0.99845601]
[2.39507239]]
db = 0.001455578136784208
Costs = [array(5.80154532)]

---------------------------------------------------------------------------
AssertionError Traceback (most recent call last)
<ipython-input-138-3483159b4470> in <module>
7 print("Costs = " + str(costs))
8
----> 9 optimize_test(optimize)
~/work/release/W2A2/public_tests.py in optimize_test(target)
60
61 assert type(costs) == list, "Wrong type for costs. It must be a list"
---> 62 assert len(costs) == 2, f"Wrong length for costs. {len(costs)} != 2"
63 assert np.allclose(costs, expected_cost), f"Wrong values for costs. {costs} != {expected_cost}"
64
AssertionError: Wrong length for costs. 1 != 2

I have checked both propagate and optimize functions and i can’t seem to find the problem.
My cost code is the following: cost = (- 1 / m) * np.sum(Y * np.log(A) + (1 - Y) * (np.log(1 - A)))

and the update as follows: w = w - learning_rate * dw b = b - learning_rate * db

I’m suspicious about this line you wrote previously:
“If you check the test case in public_test.py , you’ll see that they specifically use 101 iterations, so that they get two cost values returned.”

Careful, I don’t think you are supposed to copy your code into the posts.

In my case, I had implemented the

b = …
incorrectly in such a way that the first cost in the list would be correct but all subsequent costs would be incorrect. It was a very subtle error to the eye.

Your case is a bit different in that you are having an incorrect length to the “costs” list. Which, as @paulinpaloalto mentioned, and you can see in the test output should have a length of exactly two when the test is complete.

If your compute_cost implementation is passing its test, which it appears that it may be, then, I would next make sure that you only added code in the “your code here” blocks and also scrutinize the variable names that you used in implementation.

I’m worried the test is done with 100 iterations rather than 101 since the test block is written like this (i don’t know how to access the public_test.py to check)

adding a print(num_iterations) inside the optimize function prints 100 iterations while testing.

EDIT: I found out the return had an extra TAB, returning a result after only 1 iteration inside the FOR LOOP. I’m not sure if i added the TAB by mistake or it was by default on the exercise.

@lucassg You must have added the Tab accidentally. I didn’t have that problem when I did this exercise. In python the indentation is part of the syntax, so we have to take care on that front. It’s not just a matter of aesthetics .

Also note that the public test case does use 101 iterations. If you want to examine that code, just click “File → Open” from the notebook and then open the file public_tests.py. This is one of the topics discussed on the FAQ Thread, which is worth a look just on general principles.

~/work/release/W2A2/public_tests.py in optimize_test(target)
60
61 assert type(costs) == list, “Wrong type for costs. It must be a list”
—> 62 assert len(costs) == 2, f"Wrong length for costs. {len(costs)} != 2"
63 assert np.allclose(costs, expected_cost), f"Wrong values for costs. {costs} != {expected_cost}"
64

I have checked the codes I enter for the optimize function and tried different recommendation mentioned in the previous posts. I notice the line code “costs.append(cost)” that may cause the problem. But did not find anything in optimize_test that will reformat to the length of 2 for costs print. Please help. Thanks,