I’m currently working on Week 4’s Assignment #2. I am having an issue with exercise #6, the train_step function. I am receiving an error stating that the value of J is a really negative number. I suspect I may have an issue with another function, but I am too sure as all other functions were checked successfully. Here is the error I am receiving:

I got the same issue. It seems that it is, as you said, related to type conversions.
In my case it was in one of the previously implemented functions which is UNQ_C3 (compute_layer_style_cost function). There I used tf.square to square my numbers which produces a tensor variable and not a plain data type. This affects the result type of the equation that it is part of. I replaced the usage of tf.square with the plane x**2 operation and my error was fixed.

This is what I mean:

if n_C is 3 then

n_C ** 2 will be: 9

tf.square(n_C) will be: tf.Tensor(9, shape=(), dtype=int32)

Hi. so I have the same issue: I did what you suggested, I think, but still not fixed:
This is my UNQ_C1 and UNQ_C2. They both pass their own tests, but at UNQ_C5 I get the same error as OP mentioned.

Hi, I had this issue and the discussion here was very helpful for fixing it. Do any of you feel you understand what is happening here?

I’m thinking it’s behaving as if using tf.square(n_C) causes a trainable variable to be created, after which everything goes haywire. But that would be a weird thing for TF to do, and I’ve not been able to reproduce the problem in a simple standalone example.

I have the same issue and I still didn’t realize where is my error !!
I used all tensor flow functions for calculations ex. tf.square, …
any suggestions ?

I faced the same error. There were few different comments about type of values that should be there, I used them, but it didn’t help me. So, if someone will be struggling with this, I’d like to recommend do the same as me:

Use only suggested in exercise tf.functions, for the rest use python operators (+, -, *, etc.).

There are specified dtype for output values in UNQ_C5 - I think it could be treated as some advice, i.e. your graded functions that is used in UNQ_C5 should return tf.float32 dtype for output values

Taking into account these points helped me to pass tests, hope it will help someone else

What I noticed was that you have to re-run all cells from UNQ_C1 after each time you run UNQ-C5, then the error does not occur. And I’m using all tf functions including the function ‘tf.math.squared_difference’ which is handy but not one of the recommended functions. I passed all local tests and 100% on the submission.

I think this is the correct issue. The seed() command appears earlier and re-evaluating some cells makes the changes the internal state of the random number generator.

The real problem with getting negative cost values is that mixing integer and float types in TF/Keras has different type coercion rules than it does in python. Here’s a thread which gives details and examples.

I got the negative result from C4W4A2 exercise6. I take care of the type conversion and use the recommended function tf.substract, tf.square and tf_reduce_sum. I also reset the kernel before running EX6. but I am still getting the negative result. Here is the pointer to my area

I am stuck and appreciated if someone can help. I see these error.

I solved this problem by rewrite the following line
From J_style_layer = tf.reduce_sum(tf.square(tf.subtract(GG, GS))) * (1.0 / tf.cast((4 * tf.square(n_H*n_W*n_C)), dtype = 'float32'))

To J_style_layer = tf.cast((1.0/(4*(n_H*n_W*n_C)**2)), tf.float32) * tf.reduce_sum(tf.square(tf.subtract(GS,GG)))

I’m glad to hear that you found a solution. Not sure if you found this thread in your searches, but it’s my best attempt to document what works and what doesn’t.

Thank you for the reply. I read your document. In my case, I thought that tf.square should be used and it caused me problem. Once I replaced tf.square with **, it worked well.

Interesting. It’s good to hear that you got to a solution. My only concern is that I honestly don’t see how the change you show could account for a difference in behavior. Both the inputs are integers. Why does it matter whether you do the “cast” before or after the multiply? My theory is that something else changed at the same time that actually accounts for the difference.

Did you read my example thread (linked several times earlier on this thread) where I showed some of the possible ways to get errors here?