Timeline for efficient way to give nearest neighbour and next nearest neighbour of every point in a point set
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 19, 2016 at 14:00 | comment | added | matheorem | Hi, @mrz, I don't get it. Could you explain what your comment mean a little further? | |
| Oct 18, 2016 at 21:13 | comment | added | mrz | Imagine you would have many of such lists. In the real world each list could represent the coordinates of objects at a certain time. How could I trace the objects in time? To do so I would need to trace a single coordinate "from list to list" by finding the nearest coordinate. That should be done for all coordinates in the first data set. | |
| Dec 10, 2013 at 14:26 | comment | added | matheorem |
Sorry, I found bugs. See this ps list here pastebin.com/GXtnVxYi This ps list contains Sqrt, and if you try ps=N@ps and add small offset to d respectively, you will find their result is different. And I can confirm, add offset gives right result, because the right result will compatible with my other code. But merely add small offset without ps=N@ps will effect the performance much. So I conclude that ps=N@ps and a small offset, None is dispensable for correct and efficient code. I hope you could check this to see if my statement is right. Thank you
|
|
| Dec 10, 2013 at 12:49 | vote | accept | matheorem | ||
| Dec 10, 2013 at 14:04 | |||||
| Dec 10, 2013 at 11:20 | comment | added | matheorem |
I mean if the coordinates of points contain Sqrt, then to make the code most general and correct, either to add ps=N@ps, or add a little offset to d in your code. And in terms of the identity of your code and mine, I'm not claim any precedence here, because anyway you enlightened me to use NearestFunction first. But I read through your code and test it, so I am sure we had the same idea. And finally, if I had know that you would post an answer, I wouldn't spend a whole afternoon to design a code myself :). especially when yours is more general and efficient than mine. Thank you so much!
|
|
| Dec 10, 2013 at 11:08 | comment | added | user484 |
I'm sorry, I don't understand what you mean by "improve your answer with N". I'm not planning to change anything in my answer at this point. Also, I don't quite understand your answer either as it does not have an explanation, but I'll take your word for it that yours and mine are identical. You could wait a while before accepting though; who knows, someone may come up with an even better solution.
|
|
| Dec 10, 2013 at 11:04 | comment | added | matheorem |
Ok, are you considering to improve your answer with N? Though my method is identical to yours, but I make the label a little complex, so I'll accept yours, if there is no better method
|
|
| Dec 10, 2013 at 10:45 | history | edited | user484 | CC BY-SA 3.0 |
added 29 characters in body
|
| Dec 10, 2013 at 10:45 | comment | added | user484 |
Ah... Well, another workaround is that if you set ps = N@{{0, 0}, ...} instead then it works.
|
|
| Dec 10, 2013 at 9:49 | comment | added | matheorem |
Well, you can try this ps={{0, 0}, {Sqrt[2], 0}, {0, Sqrt[2]}, {Sqrt[2], Sqrt[2]}}. Very odd,.but it's true, offset is necessary.
|
|
| Dec 10, 2013 at 9:03 | comment | added | user484 | I see your answer but it doesn't tell me why the offset is necessary. | |
| Dec 10, 2013 at 9:02 | history | edited | user484 | CC BY-SA 3.0 |
added 343 characters in body
|
| Dec 10, 2013 at 8:57 | comment | added | matheorem |
Thank you for your answer! I am testing now, and I also found the EuclideanDistance problem, so I use N and add small offset 0.0000001 to it, I found this small offset is necessary, see my answer.
|
|
| Dec 10, 2013 at 8:52 | history | edited | user484 | CC BY-SA 3.0 |
added 507 characters in body
|
| Dec 10, 2013 at 8:43 | history | answered | user484 | CC BY-SA 3.0 |