Ran into the same int is not a float issue here. This thread was helpful.
Perhaps the unit test for compute_layer_style_cost should be updated?
There are some tricky issues here. When you run train_step different rules are in effect: you’re doing back propagation, which in TF requires that all the functions in the compute graph that require gradients are TF functions. So code that worked in compute_layer_style_cost for the purposes of computing a correct output can then fail in train_step, because gradients can’t be computed if the compute graph includes numpy functions. You can use numpy functions for the parts of the computation that only involve the scalar constant values like n_H, but not for any functions that take the trainable parameters as inputs.
Maybe there’s a relatively easy way to construct a test for compute_layer_style_cost that would more directly reveal the issue, but it doesn’t sound simple to me.
I did not use any numpy functions.