NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
From: Ed Popko
Date: 2016 Aug 28, 12:41 -0700
The NavList and its people are so amazing.
I greatly appreciate the quick responses from Frank, Francis and Sean. I'm following links and rewriting now. Frank's comments about moon’s HP and SD are a big help. A nice thing about writing this particular program is you have a visual check right off. Just go outside, preset and look up. Both bodies are in the telescope field or they aren’t.
You have probably surmised from Frank's response that I like to program my calculator. I have had just about every one Hewlett Packard ever made and have had great fun programming CelNav algorithms. My last serious set was to program Frank's workshop 19th c lunars and time sight techniques.
For the past couple of years, I have used the HP50g. Mostly I write - utilities and small packages. Utilities include dumb, but useful, stuff like angle format conversions (all programs can use any form angle format), pLog for lunars, haversines, motion of body/observer etc. But also I write larger programs like Law of Cosines or recreations of 19th c procedures such as Thompson/Bowditch, Stark, Mendosa, etc.
Why write anything you ask? There is a ton of well written PC programs such as Stan Kline’s Celestial or Andres Ruiz’s great smartphone Navigational Algorithms set. And there are many more.
For me, there are three answers to this question: accessibility, learning style and utility.
There is nothing more accessible than picking up the calculator (only a smartphone is as good). It runs for a year on a set of batteries and can up/down load from PC where writing/storing programs is more convenient. Program language offers formatted prompts and menus, data checking, a huge library math functions and units conversions, RPN/infix notation (even mixed) and many more etc.
On learning style, programming forces you to be explicit, pay attention to conventions, check for errors or reasonablness (user inputs especially) and test for boarder conditions/signs or limits of algorithms. It's also a great way to internalize how things used to work in the old days such as proportional logs, haversines etc.
And last but not least - utility. You can use what you write! And there is nothing more satisfying than to pick up a 100 year old CelNav book and recreate one of it’s example and get the same answer (or find a error). For me, these recreations gave me a huge respect for the care and attention these old nav guys paid.
Skip this section if you do not know what RPN is…
A comment on HP calculators. Early HP users were in love with the efficiency and program terseness of Reverse Polish Notation (RPN). You either loved it or hated it. And for sure, you can find RPN algorithms that are so terse, you cannot decipher how or why they work (much less fix them if they don't). I hate this kind of programming style. Today, it's silly to sacrifice clarity and maintainability to squeeze a byte or two out of computer code. Today, you can mix RPN and infix notation in the same program; use your fav syntax! And you can include comments (my programs are typically 50-60% comments becaise I also include test cases in the comments) And all those memory and speed worries! Long past, ancient digital history. I have more than 60 programs (utilities/packages) in various folders by topic and I haven't even come close to filling a small SDK memory card. Speed? My longest and worst program probably takes less than 2 seconds, so who cares.
Sorry for this calculator tangent to the pre-set topic. … Now back to the NavList.
Thanks again for the suggestions, I'm on them now.
Ed Popko