I am having some problems with global variables in both implementations
The kind of error I got is:
Cost after iteration 1: 0.6926114346158594
Cost after first iteration: 0.693049735659989
Cost after iteration 1: 0.6915746967050506
Error: Datatype mismatch. in variable 0. Got type: <class ‘numpy.float64’> but expected type <class ‘numpy.ndarray’>
Cost after iteration 1: 0.6915746967050506
Cost after iteration 1: 0.6915746967050506
2 Tests passed
1 Tests failed
AssertionError: Not all tests were passed for two_layer_model. Check your equations and avoid using global variables inside the function.
I have checked all the function calls and I am not able to find the error
Hi @Mario_RSC, that error seems to indicate that the type of your outputs doesn’t match with the expected ones. I would check the types of what is being returned by your function, in particular the costs variable.
The point here is that if I ran the two_layer_model function outside the test function it gives correct results. How can I access to the test function in order to see what it is expected?
I have found the error. I wrote again in the cells, the functions made for the “Step by Step” assignment that conflict was causing the error as it seems to be.
Glad to hear that you found the issue. For future reference, you can view the tests by clicking “File → Open” and having a look around. You can deduce the file names to access by examining the “import” cell early in the notebook. This is all covered on the FAQ Thread FWIW …
The point here is that you don´t have to rewrite again in the two_layer_function the ones you wrote in the Exercise 1. You only have to call them simply like:
I’ve scoured the jupyter test files trying to debug this problem, but to no avail (and I don’t want to start infecting these test files with print statements or resort to using pdb).
I’ve followed the suggestions in the thread, but am simply not finding the source of the error.
Did you by any chance “hand copy” over your functions from the previous Step by Step exercise? If so, I think that can cause this error. That is a mistake: they provided their own versions as an “import” file and not all of them work exactly the same as what they had us build in the previous assignment. If that is what happened, please just delete all those hand copied cells and try again.
If you reread all the previous posts on this thread, you’ll see that’s what Mario found as the solution as well:
Yes, that was the problem. I’m still trying to get used to the notion that a numpy array can be broadcast into a column or row vector, while in MatLab, the case has to be made explicit. I can see how the “Pythonic” way allows for more flexibility by simply arranging the dimensions of the scalar to the orientation of the vector by doing a dot product of the scalar with a ones column or row vector as the case may be.
On your other points, I’m not sure I understand how they relate to the question of why it’s a mistake to “hand import” your previous functions, but here are some thoughts:
You don’t need a dot product to multiply a scalar times a matrix or vector in either numpy or MATLAB, right? Also note that broadcasting does not work with dot products, only with “elementwise” operations.
What happens with “broadcasting” is that you can expand a vector into a matrix to match the other operand of an “elementwise” operation, if the matrix has one dimension that matches the non-trivial dimension of the vector.
Also note that if you’re not familiar with that concept in MATLAB, you must be using a pretty old version. They finally gave up on their “ideological purity” on this and implemented “implicit expansion”. That’s a better name for exactly the same thing as “broadcasting” in numpy. This is pretty old news in MATLAB: it was in r2016b.
Thanks for the advice. I’ve been using Sage since 2011, but had used MatLab extensively before that. It seems to me that numpy uses the term dot product more generally to cover what I would see as a scalar-vector operation, where the vector is understood to be the ones column vector.
The only thing about the way numpy uses dot products that is slightly off kilter in terms of the normal mathematical terminology is that np.dot is really more than just a “vector dot product” (which is what mathematicians usually mean by dot product): it is full matrix multiplication using the standard “dot product” operation between each row of the first operand and each column of the second operand.
Note that there is another numpy function np.matmul which is equivalent to np.dot for our purposes here. Have a look at the documentation for each. Here’s google numpy dot. And here’s the same for numpy matmul.
Yes, I was not previously familiar with that term, but here’s the Wikipedia page. The Hadamard Product is exactly “elementwise” matrix multiplication. Of course that is not np.dot or np.matmul in numpy. The numpy function for that is np.multiply or you can use the overloaded operator “*”.
One important thing to note is the notational conventions that Prof Ng uses. He always and only uses “*” in a mathematical expression to indicate “elementwise” multiply. If he just writes the operands adjacent with no explicit operator, he means the normal matrix multiply (the dot product non-commutative style). Here’s a previous thread which discusses this in more detail.
I’ve been consulting NumPy for MATLAB Users, and noticed that ‘@’ can be used for standard matrix multiplication. I’ve yet to see it in any code I’ve looked at over the last couple of years, but maybe it’ll catch on. One nice thing about Python 3 is that alphabetic unicode characters such as Greek letters can be used as variables, but I haven’t tried defining a unicode operator such as ‘⸰’ that is typically used for the Hadamard product.
