Maybe have one "mindistancetoscoopable" value. That way you would know the distance to the nearest scoopable star in the system. The other would be to actually have an array of stars in the system and let the 3rd party tool figure out what classes are fuel source.
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Maybe have one "mindistancetoscoopable" value. That way you would know the distance to the nearest scoopable star in the system. The other would be to actually have an array of stars in the system and let the 3rd party tool figure out what classes are fuel source.
I have updated my entry.html to use TGC. The new version is available on github (here, direct zip).
To be able to submit to TGC a system must have 5 valid distances to reference systems (systems with cr = 5 in TGC; probably only FD supplied systems qualify at the moment), and the distances entered must result in a single candidate location that matches 2 distances more than any other candidate location. The page will tell you how many best candidate locations there are, and if there is only one it'll give you coordinates and the number of distances that candidate is leading by. Distances which don't match when recalculated are flagged and will not be submitted. Distances to systems that are not in TGC will be submitted (but can't be tested so it's best to be careful with them).
There is a checkbox to switch between the test and production databases. Currently it defaults to test. I'll remove this once I'm happy it's working correctly.
I've updated the default reference systems to Sol, Kato, Cayu, Prim, Sabi, Aka, and Juno. These are all around 150 Ly from Sol along the axes so they are very good references for anything within a few hundred Ly of Sol. They also have short names. Anyone looking for a set of standard systems to use might like to check them out.
To be able to submit to TGC a system must have 5 valid distances to reference systems (systems with cr = 5 in TGC; probably only FD supplied systems qualify at the moment), and the distances entered must result in a single candidate location that matches 2 distances more than any other candidate location. The page will tell you how many best candidate locations there are, and if there is only one it'll give you coordinates and the number of distances that candidate is leading by. Distances which don't match when recalculated are flagged and will not be submitted. Distances to systems that are not in TGC will be submitted (but can't be tested so it's best to be careful with them).
There is a checkbox to switch between the test and production databases. Currently it defaults to test. I'll remove this once I'm happy it's working correctly.
I've updated the default reference systems to Sol, Kato, Cayu, Prim, Sabi, Aka, and Juno. These are all around 150 Ly from Sol along the axes so they are very good references for anything within a few hundred Ly of Sol. They also have short names. Anyone looking for a set of standard systems to use might like to check them out.
Why this restriction?
Doesn't really matter what the cr value is - if distances check out.
Would be highly unlikely to have a system with wrong coords - and yet the distance (along with the rest) checks out to provide a candidate.
While we are still mostly inside the "sphere" of systems provided by FD it's mostly a non-issue I guess (plenty of system to pick from), but once moving outside that, it would start becoming troublesome I'd think.
Just my 0.02 credits.
I agree - I don't distinguish between FD-provided and calculated systems. And I tend to use calculated systems as a reference more than FD-provided, because I'll usually jump to a new unknown system, get some distances to known stars (either FD provided or not) to pinpoint its location, and then get a ton of distances (usually 50-100) to any other star I know of that still needs distances.
- - - - - Additional Content Posted / Auto Merge - - - - -
But if you do have access to the system view, the top-most star is the one you jump to, right?
Last edited:
Only because it makes it easier for me to recheck all calculated coordinates (which I do when FD may have changed the procedural generation, i.e beta->gamma and gamma->release). If a system's coordinates can only be found using distances to calculated systems then I would need to calculate those systems first: order of calculation of systems would matter. That can easily be handled with multiple passes but my tools don't currently work that way. You're right that it would become unworkable as we move away from the populated area and I'll take out this restriction after gamma.
Hmmm
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Banya: 4.88 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Banki: 14.45 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Pisaly: 11.16 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Kambala: 6.57 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Kaline: 5.61 LY.
Distance appears to be wrong - Please re-check and re-submit Dist: Hyades Sector MI-S C4-15->Pisaly: 11.16 LY.
System added. - Hyades Sector MI-S C4-15
I've double-checked the distances on the GM.
Could the rest of you run this through you algorithms. Maybe I missed a float/double somewhere...
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Banya: 4.88 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Banki: 14.45 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Pisaly: 11.16 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Kambala: 6.57 LY.
Distance added, but failed to verify coordinates. Dist: Hyades Sector MI-S C4-15->Kaline: 5.61 LY.
Distance appears to be wrong - Please re-check and re-submit Dist: Hyades Sector MI-S C4-15->Pisaly: 11.16 LY.
System added. - Hyades Sector MI-S C4-15
I've double-checked the distances on the GM.
Could the rest of you run this through you algorithms. Maybe I missed a float/double somewhere...
Double Hmm:
But I don't have this float32 conversion in my program.
Code:
Calculating: Hyades Sector MI-S C4-15 (from TornSoul)
Matches ref: 2, pos: 2, neg: 2
New: Hyades Sector MI-S C4-15 (43.46875,26,-99.90625): references: 10
Banya : 4.88 4.88
Banki : 14.45 14.45
Pisaly : 11.16 11.17 !
Kambala : 6.57 6.57
Kaline : 5.61 5.61
calculations: 20; time: .016000; coordinates: 1
no insertBut I don't have this float32 conversion in my program.
Last edited:
When in MI-S
Don't recall anything that stuck out. Not saying there isn't.
It works fine for me. I get -6.3125, -11.6875, -4.125, with no errors to any of those 5 systems.
FWIW, here's how I calculate the distance in python:
round(numpy.linalg.norm((coord1 - coord2).astype(numpy.float32)), 2)
Where coord1 and coord2 are both float64 numpy arrays
Edit: removed my incorrect explanation
Last edited:
Hä? I get: Hyades Sector MI-S C4-15 (43.46875,26,-99.90625) and looking at the GM this seems correct.
Just a reminder, what I found about the distance calcs was that it specifically used the single-precision SQRTF/FSQRT function (probably the instruction on X86 CPUs), which itself causes different answers from double-precision floating point, even if you feed them both single-precision numbers to start with. Thus doing:
is not the same as what the game actually appears to be doing which is:
I literally saw things like 82.840 with FSQRT versus 82.841 with SQRT on the same input (a 'float' in a C program).
----
In other news, as Cmdr.Club route planner seemed to be broken today I got around to putting a web frontend on my own route planner. No auto-complete on system name input, but after crushing a couple of bugs this evening it seems to be working for people.
TornSoul, note I am now updating my local DB from EDSC once an hour. Given that in the case of no change I'm only querying for anything update at or since the time of the last update I saw I'm thinking I could increase that frequency without causing you issues, yes ?
Code:
SQRT(tofloat32(number))is not the same as what the game actually appears to be doing which is:
Code:
FSQRT(number)I literally saw things like 82.840 with FSQRT versus 82.841 with SQRT on the same input (a 'float' in a C program).
----
In other news, as Cmdr.Club route planner seemed to be broken today I got around to putting a web frontend on my own route planner. No auto-complete on system name input, but after crushing a couple of bugs this evening it seems to be working for people.
TornSoul, note I am now updating my local DB from EDSC once an hour. Given that in the case of no change I'm only querying for anything update at or since the time of the last update I saw I'm thinking I could increase that frequency without causing you issues, yes ?
I'm getting (43.46875, 26, -99.90625), calculated distance to Pisaly is 11.16 with single precision sqrt. I get 11.17 if I do the sqrt using double precision.
I came across a similar discrepancy last night. What do you guys get for the distance between LHS 3093 (22.875, 4.78125, 35.6875) and Col 285 Sector LM-W a31-4 (-40.9375, 125.25, -6.90625)? Galaxy map says it should be 142.82 but I get 142.83.
Edit: Yes, that COULD be the difference.
Well, this one is the difference between SQRT and FSQRT:
Code:
LHS 3093 and Col 285 Sector LM-W a31-4
Distance (float, pow): 142.8249969482 ( 142.825 )
Distance (float, fs ): 142.8249969482 ( 142.825 )
Distance (double, pow): 142.8250062905 ( 142.825 )First line is FSQRT using pow() to do the squaring beforehand. The second line is doing the squating 'by hand' using a simple multiplication, but still FSQRT. The last one is using plain SQRT (the double precision version), and pow().
Last edited:
Oops, I'm an idiot
. I had copied the data from another system to use as a template and forgot to delete the coordinates. And since it didn't have calculated=true, it didn't verify the existing coordinates.After fixing that, I was still able to calculate the coordinate without any errors. The coordinate I get now is 43.46875, 26, -99.90625
I'm getting 142.82 as well
Code:
import numpy
def get_display_distance(coord1, coord2):
return round(numpy.linalg.norm((coord1 - coord2).astype(numpy.float32)), 2)
print get_display_distance(numpy.array([22.875, 4.78125, 35.6875]), numpy.array([-40.9375, 125.25, -6.90625]))Huh. I tried it via one of the online IDE/interpreter things, and the same code gives me 142.83
http://ideone.com/0WFBje
Last edited:
I've tested the GetSystems API of EDSC the first time now. I wrote the code and structures (which use reflection) based on the docs, and they worked after just minimal changes.
This was my experience/first impressions, some of them might be relevant for statically typed languages only.
- GetSystems uses POST instead of GET making the API unnecessarily hard to use. It could be implemented using GET, therefore it should just use GET. I can imagine complex queries that would require a structured object, but those should be done likely within a local mirror of TGC anyway.
- Both the query and response use semi-undocumented wrappers ("data" and "d", respectively) around the actually documented parameters. I say semi-documented because this can be found out if one carefully looks at the examples. I just use reflection so at least for the query part I wasted some time figuring it out. I could have saved some time if at least the query and response examples JSON objects mentioned them, or if the API returned a meaningful error message instead of just
in this case.
- "ver" accepts an integer only but returns a floating point value. Perhaps it should be standardized as an integer for symmetry in both places, and use an additional version string in responses if necessary.
- From the API docs it is not clear which timezone the time stamps (query/response) should be in. Since UTC is mentioned on the page, one can only hope it is indeed UTC.
- Time format should perhaps use RFC 3339. I think it would be the most suitable for the wire format. Basically "T" instead of space and "Z" at the end for UTC.
I believe the above issues might be a bit of an issue for any newcomers. The API is certainly usable however. Thank you for doing it, nice work!
This was my experience/first impressions, some of them might be relevant for statically typed languages only.
- GetSystems uses POST instead of GET making the API unnecessarily hard to use. It could be implemented using GET, therefore it should just use GET. I can imagine complex queries that would require a structured object, but those should be done likely within a local mirror of TGC anyway.
- Both the query and response use semi-undocumented wrappers ("data" and "d", respectively) around the actually documented parameters. I say semi-documented because this can be found out if one carefully looks at the examples. I just use reflection so at least for the query part I wasted some time figuring it out. I could have saved some time if at least the query and response examples JSON objects mentioned them, or if the API returned a meaningful error message instead of just
Code:
{"Message":"There was an error processing the request.","StackTrace":"","ExceptionType":""}- "ver" accepts an integer only but returns a floating point value. Perhaps it should be standardized as an integer for symmetry in both places, and use an additional version string in responses if necessary.
- From the API docs it is not clear which timezone the time stamps (query/response) should be in. Since UTC is mentioned on the page, one can only hope it is indeed UTC.
- Time format should perhaps use RFC 3339. I think it would be the most suitable for the wire format. Basically "T" instead of space and "Z" at the end for UTC.
I believe the above issues might be a bit of an issue for any newcomers. The API is certainly usable however. Thank you for doing it, nice work!
What language are you using?
According to this the result of casting a double precision sqrt function to single precision will be the same as a single precision sqrt provided the argument in the double case is a converted single precision value. i.e. it's possible to implement FSQRT as:
Code:
function float FQSRT(float x) {
return (float)SQRT((double)x);
}My bug turned out to be due to this inequality: given doubles a, b, c,
float(a + b + c) != float(float(a + b) + c) for some cases.
Last edited:
This is quite aggravating. Nothing worse than inconsistent results from identical code.
My Javascript code should being doing that same thing: calculating the distance in double precision, rounding to single precision using Math.fround, and then rounding to 2 dp. It worked for all the cases we had before and now here's a case it doesn't work for. I guess Athan is right: there are cases where rounding the result of a double precision sqrt to single precision gives a different answer to doing a single precision sqrt.
Edit: Oh, it's not the square root; it's the addition. I have to apply Math.fround to the results of additions as well as multiplication and the sqrt itself:
Last edited:
Compiled 'C' using gcc 4.7.2 and glibc 2.13. As I said above, it comes down to hitting 'SQRT' versus 'FSQRT' down at the assembly/CPU level. The latter has much lower accuracy on answers, but appears to be what FD are using in-game. As such there are some edge cases where results go either side of a 'half' point and can affect rounded answers.