It was a genuine question. I was wondering why it appeared that some weren't using the analytic approach, at least to calculate the likely start point for a search.
The majority of us do use the analytic solution as the starting point for the search. Although I think there were 1 or 2 that were using alternate approaches.
Someone above mentioned "from all "near" 1/32ly grid points near the calculated point", and doing an exhaustive search like that struck me as inefficient (though it will give the right answer).
The "from all near 1/32ly grid points" comment was me (
link for reference). As I described in that post, what you actually end up with is the intersection of multiple thin spherical shells, which give you a small 3d volume. When you perform trilateration, it will give you a point within that small intersection volume. But the real coordinate could be anywhere in that volume. So you end up needing to look around the area near the point you calculate with trilateration - or get more distances, which will (usually) decrease the size of the intersection volume.
What I do, instead of using a sphere/cube around the calculated point is to use a fairly sophisticated heuristic that tries to follow the contour of the error function around the candidate region. Where the error function is the sum of squares of distance errors to a given point, where the error is 0 if the calculated rounded distance exactly matches the rounded distance that the user input from the game. And the candidate region is the intersection volume, i.e. the region where the error function is 0.
And then I evaluate every grid point within that contour, to ensure that I've evaluated every grid point that might be in the candidate region. If I've only found 1 point that actually has an error of 0, then I know I've found the right coordinate, assuming no typos. Or if I've found multiple points with an error of 0, then it's impossible to determine which is the real coordinate, without more data.
You've got errors from rounding, errors from movement of stars over time, and errors from mis-typed distances. But if you've got several entries for the same distance by different people, at around the same time period, the star movement isn't likely to be a big factor, and the typos are unlikely to be all the same typo - the correctly typed distance is likely to outnumber them.
To the best of my knowledge, the system coordinates do not change over time. The coordinates of a star within the system can and will change, but the coordinates of the system within the galaxy won't change.
As for typos, In the majority of cases, you will only 1 user that has input the distances for a given star pair. Especially for people (like me) who don't use a standard set of reference stars. So we can't rely on multiple entries of the same distance. Instead, we ensure that there are enough distances to guarantee that there is enough redundancy to detect at least, e.g. 2 typos distances.
So mainly what you're facing is the rounding error, plus dealing with a minority of inconsistent data. And in that situation, there's a more efficient way to search the 3D grid to find the 'sweet' spot, than searching all the intersections on the grid. Because if you know the same rounding algorithm as is being used by Elite, then it isn't a case that either the distance from a 'known' star to a candidate position either matches or it doesn't - you can check how closely it matches, and see which of the 26 surrounding points makes the highest number of distances improve their match, then move your search centre over in that direction, and repeat.
That doesn't always work though. The problem is that you're sampling the error function in 1/32 LY increments, but the function can have much smaller features. The clearest example of this is when you're dealing with a star far away, using references that are bunched together in relation to that star, due to the long distance. In that case, you can end up with a a candidate region that is a very long, thin and narrow "needle" shape, which can be many 1/32LY units in length, but is narrow enough that it passes between almost all grid points except possibly 1 or 2 somewhere along it's length. In that case, trilateration will produce a point within the needle, but almost certainly not one that is grid-aligned. Searching the 27 nearby grid points won't give you any indication which direction you should look, because the error function in that case is related to how close the needle is to a given grid point, which is mostly unrelated to where the needle will actually encompass one of the grid points. And just because you find 1 grid point within the needle, you still have to search along the rest of the length of the needle, because it's possible it encompasses multiple grid points - in which case you need more data. i.e. the distance to another system which will let you discriminate between the 2 or more candidate points i.i.e. another thin spherical shell which only encompasses one of the candidate points.
Mathematically, that "needle" could be described as a system of inequalities, and then you could add an additional constraint to the system to enforce the 1/32LY grid thing. And then you could theoretically try to solve that system of inequalities, which would give you 0 or more points that satisfy the equations. However, that would be a very complex system of equations.. and my math skills aren't up to be able to solve an arbitrary system of inequalities of that form algorithmically. Although I'm a bit curious if something like mathematica or matlab could.
