@suki I keep getting attribution errors in propagate for dw and db

The first error I fixed:
AttributeError Traceback (most recent call last)
in
3 X =np.array([[1., 2., -1.], [3., 4., -3.2]])
4 Y = np.array([[1, 0, 1]])
----> 5 grads, cost = propagate(w, b, X, Y)
6
7 assert type(grads[“dw”]) == np.ndarray

Looks like I corrected dw error by statement:
dw=np.ndarray(shape=(2,1), dtype=float, order=‘F’)

Now db is the problem even after I added db=np.float64:
AssertionError Traceback (most recent call last)
in
7 assert type(grads[“dw”]) == np.ndarray
8 assert grads[“dw”].shape == (2, 1)
----> 9 assert type(grads[“db”]) == np.float64
10
11

You posted this against Course 2, but I’m guessing that you are actually talking about the Logistic Regression exercise in Course 1 Week 2. The first question is what the type of your db value actually is. Put the following print statement in your propagate routine right after you compute db:

print(f"type(db) = {type(db)}")

When I run the test cell for propagate with that print statement in place, here’s what I get:

type(db) = <class 'numpy.float64'>

If you get something different than that, then the question is why?

@paulinpaloalto Thank you Paul. I also get type(b) =float64 in a print statement.

I experimented declaring type both before and after assignment of variable. Which should I have done:
type(a) = float64
a =0

or reverse order?

I also have a print statement of type(b). So it is float64.

Since propogate ran before without the need to specify type, should I be looking for errors proceeding this line? Did this happen because I reran this for 4 hours last night?
The instructions say enter 2 lines of code. And an exercise on gitlab does not specify type.
Also since dw was declared in np.array, why the need to declare as np.ndarray?

When I start on this again today, I will reerun everything from the beginning.

You have to understand how assignment statements work in python. Every time you make an assignment, the variable name points to a new object in memory. Try this and watch what happens:

a = 1.
print(f"type(a) = {type(a)}")
a = 1
print(f"type(a) = {type(a)}")

Do you see the subtle difference between those two assignment statements? Do you understand why the types came out the way they did? The not so subtle point being that what the type of a was before the assignment statement is immaterial to what it is after the assignment statement. The point of an assignment statement is that it changes things, right?

I think you are making this way more complicated than it needs to be. Look at the exception trace in your original post on this thread. It is an assertion which fails because db is not of type np.float64, right? So what type is db in your code? How did it get that way? Just put this print statement in your code after you compute db:

The answer is easy: just remove the axis and keepdims arguments on the np.sum call that computes db. Since b is a scalar, you want db to be a scalar as well. That is the general rule: the gradient of an object must have the same type and “shape” as the base object. Of course “shape” only applies when the base object is an nd.array, not to scalars.

What do you mean 3 different ways? Did you actually read what I just said in my previous reply? Just remove the axis and keepdims arguments. That is what is causing you the problem.

One simple line. That looks equivalent to your “trial 3”. I think if your “trial 3” didn’t work, then it just means there is something flawed about your experimental methodology. You do realize that just typing in new code doesn’t actually do anything, right? You have to actually run that cell with “Shift-Enter”. Just calling the function again after typing does nothing: it just runs the old code. It’s very easy to construct an example and prove this to yourself.

ValueError: invalid array_struct
→ 55 A= sigmoid(np.dot(w.T, X) + b)

I redid without b in sigmoid function:
A= sigmoid(np.dot(w.T, X)
Wrong values for grads[‘dw’]. [[15049.85471226]
[30465.32023283]] != [[0.99845601]
[2.39507239]]

So how would one go about debugging that? It’s the same in python as it is in MATLAB, right? The type of one of the variables referenced in that statement is incorrect. There should be no array_structs anywhere to be seen here. I don’t even know what that is in python, so I’ll have to go look it up to get an idea of what you might have done wrong.

So either use a debugger and set a breakpoint on that line and examine the types or put in print statements right before the failing line:

print(f"type(w) = {type(w)}")

And so forth.

But based on your last statement, it sounds like b is the culprit. It should be a python scalar float value. So why is it an array_struct instead? Whatever that is …

@paulinpaloalto
No, there is no need to declare type in Matlab. And the specification of the arrary defines the ‘shape’ or dimensions

**So a function f(a,b) cannot be specified in Python as ** f(a+b)
So I tried: FROM PYTHON>ORG variable = int(var1)+int(var2) print("The sum of variables ", variable)

So I tried:
** z= float(np.dot(w.T, X))+float(b)**

TypeError: only size-1 arrays can be converted to Python scalars z= np.sum(np.dot(w.T, X),b) 57 A= sigmoid(z) So how to add b to np.dot(w.T, X) is the problem

Please refer me to where in any python manual or tutorial it tells you that saying:

b = np.float

is a useful thing to do? It sets b to be a variable of class “type”, which may be useful in some contexts, but not here. The way you set b to be a scalar float in python is to assign it a value which happens to be … wait for it … a scalar float. Like this:

b = 42.

Note that this statement has an entirely different effect:

b = 42

See the difference? This is actually one significant difference between MATLAB and python. In MATLAB, the two statements above would have the same effect. They don’t in python. Watch this:

b = np.float
print(f"type(b) = {type(b)}")
b = 42.
print(f"type(b) = {type(b)}")
b = 42
print(f"type(b) = {type(b)}")

The larger point being that we start out by initializing b like this:

b = 0.0

So it starts as a scalar float. And then we update it on each iteration by saying:

b = b - learning_rate * db

where db is also a scalar float. So the RHS of that assignment statement has type “scalar float”, so that means that the LHS will have that type after the assignment as well.

So this is how it’s all supposed to work. Why is it going off the rails in your implementation?

There is clearly something wrong with your sigmoid. The outputs of sigmoid are between 0 and 1 by definition, right? Are you sure your sigmoid code passes the tests in the notebook?