LabVIEW
Find Nearest Point
So are all points unique and integers? What is the typical range of values?
Can you at least attach an otherwise empty VI, but containing a typical array of points?
I guess you want to ultimately visit each point, at each step picking the closest new point. This is a much simpler problem than the traveling salesman, which is not solvable with that many points.
Here's a simple solution (actually looks pretty similar to what you have) and it takes under 800ms for 15k points. I have not implemented the x-preference, so you could simply add your special scaling if needed. Should not change the timing much.
(LabVIEW 2014. There are probably bugs).
@GregFreeman wrote:
Thanks guys. We may also try "Binning" x and having some sort of buffer. At that point we can call X values that are sufficiently close on the same plane and sort, then go from there. Just a thought.
This will dramatically increase the speed because you would treat a small subset of points for each slice. Since the full algorithm looks like O(N²), just splitting it in 10 seperate slices will easily give you an order of magnitude. Just start at one end of a slice and patch the transitions to the next slice when you run out of points. Most of my code could be re-used.
You can add some x bias by simply adding the RE value to the distance (you can even balance the two by multiplying the RE value by a positive scaling factor. The higher the multiplier the more it does "lowest X first" at a cost of overall path lenght. Note that this does not improve performance, while breaking the problem up into slices would.
As a good control when comparing algorithms, you should calculate the final path lenght (e.g. relative to the original path lenght).
On my PC, replacing the Addition in the innermost loop with a shift register and a +1 primitive results in a minor minor improvement, takes a couple (literally only a couple) of ms off the total time. But the difference is so small, it might just be an artefact of benchmarking.
But as usual, Altenbach's solutions are pretty much spot on when it comes to performance. 
@Intaris wrote:
On my PC, replacing the Addition in the innermost loop with a shift register and a +1 primitive results in a minor minor improvement, takes a couple (literally only a couple) of ms off the total time. But the difference is so small, it might just be an artefact of benchmarking.
Yes, shift registers operate in place and one would think that unary operations (+1) should be faster than something with two inputs, such as the addition. However, it is very well possible that the compiler actually generates the same code for both version. 😄 I cannot see a difference in speed here.
@altenbach wrote:
@Intaris wrote:
On my PC, replacing the Addition in the innermost loop with a shift register and a +1 primitive results in a minor minor improvement, takes a couple (literally only a couple) of ms off the total time. But the difference is so small, it might just be an artefact of benchmarking.
Yes, shift registers operate in place and one would think that unary operations (+1) should be faster than something with two inputs, such as the addition. However, it is very well possible that the compiler actually generates the same code for both version. 😄 I cannot see a difference in speed here.
That doesnt surprise me. Is probably just my PC messing with my head..... crafty devils those PCs.... 
