|
Author
|
Topic: Stark tables
|
Arnold
|
posted August 10, 2020 09:09 AM
Good day. I was digging into Stark tables. I figured out that the K tables are Log10 [Hav]; whereof Hav = 1-cos(angle) / 2. I found also the explanation of table 7 and 8 mentioned earlier. I am curious how Gaussians table are made up, I could not figure out. Do you have a clue or suggestion? best regards,
Arnold
From: Grashoff
|
|
Capt Steve Miller
|
posted August 10, 2020 09:25 AM
Personally, I do not know how the various tables were developed, I know quite well how to use the tables.
From: Starpath
|
|
David Burch
|
posted August 10, 2020 09:32 AM
Articles by Bruce Stark and by Jan Kalivoda on the workings of this method are in the Navigator's Newsletter, which might discuss this. See at https://www.starpath.com/foundation. These articles are now public.
From: Starpath, Seattle, WA
|
|
Arnold
|
posted August 10, 2020 11:28 PM
Thank you.
From: Grashoff
|
|
Arnold
|
posted August 12, 2020 03:19 AM
Yeah! I found it now. Gaussian log(1+10^-x)
From: Grashoff
|
|
Arnold
|
posted August 12, 2020 01:29 PM
Recently I also found a book of interest. I just like to share this tip for anyone's interest. How did they calculate the Lunar Distance in the past? In the time, far from sophisticated calculators, like computers, just for some historic review :-). Haversines Natural and Logarithmic Used in Computing Lunar Distances For The Nautical Almanac. Printed in London for Her Majesty's Stationery Office 1876. (It's a copied reprint from Scholar Select series). ISBN 9780343441333.
From: Grashoff
|
|
|
|
Arnold
|
posted August 15, 2020 06:01 AM
That's the totally right source. I found also that it is indicated not to be given the most correct output. Therefore modern math from Stark indeed improves the result of calculating. :-) As I was working out many lunar sights, I found that input from Nautical Almanac data affects the output as well. I just received the American Nautical Almanac (which is giving for HP indeed more detailed information), but for the numbers of GHA and decl. the seem to match with the Brown's Almanac (UK). Earlier I noticed online a free accessible nautical almanac version (www.nauticalalmanac.com), perhaps for a hobbyist, giving other gha and decl. numbers. But as I was working with the PilotStar-PC it is giving by internal almanac also some other numbers, which at the first glance perhaps are looking no so notorious big in difference, working out lunar sights and timing calculation, it is giving much more difference. In a attempt to interpret data, and get more underbuilt answers on the attained numbers, I was curious how to learn more about the differences in gha and decl. numbers. I found out, for example, that The Nautical Almanac, by book from Her Majesty's Nautical Office, is adjusting Venus for its phases by adapting the gha and decl numbers. Is the difference just some coincidental occasion, or are they truly intended, with another point of view in setting up the data tables?
From: Grashoff
|
|
David Burch
|
posted August 15, 2020 10:43 AM
You are right that a Lunar Distance computation is one of the best ways to test the precision of almanac data since small errors on input can have notable effects on the results, not to mention there are special refraction computations that are equally important.
In one sense, lunars solved by the Stark Tables using official almanac data input are the primary solution in that if we had electronics at hand we have other ways to find our time and longitude.
With that said, we will look into the ways to optimize the lunar solutions for later models of the StarPilot. There are now several accurate solutions online that can be used for comparison.
As for the logic of the Almanac computations, I think the primary reference is the Explanatory Supplement to the Astronomical Ephemeris and the American Ephemeris and Nautical Almanac which is old (1961), but there may be newer references in the Almanac itself.
There is also a brand new book on the the history of the Almanac described at this link
https://www.springer.com/gp/book/9783030436308
it might be available in libraries or maybe just the last chapter will do. The title is misleading. It is about the almanac, not cel nav in general. Also once the USNO website comes back on the air, maybe the end of summer, you can likely find articles there about these details of the computations.
From: Starpath, Seattle, WA
|
|
Arnold
|
posted August 15, 2020 11:51 AM
Thank you, will take a look on that.
Besides of this matters expressed, I found and received another, perhaps, source of information and that is Norie's Nautical Tables ISBN 9781786790385.
When I was taught at school, I really never ever heard of haversines, also not even during my working with other people. Anyway, I just found it now, and perhaps does not give the accuracy of a mathematical formula of today, I still recognize the power of simplicity of handling the numbers.
Anyway, the Norie's Nautical Tables give also haversines explained (although less digits), it is giving Sun's HP. (as for as I know the only place). I read it only once mentioned in Bowditch, but it is expressed more in detail. Ok, for that last 0.1 correction, but could be needed in lunar calculations.
From: Grashoff
|
|
Arnold
|
posted August 15, 2020 01:20 PM
Yes, I found it. Thank you for sharing this information! I will dive into it in more detail to learn from. ♥
From: Grashoff
|
|
Arnold
|
posted August 15, 2020 05:03 PM
As the input of the Almanac Data is of concern for the accuracy of the output of a calculation involving lunar distance; independently generated by any way of calculating. Just in line with the review or description of the calculations made by J.C. Hannyngton in 1876, it is noted by me that their used Almanac Data is having the format [degrees;minutes;seconds] or [000⁰;00';00.0"]. This is to note; that it is on its own more accurate than today used [000⁰;00.0']. Perhaps an idea to implement in future software updates?
Anyway, I do recognize by the way of calculating with Iterations within StarPilot, the most accurate output, based on measurements taken at a known exact location, and at an exact timestap, resulting in an calculated time error, as found as true error. With the iteration proces continuing until the remaining ΔLD is less than 0.1', giving the most smallest ΔError in Time. Implementing higher degree of accuracy would hopefully even end up in even more accurate output?
From: Grashoff
|
|
|
