Discussion What is the most efficient way to crowdsource the 3D system coordinates

[TornSoul]

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.

the length() function is a simple wrapper doing exactly what you describe.

To with

  length: function () {
    return Math.sqrt(this.dot(this));
  },
  dot: function (v) {
    return this.x * v.x + this.y * v.y + this.z * v.z;
  },

 

[TornSoul]

This gave me the following co-ords for Alpha Cygni: -1405, 46.125 , 132.5

Confirmed.
With those coords, the known recorded distances checks out.

Kinda ironic how the good old eyeball beats computing the value

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 ?

I think distances above 500 or there abouts starts to get risky (not that all are wrong - just that not all are necessarily correct)

Trilateration is very sensitive to the error on distances - and that sensitivity rises as the numbers get larger.

The problem with having a p0 being VERY far away, is that the intersection of the shells "spread out" - Ie, the intersecting area gets very wide (orthogonal to the vector between p0 and p1-p3).
Thus giving rise to more potential coordinate points that will fit the distance check.

 

[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 ?

Hell if someone really want's to go nuts and test with somethings as far away as possible:

Try with YOOXIAE RI-Z D1-0
65759.172 LY (from where ever I were when I found it)

If someone (Athan?) feels up to eyeballing some coordinates (for comparison) that would be cool.

 

[RedWizzard]

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.

Alpha Cygni had a bad location. The correct coordinates are (-1405, 46.125, 132.5). It's almost in line with the long axis of the Pill so it needed a few more distances to get the location right - I went out and got them yesterday so if you grab the latest systems.json these errors will be gone. It got imported despite the bad location because at that time I was using the root mean square error across all the distances to decide if the coordinates were good, and the errors for Alpha Cygni were low enough to produce an RMS error of 0.000.

 

[RedWizzard]

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 ?

I really should have posted something about this when I fixed it yesterday

Those coordinates match my trilateration output. The range for my algorithm depends on getting good references - it can do Alpha Cygni but it needs the right set of references. It can't do Sagittarius A* yet though it wasn't far off. I expect it'll get Sag A* right when we have access to stars that are more spread in the direction of the the y-axis.

 

[RedWizzard]

the length() function is a simple wrapper doing exactly what you describe.

To with

  length: function () {
    return Math.sqrt(this.dot(this));
  },
  dot: function (v) {
    return this.x * v.x + this.y * v.y + this.z * v.z;
  },

To be absolutely identical to ED you need to fround all the intermediate values:

  length: function () {
    return Math.fround(Math.sqrt(this.dot(this)));
  },
  dot: function (v) {
    return Math.fround(Math.fround(this.x * v.x) + Math.fround(this.y * v.y) + Math.fround(this.z * v.z));
  },

This makes a difference for distances to Sag A*. You'd only want to do this when checking distances though, you'd want a float64 implementation for trilateration.

 

[TornSoul]

To be absolutely identical to ED you need to fround all the intermediate values:

  length: function () {
    return Math.fround(Math.sqrt(this.dot(this)));
  },
  dot: function (v) {
    return Math.fround(Math.fround(this.x * v.x) + Math.fround(this.y * v.y) + Math.fround(this.z * v.z));
  },

This makes a difference for distances to Sag A*. You'd only want to do this when checking distances though, you'd want a float64 implementation for trilateration.

I see your point.
But in practice it makes no difference.
Which I'm not entirely sure I understand why (ie. I would indeed expect a difference at the last digit(s)) - But I don't see it.

Results

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
	float3232 d22: 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
	float3232 d22: 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
	float3232 d22: 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) Correct
	float3232 d22: 131.337 <= Math.round(131.3365020751953) Correct

Code

Spoiler

function distcheck(){
  var c1;
  var c2;
  var c3;
  var d1,dr1;
  var d2, dr2;
  var p = 3;

  $.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);

      c3 = c1.subtract(c2);
      d22 = 
        Math.fround(Math.sqrt(
          Math.fround(
            Math.fround(c3.x * c3.x) +
            Math.fround(c3.y * c3.y) +
            Math.fround(c3.z * c3.z)
         )
       ));

      dr1 = +(Math.round(d1 + 'e' + p) + ('e-' + p));
      dr2 = +(Math.round(d2 + 'e' + p) + ('e-' + p));
      dr22 = +(Math.round(d22 + 'e' + p) + ('e-' + 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") +
          "\n\tfloat3232 d22: " + dr22.toFixed(3) + " <= Math.round(" + d22 + ")" + (dr22 == v2.dist ? " Correct" : " Wrong")
        );
      }
    });
  });
}

 

[RedWizzard]

I see your point.
But in practice it makes no difference.
Which I'm not entirely sure I understand why (ie. I would indeed expect a difference at the last digit(s)) - But I don't see it.

It doesn't make any difference if the x, y, and z components are all quite small, but if any of the components are large enough then you can lose precision when you square them (with float32s). This happens with Sag A*. E.g. LHS 140 - Sag A*:
Sag A* = (25.21875, -20.90625, 25899.96875)
LHS 140 = (-34.53125, 16.1875, -23.0625)
Distance with fround only on the sum of the squares: 25923.127
Distance with fround on the squares as well: 25923.125
Distance according to ED: 25923.125

This makes sense intuitively: the square of a 10 digit number like 25899.96875 will have 20 significant digits. That's way more than single precision floating point can handle.

 

[TornSoul]

Ah yes - I was assuming (in fact not thinking about) that JavaScript doesn't actually by default print the full accuracy of the number.
So those float32's actually have some "trailing zeros" - Which get taken up as the decimal point is moved (when multiplying larger numbers)

The previous examples demonstrate it beautifully actually

Spoiler

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
	float3232 d22: 19.170 <= Math.round(19.16950035095215) Correct
	   float64 d1: 19.169 <= Math.round(1.91694999038185649454e+1) Wrong
	   float32 d2: 19.170 <= Math.round(1.91695003509521484375e+1) Correct
	float3232 d22: 19.170 <= Math.round(1.91695003509521484375e+1) 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
	float3232 d22: 64.243 <= Math.round(64.24349975585938) Correct
	   float64 d1: 64.244 <= Math.round(6.42435019209141557894e+1) Wrong
	   float32 d2: 64.243 <= Math.round(6.42434997558593750000e+1) Correct
	float3232 d22: 64.243 <= Math.round(6.42434997558593750000e+1) 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
	float3232 d22: 82.840 <= Math.round(82.84049987792969) Correct
	   float64 d1: 82.841 <= Math.round(8.28405023410952026097e+1) Wrong
	   float32 d2: 82.840 <= Math.round(8.28404998779296875000e+1) Correct
	float3232 d22: 82.840 <= Math.round(8.28404998779296875000e+1) 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) Correct
	float3232 d22: 131.337 <= Math.round(131.3365020751953) Correct
	   float64 d1: 131.336 <= Math.round(1.31336496795921135572e+2) Wrong
	   float32 d2: 131.337 <= Math.round(1.31336502075195312500e+2) Correct
	float3232 d22: 131.337 <= Math.round(1.31336502075195312500e+2) Correct

The very last example only has room for two more digits, before rounding on the very last significant digits sets in - Because the distance got above 99.
Same goes ofc for all the intermediary results.

And for the chosen it just so happens that the intermediary results doesn't push beyond this limit - thus there is no difference.

Which as you say, doesn't happen until we start using larger numbers.

 

[Snuble]

The eyeball method, I wonder if it is possible to do something with javascript/canvas/html5. That give access to the pixels in image. Dont have to upload, can get it directly in browser from file-input.

 

[Chromatix]

Since we now have an accurate position for Alpha Cygni, we can use it as a reference star for later work, along with the other external stars that we've been able to find good positions for. That's the main reason why I started looking up the positions of such stars in the first place.

However, I need to think about the precision stuff that's been turned up here, so that we know how far away a reference star can be before it stops being useful (which is a different question than the distance it can be away before errors in the measurement calculation become visible). My hunch is that Alpha Cygni is still useful for locating stars in a large area surrounding Sol, but Sag A* is not.

It is however interesting that Sag A* turns out *not* to be directly on the axis. It makes me suspect that the galactic coordinate system was defined before the actual centre of the galaxy was precisely located.

(NB: Polaris is also not precisely over the Earth's North Pole. However, the fact that it's anywhere near it is just a convenient coincidence, and has nothing to do with how we humans define anything.)

If anyone is feeling bored, perhaps attempting to locate the rest of the 58 navigation stars would be worthwhile. Many of these are close to Sol (being apparently rather than intrinsically bright stars), but others are far enough out to make useful external references. As an added challenge, ED doesn't always use the most popular name for each star, so some sleuthing may be required for several of them.

 

[wolverine2710]

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?

I've added you to list 1 aka "List of tools and programs created for the crowd source project." If you like to share your source code please provide a fixed linked where the latest (stable) version can be downloaded from.

 

[wolverine2710]

I finally finished my coordinate verifier tool (visit link to see how it works), and it also thinks that some coordinates are invalid:

LDS 1503
LHS 3297
WREDGUIA WH-Q B46-2

The tool thinks there is no valid coordinate for these systems, in other words, one or more of the distances must be incorrect. All other systems seems to be valid. I used this source.

So either the reported coordinates are incorrect (typo or rounding error), or there is something I didn't think of, and therefore not covered with a unit test in my tool.

I've added you to list 1 aka "List of tools and programs created for the crowd source project."

 

[Athan]

If anyone is feeling bored, perhaps attempting to locate the rest of the 58 navigation stars would be worthwhile. Many of these are close to Sol (being apparently rather than intrinsically bright stars), but others are far enough out to make useful external references. As an added challenge, ED doesn't always use the most popular name for each star, so some sleuthing may be required for several of them.

If anyone needs some help finding probable ED stars for a given real-name one maybe this will help: http://www.miggy.org/games/elite-dangerous/stardata/ , although I realise that it would be more useful if I provided a "real star name" -> "Probable ED co-ordinates" search. I'll have a look at that this evening.

 

[Athan]

Newsletter is out:

You’ll be playing Beta 3 in a volume of 868,744 cubic light years, containing 2,406 star systems, including 4,181 stars and 24,918 planets.

 

[Snuble]

Okay, we really need to get a grid set up for collecting data then. I'm having deadline panic on a few other projects, the kind that will provide income for the next year, so unsure how much I will get done.

What I do have is a 90% works for me 20^3 grid of the current pill, that I can easily expand to the new playable area. I'm guessing its a sphere this time, as it would fit 110ish of my boxes, giving an average of 22 systems. Thats way more dense then what I have now, so my guess is that 240-300 boxes will be more correct. If I can get it to 100% works for me, I could set up a seperate forum thread where our cartographers could "check out" what part of the space they are currently working on, and what data have been collected. Based on updated data, I could then give a star count for each grid and what grids have been explored.

For Beta 3 make sure you have made enough credits to get that explorer with 20LY jump range (13ish should be enough tough), plenty of fuel tanks and well the 1.5m for a advanced scanner would be very helpfull too... Hopefully there will be no 3 day showstopper bugs this time.

Wolverine should make sure there is one updated master list that is updated a few times a day so we can keep our tools as up to date as possible. Some will be interested in distance data, other like myself have more use for the calculated coordinates. The reason for having the most advanced scanner is that it from what I read scans the entire system. So those unknown get revealed without the hours of looking for a moving pixel. This might be a bug tough, and it should not be the priority to scan every object on that first trip trough space.

What would be usefull however is to collect data about docks and distance to them. This takes nearly no extra time compared to gathering the refernce distances. Given the "not all systems on scanner", opening the galaxy map to find all the connecting systems is essential to finding those 2406 stars.

Now FD could of course take the fun out of this and just give us the coordinates, but that we will know on wednesday...

 

[TornSoul]

Beta 3’s 2,406 star systems mean it is huge, about five times bigger than Beta 2

(man that took some fiddling to be able to post again... secure content... https vs http tsk tsk FD)

I like their rounding *cough*

2406/587 = 4.1

I guess if you round up...

But that means we get an extra area/volume (assuming star density is about the same) of 3 (and a bit) extra pills to play with.

I would have thought they would have pushed it much further than that..., considering SB3 supposedly is the last beta stage.

588 stars or 2406... I don't know, but that doesn't make much of a difference in my book - Testing wise.

You'd have to go at least a couple of magnitudes up from now, before it ought to test "the boundaries" of the code.
If expanding to 2406 is doing that - Then I'm a bit worried...

 

[JesusFreke]

(man that took some fiddling to be able to post again... secure content... https vs http tsk tsk FD)

I like their rounding *cough*

2406/587 = 4.1

I guess if you round up...

Maybe they were using single precision floats....

 

[wolverine2710]

Now FD could of course take the fun out of this and just give us the coordinates, but that we will know on wednesday...

This week I did send Michael Brookes asking if he could provide us with a new partial list of coordinates for SB3 IF the bubble/pill should expand. I wrote here a snippet of his reply

"Michael Brookes: A partial list should be possible".

The list will probably be like as with SB2, partial because it won't contain the procedural generated ones. I can ask him if we could get the list before launch (so we have a headstart) but I have this feeling it will be like last time. The day after the launch. Well actually it was the day of the launch because SB2 went online later then expected, not on the 30th of September but in the very very early morning/night of the 1st of October. Worth a PM though.

Edit: Thanks god the forums are back online. Saw Athan's post about the 2046 star systems but at the moment of hitting a large reply the forums borked and it was gone ;-(

- - - - - Additional Content Posted / Auto-merge - - - - -

Wolverine should make sure there is one updated master list that is updated a few times a day so we can keep our tools as up to date as possible. Some will be interested in distance data, other like myself have more use for the calculated coordinates. The reason for having the most advanced scanner is that it from what I read scans the entire system. So those unknown get revealed without the hours of looking for a moving pixel. This might be a bug tough, and it should not be the priority to scan every object on that first trip trough space. What would be useful however is to collect data about docks and distance to them. This takes nearly no extra time compared to gathering the reference distances. Given the "not all systems on scanner", opening the galaxy map to find all the connecting systems is essential to finding those 2406 stars.

My 'swallowed' reply to Athan was about automating the process further. Its almost time to go to bed. Will try to type it again but otherwise it will be tomorrow. I have some suggestions which I think are easy to implement giving our current tool set and which makes syncing the lot with each other a LOT easier.

EDIT: Forums are back to default settings it seems which as with another forum means. Post more then once in approx 10 minutes and you do NOT end up with a new post BUT its merged with your last post. Will have funny effect here in this forum where things go fast. Hope they restore old behavior soon. The default behavior is with default skin which explains why we don't see the nice skin they showed in last newsletter!!

 

[TornSoul]

The default behavior is with default skin which explains why we don't see the nice skin they showed in last newsletter!!

The default skin/theme is the FD forum skin (they make other games as well..)
But there is also a ED theme - But... it's not the one in the newsletter. I don't recommend trying it unless you got some eyewash close by.
(scroll you browser ALL the way to the bottom - In left bottom corner there is a theme selector. Took me awhile to spot... I went the way of user setting first )

Personally I've gone with the "Minimal Blackout" theme - Do let me know if they fix the ED default theme to something that looks like that one in the newsletter...