Where you and I disagree on this is around your requirement for all permutations of the references to generate the same coordinates. The effect of that is to require all 4 star subsets of the reference stars to be independently good sets of references. I don't think that's necessary; you only need one good set of reference stars to generate the correct coordinates, you just need to be able to tell if they are good or not.
(my emphasis)
Being able to tell is the crux of it all
As of yet I'm not convinced that the (reverse) distance test will never produce false positives.
I'm working on some tests to try and convince me (or not) otherwise - As I would in fact prefer this method (over mine) as it seems to discard fewer values.
But that is also why I'm a bit suspicious
Right, but remember we're dealing with a fixed volume of space: the Pill. It's entirely possible to find a fixed set of references for all stars in the Pill.
Absolutely - I do think I've made a couple of "good enough for beta" references here and there.
But in the (very) long wrong it won't work.
And I really prefer that people can simply look at the galaxy max and hover over the nearest systems, without having to enter a name in the search field to find a specific star etc.
That's really my main objection to that methodology - it's not user friendly enough
I wasn't meaning if p1-p3 lie in a plane (or course they do), I was meaning all four. If you're saying you've disproved that four points in a plane is a problem, I think you might have made a mistake somewhere as that arrangement definitely is a problem. Consider, you've used three points to generate two candidate coordinates. Those three points define a plane and the candidate coordinates are on either side of that plane (one above, one below). The fourth reference picks the correct candidate based on distance. But if the fourth reference point is also in the plane then the distance to both candidates will be equal and you cannot select between them. Obviously that situation will hold regardless of which point is selected as the fourth point. The same issue applies to larger sets of references if they all lie in a plane (regardless of permutation of the points).
I should have been MUCH more precise in my formulation there (especially as i was knit picking a bit at you
)
p1-p4 all *exactly* in the same plane = big trouble - agreed.
The critical line (and takeaway) is my last line
"Wether p1-p4 - or indeed p0-p4 all are very close to being in the same plane or not - has no impact on the final calculations."
(emphasis added)
That was the main thrust of my argument.
In all my 1M runs of finding "best fitting plane" it never happened that p1-p4 (or p0-p4) happened to be in the same plane - There was however *many* where it was a very close call (if i recall the distance to the best fitting plane could be out on the 2nd decimal).
I collected those - and investigated them closer.
To test for accuracy vs test cases of "normal" average distances to the plane.
Will in fact i never bothered comparing them, as there was no need - The accuracy for the "all p1-p4 very very close to best fitting plane) where all over the place. Some very good, some very bad, and everything in between.
As I've mentioned a few times - it was all a rather large waste of time (with regards to the objective)
But my reporting it hopefully can save someone else from wandering down that dead end
My approach goes further than just testing the p1-p3 distances. I test all the distances I have. Basically my approach works like this:
- I have input distances to N reference stars from Michael's list (i.e. that have confirmed coordinates). I don't trust the results unless N >= 5.
- I generate candidate coordinates using every 3 star combination from those N references. This results in at most C(N,3)*2 candidate coordinates.
- I then select the best candidate coordinate as measured by the total difference between the calculated distances and the input distances for all N stars (actually I used the total squared error).
- Any output that results in a visible error (i.e. err >= 0.001) between the calculated distance and the supplied distance is not good enough and requires more data.
On the first two point we do exactly the same.
It's on the last two where I get a bit more draconian in my "filter methodology"
Might be overkill on my part - time will tell (when I've done some more testing)
