Airborne_Again wrote:
Timothy should have accepted the bet…
I think you’ll find I did 
This has been a long and frequent discussion on their forum site.
Few people have the time to follow loads of forums. Are you able to summarise?
No, they don’t and they continue to do the wrong thing. Case closed.
Most reasonable people would not regard that as a helpful post, so why make it? We have been there before, haven’t we?
denopa wrote:
despite setting SD to decimals, I can only enter waypoints in seconds
Sorry to hark back to a while back, but there is a button to allow you to enter in decimal minutes manually:
Timothy wrote:
I agree that there are two unrelated things going on.
In the end it’s the same things, simplifications. Rhumb line makes sense using an appropriate map and a compass. You follow the same heading on the compass from A to B. It makes no sense whatsoever if you are to follow a magenta line on a moving map.
The other error must be round off errors IMO. The GTN with it’s ancient hardware probably use single precision float (or some integer representation with similar precistion). If the distances approaches single digit kilometers (or NM), then there are too few digits of accuracy to calculate that distance with any accuracy at all. It’s all described https://en.wikipedia.org/wiki/Great-circle_distance. This means the precision is +- a few of nautical miles.
Why Skydemon, which do not use GC, cannot manage to calculate this correct, is another question. I think the only logic to that is their own logic: “It doesn’t matter”. They don’t calculate any distance correct (not a single one), so why do it for smaller distances? One can only wonder what else “doesn’t matter” to them.
EasyVFR calculates all of this correct.
I can’t see rounding errors being the cause of the OP issue.
32 bit IEEE floats (which is most likely what they use; fixed point integer paths needs serious competence to avoid over- and under-flow) still give you a 24 bit mantissa, which is about 8 decimal digits.
To me it sounds like some cockup.
Peter wrote:
is about 8 decimal digits.
- which gives an accuracy of a few NMs, pure and simple, basic math when doing GC calculations. When the distance is only a few NM, then the error becomes very visible. Double precision will give you an accuracy of a few meters.
In the first case it is Garmin that is arguably “wrong” (I am not sure I agree) and SD right.
But I am pretty sure that it’s nothing to do with rounding, as the GTN gets it right in the static case, then, I think deliberately, “improves” it in the dynamic case, whereas SD continues to show the static case throughout.
In the second case it is clearly SD that is wrong and Garmin right.
Peter wrote:
This has been a long and frequent discussion on their forum site.
Few people have the time to follow loads of forums. Are you able to summarise?
Summary easy: they know it is wrong, but argue it is easier for them this way and decided to continue to do wrong.
No, they don’t and they continue to do the wrong thing. Case closed.
Most reasonable people would not regard that as a helpful post, so why make it? We have been there before, haven’t we?
It is useless to continue a discussion and argue without the accused, when the accused already has all the information and took a decision in full awareness of it being wrong. Skydemon decided to stay a non-professional assistance tool for hobby pilots. We should treat it as this and not interpret anything serious into it.
Timothy
Accepted the bet
You did, but we hadn’t agreed a wager! I was confusing the behaviour of the indicator at the top with the bar, sorry…
LeSving wrote:
The other error must be round off errors IMO. The GTN with it’s ancient hardware
The GTNs have ancient hardware? Are you thinking of the GNS series?
probably use single precision float (or some integer representation with similar precistion). If the distances approaches single digit kilometers (or NM), then there are too few digits of accuracy to calculate that distance with any accuracy at all. It’s all described https://en.wikipedia.org/wiki/Great-circle_distance. This means the precision is +- a few of nautical miles.
Sorry, but that’s nonsense. The Wikipedia article you refer to states that one particular formula gives poor accuracy with single precision floating point. That does not in any way mean that you can’t compute positions with high accuracy using only single precision using a different formula. The same article even shows two examples of such formulae!
Why Skydemon, which do not use GC, cannot manage to calculate this correct, is another question.
As several posts have already shown, SkyDemon does use GC for navigation calculations, however not for displaying the magenta line on the map. Probably because it is more difficult to render a GC track correctly.
