Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
I tried to use it from go, and got the same response.
Code:
const apiurl = "http://edstarcoordinator.com/api.asmx/GetDistances"
resp, err := http.PostForm(apiurl, url.Values{ "ver": {"1.1"}, "date": {"2014-09-18"} })Please consider adding the route planner map to the list of tools using the coordinates, too:
Online
Forum
Source code
I need to add link to the map from Chromatix, since his work inspired my project in the first place.
Might be easier for you to grab my systems.json (link in first post) - it has all the systems we have so far and all the distance data I've got. I can upload the webpage I used to look at this issue too if you're interested.
wolverine2710
Tutorial & Guide Writer
Can you give us a list of the systems you are missing distances data for? Or the distances which you miss.
Perhaps one of the commanders here (which have created a tool) does have that distance info. After all things were hectic in the last week!! Unfortunately Harbinger which has done tons of work had not archived all his distances early in his discovery process - so it might just not exist.
If the distance data does NOT exist perhaps it can be supplied by volunteers. BUT the INCENTIVE to do so would be greater if it would bring some extra functionality, extra checks to the table.
Atm we have 573 3D coords in euclidean space. I guess (not an expert) a graph (with only distances) is being constructed from that and on that graph third party tools use Dijkstra/A* search for stuff like shortest path routines. Before wtbw and MB gave us 3D coordinates in a BPC crowd source effort, ONLY distances were gathered. Those were used to create a graph.
Suppose we have a distances graph created from 3D coordinates. Suppose we ALSO have a distances graph solely based on distances - crowd sourcing the ones you are missing. Could that not be used to double check results. Again laymen. Suppose we go from for example every star system to every other star system and calculate the length of the route (using whatever routine like shortest path, longest path etc etc) and do that for both graphs. If everything is OK then each and every length should be the same - aside from potential rounding errors. Or am I completely and totally mistaken.
If we should crowd sourcing more distances might I suggest using RW's tool for that. It directly shows if an typo is being made. Also he is the maintainer of THE reference. Using his tool would make feeding the distance data in his reference most efficiently. Again I can be mistaken.
What do you commanders think about this. Has it merits, is it rubbish. Should we all go out and get the missing distances for Chromatix (I mean for us ALL)?
Last edited:
I wanted to ask just that, whether it has all the information that so far had been collected. Thanks for the info.
wolverine2710
Tutorial & Guide Writer
There is a misunderstanding going on. Likely because I didn't communicate clearly. The way I see it is that the "List of tools and programs created for the crowd source project." is a list of tools used/create in/for the crowd sourcing project. Stuff like tools for entering distances, calculating 3D coordinates, verifying the results etc. It is NOT meant to be a "list of tools using the coordinates". The OP was not ready and on my TODO list was the following (which I just added) "List of third party tools using star systems (coordinates)."
I saw your very useful input here. Can't recall if you have made stuff for verification etc (not a perfect memory). Can you please tell me in what list I can best put you? There WILL be overlap and for example Chromatix will end up in both lists. Note: If you don't mind I certainly add your name in the credits list.
I have some stuff bookmarked for the second list. It would be very much appreciated if anyone can give me urls for the spoilertag "List of third party tools using star systems (coordinates)."
Note: In fact I was planning on creating (time permitting) a thread called something like "Complete overview of all third party tools and data". The second list will fit nicely into that one ;-)
Last edited:
Thanks for the explanation.
I haven't been able ot do anything yet to improve/calculate coordinates, and I am not yet sure if my plans will improve anything in the first place. Therefore I believe I do not (yet) belong to the credits. I just thought my map is a good visual representation of the work you all have done here, therefore might be considered for addition to the "List of third party tools using star systems".
wolverine2710
Tutorial & Guide Writer
I respect your choice, though misplaced. I've added you to the second list, shown beneath.
WIP, searching my bookmarks and updating it.
The tools are listed by commander name - in alphabetic order.
- Biteketkergetek. Route planner visualized in 2D.Website. Forum. Source code
- Chromatix.Generates 3D map with routes based on fuel-efficiency.
Thread "Complete Maps of the Bubble ".Sourcecode. - RedWizzard. Web based. Runs locally in your browser. Complete overview of star system data, which can be viewed/sorted in different ways.Github url. Download as zip.
- TornSoul.A web-api for retrieving systems and distances. EDStarCoordinator.
Last edited:
I've updated the systems.json data to include the time and contributor info from Smacker's TD version (existing contributor info also retained for now). The systems.html has also been updated and should produce CSV output that is very close to TD's. Also fixed some stuff in entry.html.
wolverine2710
Tutorial & Guide Writer
Looks good. Must again been an awful amount of time you put into it. I was worried about the contributors part. Not that much because of crediting but for backtracing in case of problems but I saw that in the system.json file it still exists. I do hope you keep it. Perhaps it can be used for crediting in the future. The new region tag in the json file is very handy.
Didn't speak up yesterday (my bad) but I actually liked the ability to create a csv file which was sorted like it was selected.sorted on screen. Yes it was possible to generate a file different then the TD one but it added flexibility.
Any change of getting a switch for it? That would be great - for me....
Edit: Again today did not have time to test your tool further and write down suggestions. But hey its only 3:49 PM here so there is time. Sleep well.
I assume this is Keries <> WREDGUIA WH-Q B46-2 (this is why I needed access to the data, to have the co-ords of the latter).
Using a pure C program with purely floats, and the math.h sqrt() and pow() on a Linux system I get:
Code:
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
typedef struct {
char name[128];
float x;
float y;
float z;
} star;
star stars[] = {
{ "Keries", -18.90625, 27.21875, 12.59375 },
{ "WREDGUIA WH-Q B46-2", -132.6875, 26.46875, -53 }
};
int main(int argc, char *argv[]) {
float d = 0;
d = sqrtf(
powf(stars[0].x - stars[1].x, 2) +
powf(stars[0].y - stars[1].y, 2) +
powf(stars[0].z - stars[1].z, 2)
);
printf("Distance: %10.6f\n", d);
return 0;
}
14:57:54 2$ ./rounding
Distance: 131.336502i.e. 131.337 when rounded. Thus I'd conclude that this could be what the game is doing and the 'incorrect' rounding is an artifact of using purely 32 bit floats and what goes on with those inside sqrt() and pow() functions.
My basic point is that you can't confirm/deny things like this unless you're using the same format to store and operate on the numbers, and possibly the same exact methods to operate on them (I now need to look at the disassembly to see what instructions ended up being used).
Using perl, python, php, c# ... could just mean you're using a different data type and different functions and thus any number representation and rounding will be different. I think we can assume the game is using whatever Visual Studio provides for C++.
Edit: For example if I use 'bc' (an arbitrary precision calculator), I get:
Code:
sqrt(( -18.90625 - -132.6875)^2 + (27.21875 - 26.46875)^2 + (12.59375- -53)^2)
131.33649Edit2: Further testing shows that the discrepancy likely creeps in only at the last stage of calling sqrtf(). Indeed if I call sqrt() instead, which returns a double, I get "131.3364967959" as the answer. Maybe we've found something that FD could fix/change in their code ?
Last edited:
Will do. I think there is some value in being able to find any new systems at the bottom of the csv block (which is where they'll be if the table hasn't been sorted). So I think I'll default to same order as the table and have a button to sort alphabetically.
And it looks like my hypothesis explains all 4 of the rounding discrepancies that RedWizzard highlighted:
Code:
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
void test_systems(int first, int second);
typedef struct {
char name[128];
float x;
float y;
float z;
} star;
star stars[] = {
{ "Keries", -18.90625, 27.21875, 12.59375 },
{ "WREDGUIA WH-Q B46-2", -132.6875, 26.46875, -53 },
{ "HIP 91906", -108.09375, 57.1875, -33.59375 },
{ "Wredguia UR-Q b46-2", -97.78125, 56.875, -49.75 },
{ "Loga", -79.78125, 36.53125, -42.0625 },
{ "LFT 668", -19.03125, 25.65625, -24.21875 },
{ "Haras", -118.75, 14.40625, -21.40625 },
{ "LHS 3297", -36.46875, 22.6875, -16.53125},
{ "", 0, 0, 0 }
};
int main(int argc, char *argv[]) {
int s = 0;
while (stars[s].name[0] != '\0') {
printf("%s and %s\n", stars[s].name, stars[s+1].name);
test_systems(s, s+1);
s += 2;
}
return 0;
}
void test_systems(int first, int second) {
float f = 0;
double d = 0.0;
f = sqrtf(
powf(stars[first].x - stars[second].x, 2) +
powf(stars[first].y - stars[second].y, 2) +
powf(stars[first].z - stars[second].z, 2)
);
d = sqrt(
pow(stars[first].x - stars[second].x, 2) +
pow(stars[first].y - stars[second].y, 2) +
pow(stars[first].z - stars[second].z, 2)
);
printf("\tDistance (float): %20.10f ( %7.3f )\n\tDistance (double): %20.10f ( %7.3f )\n",
f,
f,
d,
d
);
}
Code:
15:37:35 1$ ./rounding
Keries and WREDGUIA WH-Q B46-2
Distance (float): 131.3365020752 ( 131.337 )
Distance (double): 131.3364967959 ( 131.336 )
HIP 91906 and Wredguia UR-Q b46-2
Distance (float): 19.1695003510 ( 19.170 )
Distance (double): 19.1694999038 ( 19.169 )
Loga and LFT 668
Distance (float): 64.2434997559 ( 64.243 )
Distance (double): 64.2435019209 ( 64.244 )
Haras and LHS 3297
Distance (float): 82.8404998779 ( 82.840 )
Distance (double): 82.8405023411 ( 82.841 )I don't know if your clib has special handling for the power of two, but perhaps you should try simple multiplication, i.e. use x*x instead of pow(x, 2).
Maybe, but I did some tests and that part of the program wasn't what was throwing things off (compared to 'bc' output, which as I said is arbitrary precision, and I bunged its scale (significant digits) up to 100).
The discrepancy really is in sqrt() versus sqrtf().
Edit: But I double-checked anyway, and indeed doing x*x by hand makes no difference compared to using pow(x, 2).
Last edited:
wolverine2710
Tutorial & Guide Writer
Athan. Thanks for having a go at it. I've not been really following this rounding part of the crowd source project so perhaps can you explain me something.
Did I understand correctly that with what you found all rounding issues can counted for and avoided?
If so does it mean that by changing some part in the programs used so far (if possible) we can get outcomes which are the same as what ED tells us?
Did I understand correctly that with what you found all rounding issues can counted for and avoided?
If so does it mean that by changing some part in the programs used so far (if possible) we can get outcomes which are the same as what ED tells us?
It's more of an explanation for why the game displays some wrong figures for distances. Everyone's work here has avoided the 'error' FD have made. But, yes, in theory people could make use of this knowledge to ensure we always use the same figures that FD do.
We can probably assume that the game does the exact same math for displaying a distance as it does for checking a destination is in jump range, but there's an outside chance that it doesn't. That's going to be tricky to check though. Off the top of my head I suspect even a Type-9 with maxxed cargo bays can't be made to have a 0.001ly range difference (due to adding/removing 1T) for specifically one of these "off by 0.001" cases. i.e. it's going to be moot in practice any way.
Edit: And on a quick check, you couldn't, for instance, force perl to use only single-precision floating point to get answers matching the in-game ones. You're stuck with double-precision. I suspect java, javascript, c#, php, python etc are going to face the same issue, being higher level languages.
Edit2: Actually looks like you can force float32 usage in python at least.
Last edited:
I wonder if it is possible, too. If it is possible to use 32-bit floats in your language, then this could work. Even in this case different sqrt implementations may end up yielding different results. I don't know how well the behavior of sqrt on single-precision floats specified, perhaps it is implementation specific?
Perhaps it is reasonable to assume ED uses the sqrtf function of the msvcrt.dll version it loads.