NavList:

   

Reply

> *From: *Robert H. van Gent
> *Date: *2024 Feb 25, 20:24 +0000
>
> The Fliegel & Van Flandern (1968) algorithm, online here
>
>    https://dl.acm.org/doi/pdf/10.1145/364096.364097

Since the objective is to "determine the elapsed number of days between
any two given calendar dates" and no astronomical application is
mentioned, I wonder if the algorithm would have been simpler with some
other zero point such as 1 BC December 31.

To utilize the full span of some recent JPL ephemerides (which extend
into the past beyond the year -10000) you need a different algorithm
since the one by Fliegel and Vanflandern is invalid if JDN < 1.

The "rather elaborate logic" to account for the variable month lengths
can be the array [31, 28 ...]. Iterate through the array and sum the
elements to get the number of days in the months before this month. With
the array [31, 59 ...]. you avoid iteration. However, the former method
makes it's easy to use the same array to check for an illegal day of month.

Getting back to the 1968 letter, the use of I, J, K instead of the more
obvious Y, M, D takes advantage of the implicit variable type feature
(or defect) in Fortran. Variables that begin with the letters I, J ... N
are integers by default. They don't require a declaration. A variable
with any other first letter is a "real" (floating point) by default.

Implicit typing can lead to a nasty bug if you misspell a variable on
the left side of an assignment. A new variable is silently created and
your result stored there! Later Fortran versions allow the IMPLICIT NONE
statement to disable implicit typing.


> How (and why) these algorithms work is far from obvious but an
> alternative algorithm published by Robert G. Tantzen in 1963 and online here
>
>    https://dl.acm.org/doi/pdf/10.1145/366707.390020 (cf. algorithm 199)
>
> is much easier to understand.

Tantzen uses branching but neither iteration nor tables. (Twice says
"without tables.") The procedures are "valid for any valid Gregorian
calendar date." Does that mean they fail with proleptic dates (before 1582)?


> This algorithm was popularized in the astronomical literature by Jean
> Meeus in a 1977 paper in a Belgian astronomical journal, online here
>
>    https://ui.adsabs.harvard.edu/abs/1977C%26T....93..158M
>
> and in the various editions of his _Astronomical Formulae for
> Calculators_ (first English edition published in 1979).

Also see his "Astronomical Algorithms," where the algorithm is similar
but not identical. Unlike the preceding authors, Meeus provides for the
Julian calendar too. That's important in the investigation of historic
astronomical phenomena such as eclipses and occultations.


> A partial explanation of Tantzen's algorithm can be found in a 2003
> paper by Paul H. Kimpel, online here
>
>    https://www.digm.com/Resources/Gregory/Date-Manipulations-in-WFL.pdf

As Robert said, how (and why) these algorithms work is far from obvious.
I think something is wrong if a calendar algorithm requires that much
explanation. Clever but difficult to understand code may have been
necessary in the old days. But by 2003 we had enough computing power to
do it the right way with algorithms which are understandable at sight.

That was my goal with the SofaJpl "astronomical toolbox" DLL. Its Julian
date algorithms are a radical departure from the preceding works. The
source code (C# language) is available online, but the Julian date
computations are deeply buried. For a long time I have wanted to present
them separately. Thanks to Robert van Gent I have found the motivation.

--
Paul Hirose
sofajpl.com

   

Reply