NavList:

There is a distinction to be made between the intrinsic accuracy of numerics on modern computers on the one hand, and getting an inaccurate result due to an inaccurate input (i.e. error propagation through a formula) on the other.  I think the former is quite good, while George makes a valid argument about the latter.

I base this comment on my experience with Excel, which yields the discriminant = zero (instead of, say, -1e-10) for the test example I presented with Van Allen's method.  The comparison of the computed second altitude (now using John Karl's equations) with the known input value (my suggestion for resolving the LHA1 ambiguity) shows a little round-off, as their difference was of the order of 1e-14.  I was very happy to see that Excel adequately handles VSOP87 formulae, that in some cases require summations of more than a 1000 terms.

There is one case, however, where I have seen Excel's numerical abilities challenged.  It occurred in extracting a fix from a noon-curve (or any meridian transit, for that matter).  If I use the charting feature and extract the parameters of the quadratic fit from there, everything is fine.  If, on the other hand, I use quadratic least-squares formulae from Meeus without plotting a chart, the results can be a bit off...  A Fortran program in double precision shows the same problem, while the same program compiled in quadruple precision gives accurate results yet again, agreeing with Excel's chart and fitting results.  Interesting, does anyone know enough about Excel's inner workings to explain this?  I addressed the problem in Excel by first stretching the time axis to a larger interval, run that stretched noon curve through the least-squares formulae, and the recompress the results for LAN and longitude to the original scale.  That seems to work OK, as we have seen from my processing of Jeremy's and Antoine's meridian transit data a few weeks ago.

Peter Hakel