You may be putting wholes into the Google Earth application, but I'll guarantee you it doesn't calculate by wholes as it tracks the globe, even if it 'answers' with wholes. Plus, have you compared the island's and Lae's positions (lat - long) on Google compared to the charts of 1937? Could be some slight differences; forgive that if you have / if there are not, just a thought.
The reason I believe Gary makes a big deal about precision is there is no way to work that on the charts on table top or especially in a moving plane, and there is no way that human (or autoflight) can track headings with an airplane anywhere close to what you can get out of a calculator. It's a matter of what's practical.
Jeff,
Whole degrees and who miles were used to plot the points given to Google Earth. GE did not compute anything as it only displays the data given to it in this case. I calculated the points using a different method.
What is interesting about following the flight plan is that it does not matter what position was known for Lae back in 1937 because you are following a set of instructions (flight plan) from the real point in space. The whole point to the exercise was to follow and plot the course that Williams created just to see where it ends up. I believe the answer is 19SM North of Howland. This of course does not take in to any of the errors that Gary mentioned (Rule of 60 for example). This was not any sort of attempt to create an X marks the spot, suggesting that this is where they ended up.
The real source of errors like human errors both in starring at compasses for many hours, celestial navigation errors, changing head winds, etc, would far exceed the errors in Williams plan. As John pointed out with the Noonan Pan Am document, Noonan was well aware of these errors inherent in the system.
When I think about all the potential errors I think of something like a cone of uncertainty much like is used in
hurricane forecasting. I have not yet attempted to do anything like that and as Gary suggested simple rules like the Rule of 60 captures the majority of the potential sources of error and makes for a nice simple computation. I guess that I cannot see any reason to expend a lot of effort in modeling potential errors unless you wanted to perform real experiments with say humans starring at a compass all day and track and average their responses. This would be a whole lot of work for little if any value.
I believe I now see why Gary pushes the point about the rumb line for simplicity. If you find that you are not on course for whatever reason, computing your way back to the rumb line flight line would be much easier than attempting to find your way back to the great circle flight line because in the case of the GC plan, you have to consider all of the headings and distances for all of the previous segments that you have completed up to the point where you want to perform new calculations. With the rumb line you do not need to worry about any of that and you can proceed to your calculations. For that reason alone I can see why the rumb line is the way to go. Perhaps I have that incorrect but that is the way I see it at this point. Perhaps Gary will correct me if that is not the case.
As for the precision stuff, I am of a completely different mind set. When you write software for a living, you cannot possibly consider and re-consider the practical precision for each calculation that you perform. You would go mad if you attempted to do so. For example, the following constant is used for Pi:
const double PI = 3.14159265359;
This is pretty unisveral in software development. You run your calculations using this value and you do not consider the precision of the particular task in the real world that is being performed, you use the theoretical value. As we know Pi has an infinite fractional value so you just pick a value that works for anything practical and run with it. At the output stage, yes, you can trim the data back to a reasonable precision however that is more work and of little value unless there is a need to do so. Like the KML file that I posted, that is generated by code for data representation, it is not meant to be read by anyone. If you peek under the hood you see this huge fractional value but there is a nothing of value gained by expending the effort to round to the nearest 10th for example as no one is supposed to view the data with an editor. In fact most of the values you using for floating point are internally stored as described and you are not concerned until a human has to read the value on a print out or summary report.
At least for myself, I believe I have learned quite a bit about the Williams flight plan and I find it interesting to walk through the mechanics of the calculations. There is probably no value in the final end point at Howland as I tend to believe now that FN did not use that plan due to the above mentioned reasons. The GC flight plan works great on maps and when you are going to simply follow a step by step instruction but if you need to make corrections as you go, this is not very practical. The problem with step by step instructions is they do not work over large areas when you know that you will be required to make corrections along the way.