You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was reported to me at jlmelville/rnndescent#8 but would also affect pynndescent, which is unsurprising as I directly converted the equation from here into C++.
Equation 7 of the TS-SS equation in the original paper (PDF), written in terms of degrees, has a denominator of 720, which would convert to 4pi in radians (the pi would cancel). As can be seen at:
there's only a division of 2 that shows up in the calculation of the return value.
I would volunteer to write a PR and update any affected test, but I would like to to use that paper as a means of confirming my understanding of the equations, as there are some partial numerical results in it. Unfortunately, I quickly got fed up trying to back-convert the vectors in the figures to plausible 2D descriptors (e.g. how can A and B in figure 1a be vectors of length 6, with an angle of 30 degrees between them, but a Euclidean distance of 2). Obviously this doesn't affect the returned neighbors but it could have a (small) effect for anything that used the distances downstream, like UMAP.
The text was updated successfully, but these errors were encountered:
This was reported to me at jlmelville/rnndescent#8 but would also affect pynndescent, which is unsurprising as I directly converted the equation from here into C++.
Equation 7 of the TS-SS equation in the original paper (PDF), written in terms of degrees, has a denominator of 720, which would convert to 4pi in radians (the pi would cancel). As can be seen at:
pynndescent/pynndescent/distances.py
Lines 518 to 520 in d99a821
there's only a division of 2 that shows up in the calculation of the return value.
I would volunteer to write a PR and update any affected test, but I would like to to use that paper as a means of confirming my understanding of the equations, as there are some partial numerical results in it. Unfortunately, I quickly got fed up trying to back-convert the vectors in the figures to plausible 2D descriptors (e.g. how can A and B in figure 1a be vectors of length 6, with an angle of 30 degrees between them, but a Euclidean distance of 2). Obviously this doesn't affect the returned neighbors but it could have a (small) effect for anything that used the distances downstream, like UMAP.
The text was updated successfully, but these errors were encountered: