In the unittest_test_logistic_regression I get this partial error:
Wrong output type.
Expected: <class ‘numpy.float64’>.
Got: <class ‘float’>.
Wrong output type.
Expected: <class ‘numpy.float64’>.
Got: <class ‘float’>.
2 Tests passed
2 Tests failed
Any hints where to look for errors?
Well, the message is telling you what to look at, right? It seems like you are returning python floats, but they should be numpy scalars instead.
It would help to see a more complete exception trace. We can’t tell which part of the assignment is the one where you are seeing this error. Also note that you filed this under NLP C1 W2, but Logistic Regression is Week 1, right?
This is part of the NLP C1 W1 as part of the assignment. The unit test function applies a sequence of inputs and compares to prerecorded outputs. What is puzzling me is that it complains about 2 inputs and is fine with 2 other ones. It’s the same code that processes all 4 of them but complains only about 2.
Have you actually looked at how the test cases work? You can open the file and examine the code by clicking “File → Open” and then opening the appropriate “dot py” file. You can deduce the name by examining the “import” cell at the beginning of the notebook.
But the error messages are giving you a clue. Now you have to understand how it applies to your code.
If you want more help here, then please show the complete output that you are getting.
So the unittest.py trys assert on np.float64 like so:
try:
assert isinstance(result, np.float64)*
and in my case there is a type mismatch but the type mismatch is only on 2 tests (I put the whole output in the very first post).
Maybe I am reading the output message wrong, I interpret it as there are 4 tests total and 2 are failing. In the unittest.py there seem to be only 2 tests defined
It looks as if in unittest.py
try:
assert isinstance(result, np.float64)
successful_cases += 1
except:
assert throws an exception but also executes the next line before going to except label
I think the code is more complicated than that. There are two separate test cases and for each one, it checks two things: the type of the output and the accuracy value that is returned. Notice that your failure is only on the type, so the actual value must be correct. You can see that there is a different message about accuracy that can also be printed.
I instrumented my test_logistic_regression function to print the type of the return value and here’s what I see when I run the tests for that section:
type(accuracy) <class 'numpy.float64'>
Logistic regression model's accuracy = 0.9950
type(accuracy) <class 'numpy.float64'>
type(accuracy) <class 'numpy.float64'>
All tests passed
What do you see if you add that print statement?
And if I add the logic to coerce my accuracy value to float:
accuracy = float(accuracy)
Then I see this:
type(accuracy) <class 'float'>
Logistic regression model's accuracy = 0.9950
type(accuracy) <class 'float'>
Wrong output type.
Expected: <class 'numpy.float64'>.
Got: <class 'float'>.
type(accuracy) <class 'float'>
Wrong output type.
Expected: <class 'numpy.float64'>.
Got: <class 'float'>.
2 Tests passed
2 Tests failed
Looks exactly like what you are seeing, right? So the question is why your value turned out to be the wrong type.
And if I add the logic to purposely break the return value:
accuracy = 42.
Then here’s what I get:
type(accuracy) <class 'float'>
Logistic regression model's accuracy = 42.0000
type(accuracy) <class 'float'>
Wrong output type.
Expected: <class 'numpy.float64'>.
Got: <class 'float'>.
Wrong accuracy value.
Expected: 1.0.
Got: 42.0.
type(accuracy) <class 'float'>
Wrong output type.
Expected: <class 'numpy.float64'>.
Got: <class 'float'>.
Wrong accuracy value.
Expected: 0.0.
Got: 42.0.
0 Tests passed
4 Tests failed
So you can see that there actually are a total of 4 distinct things it is checking and it is actually possible to fail all 4 checks.
So it’s two tests that test for two attributes: value and type … Sort of makes sense to report 4 tests.
This is the modified code that passes all tests, the difference with my original code is the cast to np.float64():
{moderator edit - solution code removed}
Why is this cast required? The result is used for percentage representation, 4 digits are sufficient …
The cast is required because of the way that the test is written. Note there are other ways to write the code than the way you did. You are creating a list of all correct cases and then taking the length of that list. That requires a lot more memory and complexity than just keeping a count of the number of correct answers.
But you’re right that at some level this shouldn’t matter that much. Your code computes the correct answer and even if you used the “increment a count” method there are ways to do that which will result in a python “float” instead of a numpy.float64. I’ll try to file a bug about this, but I doubt anything will be changed anytime soon.
In the meantime, we just have to comply with the test.
The method I used was going (by means of a for loop) over all predictions and corresponding labels, comparing them with an if statement, and incrementing (+= 1) the number of correct cases . Is this the standard way to do that? Or is there a more clever method?
You don’t need a loop to compute the number of cases in which the predictions are correct. You can do a direct Boolean comparison between two vectors in python and numpy with “==” as the operator. That gives you a vector with 0 (False) every place they don’t agree and 1 (True) in the positions that agree. Then you just need to take the sum of that vector to get the count, right?
That will give you a nice simple and clear line of code that computes the answer and also probably runs faster, because the operations are vectorized. So it’s a win both in terms of the code being easier to write and performing better as well.
Fantastic!
This also solves the same error my colleague idjordje got:
“Expected: <class ‘numpy.float64’>.
Got: <class ‘float’>.”
with no need to cast “numpy.float64” to satisfy the test.