NavList:

Re: Time and Longitude by Jupiter's moons
From: Frank Reed
Date: 2024 Dec 15, 21:26 -0800

A few days ago, I wrote:
"Yet every time I click on that app on the S&T website (linked above) or any of numerous other tools, they calculate it fresh for next month as if the running code is doing something new, useful, important... There's a bit of "lunacy" in this (intentional pun). We know how to code, but we cannot stop."

And David C, you replied:
"Is there a reference set of mathematical libraries that can be relied on to be correct? Libraries that are maintained by experts who stand by the accuracy of their data. If every programming language has a mathematical library how do we know which one(s) to use in a mission critical application? "

Sorry to take a few days answering. What I am suggesting is rather the opposite at its core, but yes, we use a product "maintained by experts". It's not a mathematical library, in the sense of formulae and computer code. It's an astronomical data library.

Consider this: I hand you a database (a plain text file is just fine, like in the attached image below) providing the GHA and the Dec of the Sun, Moon, and every navigation star and planet for every ten minutes of UT for the year 2025. You want to create an app that provides the GHA and Dec of any body for any instant (nearest tenth of a second maybe) for 2025. How would you go about it? An A.I. or an indentured servant (a "grad student") will do the actual grunt work of coding, but we need to design the system. Aaah, it's good to be the designer.. Would you build an app that recomputes the GHA and Dec from "first principles" working out orbits and and precession and all that until your newly crafted, intricate code mostly matches with the numbers in the database I have given you? Or would you just linearly interpolate between the values given in the database? Linear interpolation is about as simple as things get. It's what navigators have been doing for a few centuries using nautical almanacs. The advantage is near foolproof code, such as:

  Dec(t') = Dec(t0) + [Dec(t1)-Dec(t0)] · (t' - t0) / (t1 - t0).

The disadvantage is that your app needs to access that moderately large database of data (it's like carrying around a complete nautical almanac) which means you have to distribute that data with every copy of your app or you have to provide some means of downloading updates automatically on a regular basis and assume that downloading (basically internet access) is always available. Twenty-five years ago, those disadvantages still often overwhelmed the advantage of simple code. That's no longer true in nearly all scenarios. No one will even notice a few --or a few hundred-- extra megabytes of downloaded data today...

You asked about getting a "mathematical library" for these things. What I am saying, as outlined above, is that we can bypass the libraries of code that used to be important and instead get a "data library" from a trusted source. This is relatively easy now (in 2024), and the only real trick is to compress and trim down the database so that it has only the necessary precision required. We can get a complete JPL (NASA Jet Propulsion Laboratory) integration of major Solar System objects, for example, with a precision of a millionth of a second of arc, or something like that, and reduce it in size significantly by cutting the precision back to match the needs of celestial navigation (sample from JPL Horizons attached). That's really the only interesting coding project we need to worry about, and that's in the same nearly foolproof category as adopting linear interpolation for all the work.

I'm leaving out quite a few important issues (*) here because I'm trying to focus on the main idea: linear interpolation in a database of highest quality astronomical data from the best sources beats long algorithms for computing orbits and similar older approaches to the problem. Recomputing the positions of celestial objects from scratch every time is just asking for trouble.

Frank Reed

* important issues... like star coordinates!

File: