Hi there.

Despite ‘all tests passed!’ for ‘sigmoid’ and ‘initialise with zeros’, I am getting ‘invalid character’ on the cost = line with the ^ arrowhead marker under the second ‘Y’. On the A = line I use ‘s’ as defined in the sigmoid section. I have tried ‘run all’ in the cell menu.

Do you have any advice, please?

1 Like

I’m not sure I understand what you mean, but I’m a bit worried about your statement involving s. That variable is not defined in the local scope of the *propagate* function at least in the way I implemented this. Note that you don’t have to write out *sigmoid* again: just call the function.

As to the “invalid character” error, are you sure you are using valid python syntax for the operators? I guess it’s also possible that you somehow accidentally inserted an unprintable character when you entered the line. It might be worth just deleting the line and retyping it from scratch, if you are confident about the operators that you used.

Even though we’re not supposed to publish source code for the solutions, it’s ok to “copy/paste” in the output you are seeing (the exception trace) even though that does reveal a bit of source code.

Thank you Paul.

I called the sigmoid function as you suggested, retyped the ‘cost =’ line and removed one bracket. That took care of the ‘invalid character’ alert, however I still have a syntax error, which now points to the p in the 3rd np term.

If I comment out the whole line the error alert goes away, so I am pretty sure the problem is in this line.

I suspect the solution is embarrassingly straightforward.

…I of course meant the 4th np term.

The details matter in programming. Compare what is inside the parens of the first call to *np.dot* with what is in the parens for the second call to *np.dot*. Do you see the difference? Hint: there’s a single crucial character that is present in the first case and missing in the second case.

Hi again Paul.

I have now run the propagate function and got the right values (they correspond to the ones shown in the notebook) but with assertion errors for each value. Does this mean I also need to get a new clean copy of the notebook, or should I just ignore the assertion errors

?

I only started the course about 10 days ago, it looks as though the numerous cases in Discourse are considerably older that that.

Please advise

… I also notice that there is, in fact, a small difference between the expected result for cost. Do I need to go back?

Yes, a difference in the third decimal place is *not* a rounding error. It means that there is a real error in your algorithm at least for the cost.

I don’t think there have been any recent updates to this particular assignment. If you want to check, you can use the instructions linked from the FAQ Thread to get fresh copies of the test files.

Hi Paul.

I fixed it and passed, but I’m not sure why this worked.

After checking everything thoroughly I just changed my (-1/m) * expression at the start of the cost calculation, to -1* and put the rest of the expression /m.

Are these not equivalent?

Yes, they should be, but my guess is that perhaps you also changed the parenthesization at the same time. Meaning that the problem was really an “order of operations” issue, e.g. before your -1/m was multiplying only the first term. Just a theory of course. It is true that the rounding behavior or -`1/m * (big expression) is`

different than `-1 * (big expression)/m`

, but as I mentioned before rounding errors show up in the 15th or 16th decimal place, not the third, if we are doing 64 bit floating point.

It is true that I took out the brackets that were there for (-1/m) and the next bracket ran for the length of the remaining expression, so I just put ‘/m’ at the end. I have been wondering if it was the brackets all day.

Thank you for your guidance.

Please note that the editor in the notebook is “syntax aware”: you can use it to check your matching parens and brackets. Just click on one and it will highlight the one that matches it in green. Or if there is no match, it highlights it in red.