Using your code I get an abs. error of 1.1921e-07, which is expected for float32 due to its limited floating point precision. These errors are caused by a different order of operation, which might be used depending on the input shape.
No, I don’t think there is an easy way to create the same errors unless you write an algorithm with a defined sequence of operations (for this slice). Also note that neither of them is “correct” and both show the expected error to the theoretically ground truth value. If you need more precision, you could use float64 instead.
Yes, I guess so, but it would also depend on the used libraries (in this case MKL might be used as the conv is performed on the CPU) as well as the selected algorithm.