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:
Could somebody have a look at my code and tell me where the problems are and how to fix, thanks in advance.
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.
Also did you try to submit this assignment??
Hey @Namhoang, I have deleted the picture that containing your code. As @Deepti_Prasad said it’s against our guidelines but we are here to help you.
I see your output same as your expected output so where are the problems or the error 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”. 
There aren’t any problems. Your results are close enough.
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 754 binary 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.
