Hello, I am trying to implement the equalize function:

It is optional so I hope it is okay to post my code here (as it does not affect grader): [Deleted by Mentor]
This is the output from my code, the cosine_similarity after equalizing is different from that of the expected output:

based on your error log, you need to look into your codes for correction/adjustment in corrected_e_w1B and corrected_e_w2B, e1 and e2.

The most important thing, kindly remove codes from your post, it is against community guidelines to share codes on public posts. Share only your error log or the output with expected output log.

Notice that your answers are actually pretty close to the expected values: the differences are out in the 15th decimal place of the mantissa values. We are operating in 64 bit floating point and you can get different rounding behavior with different ways to express a given computation that are equivalent mathematically.

I compared your code to mine and the only differences I see are where you compute the square of the norm of a vector. That happens in 5 places in the code. You implement those by taking np.linalg.norm and then squaring it. I did it by squaring the vectors and then summing the elements. Thatâ€™s both mathematically equivalent and a lot more efficient because it omits the computation of the square root, which is expensive and just wasted anyway. Try it my way:

||v||^2 = \displaystyle \sum_{i = 1}^n v_i^2

I got the exact answers out to the full resolution of the print statements. If we were operating in \mathbb{R} both implementations would give exactly the same result, but not in the pathetic limited world of floating point. There are literally only 2^{64} distinct numbers we can represent between -\infty and +\infty. Thatâ€™s pretty sad compared to pure math and it has some real world side effects. But we can still land a spacecraft on Mars with 64 bit floating point, so itâ€™s â€śclose enough for jazzâ€ť.

Thank you for your replies the problem I have is the last 3 numbers are not what shows in the expected result, so I thought there was some miscalculation

Hello, I have tried to implement the function using np.sum(np.square())the result is close but not exactly, could you please message the code so I can compare and correct mine? Thanks in advance.

Weâ€™re into â€śangels dancing on the head of a pinâ€ť territory here for sure. Before your answers differed in the 15th decimal place and now they differ in the 17th decimal place. Thatâ€™s 10^{-17}, which is literally smaller the resolution of IEEE 754binary float64. The spec shows that as 15.95 decimal digits. You can get bigger differences than that just from things like the difference between:

1/m * expression

and

expression / m

But if you really want to get this exactly, you can DM me your notebook. Or DM me the â€ścopy/pasteâ€ť of your current code and Iâ€™ll have a look.

Just to close the loop here, we had a private conversation to compare the source code and there were a couple of lines where the operations were:

(a * b) / c

And you get a very slightly different answer if you write that as

(a / c) * b

Of course they are equivalent from a mathematical point of view, but the rounding errors are slightly different when you run the computations in 64 bit floating point.