NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: The "Death to the Intercept Method" revisited?
From: Jing C
Date: 2017 Sep 21, 08:07 -0700
From: Jing C
Date: 2017 Sep 21, 08:07 -0700
I suppose I imposed a few arbitrary restrictions, I chose a method that could be done with a non-programmable scientific calculator (the worksheet stores intermediate steps), and I have a bias for the analytical approach. Also, the method in my worksheet does NOT require an assumed position, at least not until the very end where you need to choose one of the two solutions. The two solutions seem to usually be far enough apart that you only need the vaguest sense of where you are. And in the hypothetical alien drop off scenario, a third set of sights should narrow the choice down to one. Instead of an AP, what is being moved is the GP (or as one of the author puts it, the Earth is being rotated as the GP stays fixed.). Another restriction is ignorance, I am not familiar enough with the iterative approach to write up directions for how to do it on a non-programmable calculator. The trig functions were easier for me because of this and I think they would be for most people.
On Thu, Sep 21, 2017 at 3:33 AM, Geoffrey Kolbe <NoReply_GeoffreyKolbe@fer3.com> wrote:
"To go back to Tony's original question, (which was) to do the running fix with a direct calculation method using a calculator but not plotting. "
Since you are using a calculator as a "computer"; that is you are running a program which uses a number of variables and the calculator has sufficient spare memory to run the program, would it not be easier to use a process of itteration on an assumed position, which can be done to arbitrary precision? It might take a few microseconds longer, but it would not require the user to input an assumed position. I did that once with a programmable calculator (thirty years ago) and it was very successful....
Geoffrey Kolbe