According to my calculation, EHLE-EDHK is 205 NM. But then again, spheric distance calculation tends to require wide words especially for longer distances and I'm using only IEEE double.
This should be 265NM. KEKIX N873 JUIST P174 NIMDO P999 DHE L619 LBE P615 RENSU RENSU5M
It's bit of a zig-zag around Helgoland and Elbe VOR's, but the germans should give you shortcuts.
Hi Tom, the problem I was referring to is that the displayed % of distance seem to be incorrect.
From the screenshot: Length: 273NM (118% of direct)
273NM is not 118% of 202NM (or the 205NM from your calc).
I did wonder about the very low overheads over GC mentioned but didn't check it at the time.
IEEE double is 64 bit float, no? That is loads of precision, surely?
IEEE double is 64 bit float, no? That is loads of precision, surely?
Yes; I haven't made any lengthy investigation, but the difference between single and double is very noticeable, even at short distances.
No one wants to try my route? EGTK to LEGE FL270?
A normal C "IEEE float" is a 24 bit mantissa and 8 bit exponent. That is easily good enough for any "real world" maths.
A double IEEE float is (from memory) a 48 bit mantissa and a 16 bit exponent. That is many orders of magnitude beyond the precision to which any physical constant in the universe is known.
Not knowing anything about what you are doing, I would suggest that if you need a double float to keep errors to a reasonable value, there is something very weird about the algorithm, the way the expression is evaluated, or perhaps there is a bug in the compiler implementation (I have seen that on a Hitachi H8 C compiler; it occurred at the same time as the infamous Intel floating point bug problem so we specially checked it and found it 
).
I also recall compilers on which trig functions (e.g. sin(x)) were always evaluated as double, and one then got issues with casting these into normal floats (due to compiler bugs).
We will double check the offset from the direct GC distance. Could of course very well be that we made a mistake there, but that should be very easy to solve. We also have the airways structure and all the airspaces in our database, so theoretically we could draw much more on the map, but we did not get around yet to doing that and giving that priority. Our focus at first is to deliver a good IFR routing engine.
I am sorry: I tried but no route found for EGTK to LEGE @ FL270. Don't know why. Will have to check.
From Biggin Hill to Girona I get: LYD M189 SANDY DCT LAM DCT MID UN615 XAMAB UL612 RESMI UN857 DIRMO UN855 KANIG
Thanks. Yep, pretty well same as RR - seems hard to save much in airways down that part of France.
Does anyone know how to find routes with AeroPlus for Z flight plans? Neither the Quick search nor the Extensive search come up with any proposal. Departing from a VFR field obviously requires a Z plan. For example I cannot find any plan when departing LSGL with a destination at typical IFR summer destinations by the Mediterranean or any large IFR airport either, e.g Paris, Munchen etc.
Any ideas?
As a comparison, FlightPlanPro nails virtually all destinations with Z plans and EuroFpl has a fairly good coverage for typical destinations.
Thanks, GF
