Confirmed here as well. I convert the distance to numpy's float32 datatype before rounding to 3 decimal places, and it works like a charm.
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Confirmed here as well. I convert the distance to numpy's float32 datatype before rounding to 3 decimal places, and it works like a charm.
Ah-ha! At least for python, just converting the final distance to a float32 isn't enough. You have to convert to float32 before taking the sqrt (or norm, for numpy arrays), so that it presumably uses the float32 version of sqrt.
e.g.
coord1 = numpy.array(1.125, 2.25, 3.3125)
coord2 = numpy.array(5.96875, 6.6875, 7.4375)
numpy.linalg.norm((coord2 - coord1).astype(float32))
Using this to calculate the distance, my measured coordinates for Sagittarus A* fit RedWizzard's distances perfectly.
That is the whole point. Divide and conquer. The data gathering so far have been sort of inefficient. It works for coords because it want lots of data, but once the playable universe increases or you want to get data updates, a more organized approach is needed.
wolverine2710
Tutorial & Guide Writer
I wonder if you can grasp any of it. I just added some comments so I can later, too
Will have a look at it tomorrow. I'm away today and arrive at night again ;-(
Yeah it's a little weird. For me trilateration gives (25.6875, -21.46875, 25899.96875) and a grid search near that points gives (25.4375, -20.46875, 25899.96875). Of the 34 distances I've got now 27 are spot on but the remaining 7 are out by 0.002. Your coordinates have 25 spot on and the other 9 out by 0.002. It's strange that they're all consistently out by 0.002. I'm wondering if I've made a mistake somewhere.
Aha, yes! If I round all my intermediate results to float32 precision then my brute force search gets the same coordinates as you measured and no error in any of the distances. Using that distance calculation I get:
Trilateration: (25.21875, -20.96875, 25899.96875)
Brute force: (25.21875, -20.9375, 25899.96875)
The brute force result gives me the same total error as your measured coordinates. I'd need some reference stars that are further apart in the y-axis to distinguish between them.
So I guess the conclusion is that your coordinates look good and I think we've got the ED distance calculation properly nailed down now.
Well, since my code works the other way around, i.e. it finds all integers that yield the correct distance, this will be a bit harder to implement.
When generating the integer coordinates, it does not use sqrt anymore. Perhaps I can grasp the concept and convert it to 32 bit floats today (unfortunately go has floor/ceil/sqrt only for float64, and even if I convert the values to float32 first, I believe it could give a different answer)
Ok, I will check my algorithm, preferably with 32 bit floats, too.
I did just that, but what should I check specifically? I am not saying your algorithm is incorrect. My idea was to present a completely new algorithm to calculate the distances, hopefully make it good enough to calculate results differently to verify them. While it could be used to generate distances (which it does to verify them) it is much more cpu/memory intensive than triangulation, so I made it as a verifier instead. So the algorithm is very different than others, therefore I see no way to use code/algorithms from others.
There is a lot of merit in having a completely different approach.
I'm not exactly sure what will help. Bulklocate should convince you that the calculated coordinates do in fact yield the distance numbers quoted (click on a system in the main table to get a list of reported and calculated distances). I guess then you'll need to try to track down which distances are causing your algorithm to fail to find a solution.
I have spent the better half of the day doing it. Now I switched to 32-bit floats using sqrtf, ceilf and floorf from C, but this seemed to result in one more error (or I haven't noticed this earlier, now the verifier lists warnings at the end). I added some unit tests to make sure the calculations are "correct", fixed some errors, but they are still there.
So in the end I tried a different approach: I decided to calculate what is the most likely location for the system in question for the input provided. Apparently the verifier thinks all positions are the most likely correct values, even for the systems yielding less than 100% certainty.
Code:
# warnings:
! LDS 1503 has 1 positions with 78.571% certainity, -51.78125,19.90625,-31.71875 included
! LP 229-17 has 1 positions with 75.000% certainity, -23.03125,9.03125,8.96875 included
! LHS 3297 has 1 positions with 88.889% certainity, -36.46875,22.68750,-16.53125 included
! WREDGUIA WH-Q B46-2 has 1 positions with 80.000% certainity, -132.68750,26.46875,-53.00000 includedWhat I have not realized so far was that it might not be enough to convert the input value for sqrtf to floating point; one must do that for the individual coordinates before squaring, to avoid 32-bit integer overflow. I just use 64-bit integers to avoid problems. (Perhaps someone pointed this out earlier, but I wasn't looking) Likely FD does just that, as it is the simplest thing to do, and it is ultimately incompatible with my solution (i.e. it will always report possibly incorrect coordinates).
Last edited:
My implementation in c# has none of these rounding errors. I delete the xyz coords and then use 10 nearby systems and 5 long range systems to calculate, and then verify the distance against in game. I'm using 1/32 and the rounding system used is bankers rounding. Could your errors be from the rounding algorithm?
Oh the irony. This is the exact method I used to try and get co-ordinates way back in Premium Beta 2 (NB: Not all of that data was gathered using the pixel method, some was purely by eye, some using a ruler on-screen). Of course at that time we didn't realise the float32-come[sic]-1/32ly thing so I didn't know to round them like that. I thought I was getting, at best, about 0.02ly accuracy.
It did occur to me that it would be possible to OCR this fairly easily, either from screenshots or something doing FRAPS-like frame grabbing. The star in question will always be centred (yes, this assumes you selected it as the current one), so you just need to find the lines either side, with the screen in the correct orientation, and then enter the closest co-ordinate intersection (as this will only get the fractional part).
Last edited:
Hey Generic EventHandler, nice handle!
Well, its not really rounding errors in my code that cause my algorithm to fail. It is really the other way around, some distances shown in-game are incorrect because of the single-precision floating point arithmetic used. My verifier thinks some distances for some stars must be incorrect, because there is no valid coordinate for them to exist, assuming all distances in the input is precise to 3 decimal digits. This last assumption is incorrect, however. My verifier uses "infinite" precision in this sense, assuming all input coordinates can be represented as 32-bit integers on a 1/32Ly grid.
With this kept in mind the output of my verifier can be still useful, because it shows that 99% of the systems are indeed correctly mapped, and the remaining 1% has coordinates that are the most likely valid.
Keep in mind that my verifier really calculates the coordinates with a method completely different than normal quadrilateration, this is its only purpose. It does not use the calculated coordinates from the systems.json file, only compares its result(s) to the one in the file.
I ran a super fast thrown together verifier thingy in JavaScript
Code:
//dist3 is the output from the distances api
function distcheck(){
var c1;
var c2;
var d1,dr1;
var d2,dr2;
var p = 1000;
$.each(dist3.distances, function (i1, v1) {
c1 = Vectorv.fromArray(v1.coord);
$.each(v1.refs, function (i2, v2) {
c2 = Vectorv.fromArray(v2.coord);
d1 = c1.subtract(c2).length();
d2 = Math.fround(d1);
dr1 = Math.round(d1 * p) / p;
dr2 = Math.round(d2 * p) / p;
if (dr1 != v2.dist) {
console.log(
v1.name + " [" + v1.coord + "]" +
"\n\t" + v2.name + " [" + v2.coord + "]" +
"\n\tFD dist: " + v2.dist.toFixed(3) +
"\n\tfloat64 d1: " + dr1.toFixed(3) + " <= Math.round(" + d1 + ")" + (dr1 == v2.dist ? " Correct" : " Wrong") +
"\n\tfloat32 d2: " + dr2.toFixed(3) + " <= Math.round(" + d2 + ")" + (dr2 == v2.dist ? " Correct" : " Wrong")
);
}
});
});
}Which gave me this
Code:
Alpha Cygni [-1405,46.09375,132.5]
Keries [-18.90625,27.21875,12.59375]
FD dist: 1391.399
float64 d1: 1391.398 <= Math.round(1391.3984541471666) Wrong
float32 d2: 1391.398 <= Math.round(1391.3984375) Wrong
Alpha Cygni [-1405,46.09375,132.5]
Tring [-125.375,9.5,-47.96875]
FD dist: 1292.807
float64 d1: 1292.806 <= Math.round(1292.8063323215217) Wrong
float32 d2: 1292.806 <= Math.round(1292.8062744140625) Wrong
Wredguia UR-Q b46-2 [-97.78125,56.875,-49.75]
HIP 91906 [-108.09375,57.1875,-33.59375]
FD dist: 19.170
float64 d1: 19.169 <= Math.round(19.169499903818565) Wrong
float32 d2: 19.170 <= Math.round(19.16950035095215) Correct
LFT 668 [-19.03125,25.65625,-24.21875]
Loga [-79.78125,36.53125,-42.0625]
FD dist: 64.243
float64 d1: 64.244 <= Math.round(64.24350192091416) Wrong
float32 d2: 64.243 <= Math.round(64.24349975585938) Correct
LHS 3297 [-36.46875,22.6875,-16.53125]
Haras [-118.75,14.40625,-21.40625]
FD dist: 82.840
float64 d1: 82.841 <= Math.round(82.8405023410952) Wrong
float32 d2: 82.840 <= Math.round(82.84049987792969) Correct
Wredguia WH-Q b46-2 [-132.6875,26.46875,-53]
Keries [-18.90625,27.21875,12.59375]
FD dist: 131.337
float64 d1: 131.336 <= Math.round(131.33649679592114) Wrong
float32 d2: 131.337 <= Math.round(131.3365020751953) CorrectThe last 4 "proves" that we can spot the rounding error - By adjusting to float32.
But what about the first 2 for Alpha Cygni?
I don't recall reading about anyone having issue with that one (which could just be bad memory on my part ofc)
Anyone know whats up with those two distances?
Ie. neither float32 or float64 reports the same as ingame.
Last edited:
Nope, I can't explain why the game is rounding those two up in the third decimal place. Changing powf() to direct multiplication doesn't make a difference in my code. To be sure we need someone to check it in Visual Studio though. I don't think I have it installed any more.
Btw, you're printing the first set of co-ords for the second star in each set as well, which was slightly confusing for a moment.
I suspect we don't have the correct coordinate for this star yet. It's one of the ones that is rather far out, and hard to pin down using only trilateration. For these ones that are far out, my script isn't able to map out the candidate region quickly, so it aborts before finding/verifying the coordinate. I haven't tried letting it run longer for this particular star.
I'll see If I can do the screenshot + measure pixels method for it this evening, unless someone else wants to give it a go.
Last edited by a moderator:
Does this code calculate the length with single-precision arithmetic? I mean after subtract() the three relative coordinates dx, dy, dz should be multiplied added together as 32-bit floats using dx*dx+dy*dy+dz*dz. This may yield some precision loss if one of the components very large compared to the others. I don't think this could explain the in-game value being rounded up, though.
After some fiddling, I think I have correct co-ordinates from pixel-measuring (hint: it's easier to always be measuring horizontally, so take a screen shot for each of the ED x and z co-ords, not just one and try to get both).
This gave me the following co-ords for Alpha Cygni: -1405, 46.125 , 132.5
Which then give me a distance from Sofagre (where I happened to be parked up) of 1360.541, which is what it says in-game. It also matches the 1391.399 for Keries<>Alpha Cygni that in-game shows (according to TornSoul).
So, the question now is ... what's the viable range for these trilateration and other methods? I'd guess it's likely moot in practice as we'll tend to push slowly out from known co-ordinates anyway, right ?