Before making these changes, I had the following discrepancies
between the calculations made by the different programming
language implementations of Astronomy Engine:
C vs C#: 5.55112e-17, worst line number = 6
C vs JS: 2.78533e-12, worst line number = 196936
C vs PY: 1.52767e-12, worst line number = 159834
Now the results are:
Diffing calculations: C vs C#
ctest(Diff): Maximum numeric difference = 5.55112e-17, worst line number = 5
Diffing calculations: C vs JS
ctest(Diff): Maximum numeric difference = 1.02318e-12, worst line number = 133677
Diffing calculations: C vs PY
ctest(Diff): Maximum numeric difference = 5.68434e-14, worst line number = 49066
Diffing calculations: JS vs PY
ctest(Diff): Maximum numeric difference = 1.02318e-12, worst line number = 133677
Here is how I did this:
1. Use new constants HOUR2RAD, RAD2HOUR that directly convert between radians and sidereal hours.
This reduces tiny roundoff errors in the conversions.
2. In VSOP longitude calculations, keep clamping the angular sum to
the range [-2pi, +2pi], to prevent it from accumulating thousands
of radians. This reduces the accumulated error in the final result
before it is fed into trig functions.
The remaining discrepancies are largely because of an "azimuth amplification" effect:
When converting equatorial coordinates to horizontal coordinates, an object near
the zenith (or nadir) has an azimuth that is highly sensitive to the input
equatorial coordinates. A tiny change in right ascension (RA) can cause a much
larger change in azimuth.
I tracked down the RA discrepancy, and it is due to a different behavior
of the atan2 function in C and JavaScript. There are cases where the least
significant decimal digit is off by 1, as if due to a difference of opinion
about rounding policy.
My best thought is to go back and have a more nuanced diffcalc that
applies less strict tests for azimuth values than the other calculated values.
It seems like every other computed quantity is less sensitive, because solar
system bodies tend to stay away from "poles" of other angular coordinate
systems: their ecliptic latitudes and equatorial declinations are usually
reasonably close to zero. Therefore, right ascensions and ecliptic longitudes
are usually insensitive to changes in the cartesian coordinates they
are calculated from.
Now there are constants for the mean radii of Jupiter's
four major moons available in the C, C#, Python, and JavaScript
versions of Astronomy Engine.
Clarified that these are all mean radii.
Fixed some lingering "//" comments in the C code
(I want to keep ANSI C code as portable as possible.)
Now callers can create time objects from either UT (UT1/UTC civil time)
or ephemeris/dynamical Terrestrial Time (TT). The new TT functions
numerically solve to find the UT that produces the given TT based
on the Delta-T value at that UT. This is always a very fast
numerical convergence, because TT and UT are almost perfectly
linear over brief time windows.
I am starting the process of implementing calculation
of Jupiter's four largest moons: Io, Europa, Ganymede, Callisto.
This commit just contains constant declarations for the
equatorial, polar, and volumetric mean radii of Jupiter.
The positions of the moons will be related to the center
of Jupiter and be expressed in Jupiter equatorial radius units,
so I felt it would be good to give users a way to convert to
kilometers, which can in turn be converted to AU.
Ported the ObserverVector function to C#, but it is not tested yet.
While doing that, I realized I needed a way to document newly public
constants DEG2RAD, RAD2DEG, and KM_PER_AU. This led to work
on the 'csdown' project that converts C# XML documentation
into Markdown format.
Then I realized a lot of code would be more elegant if
AstroVector had operator overloads for addition, subtraction,
and dot products.
This in turn required these operators to know which time value
to store in the AstroVector, which led to realizing that I
was sloppy in a lot of places and passed in null times.
So this whole commit contains a variety of unrelated topics,
which is something I don't usually do, but it felt
justified here while I'm in a refactoring mood.
Astronomy Engine used to use USNO historical and predictive tables,
along with linear interpolation, to calculate Delta-T values.
The problem with the USNO tables is, they did not work well outside
a few centuries around present day.
Later I replaced with Espenak & Meeus piecewise polynomials
that work over a much larger time span (thousands of years).
I just discovered there were still comments in the code referring
to the USNO models. I updated the ones I could find to reflect
the current truth about how the code works today.
This is technically a breaking change, but only for clients
that use the cartesian coordinates in an ecliptic coordinate
return type. Before now, the coordinates were just separate
floating-point members ex, ey, ez. Now they are a standard
vector type.
The purpose is to allow seamless interfacing with vector
rotation functions, and to be consistent with the equatorial
coordinate types.
Now that equatorial coordinates include both angles
and cartesian coordinates, there is no need for the
VectorFromEquator function. It has been removed
from all four supported languages.
The expression "VectorFromEquator(equ, time)" can be
replaced with "equ.vec" in any calling code.
This caused me to discover I had forgotten to finish
making the necessary changes to astronomy.ts for saving
the cartesian vector inside the EquatorialCoordinates class.
I also realized I had made a mistake in the documentation
for the y-coordinate of the vector: it is the June solstice;
there is no such thing as a September solstice!
Also fixed some mistakes in demo tests: if something failed,
I was printing out the wrong filename (camera.c instead of camera.cs).
Added a C# demo program camera.cs that works the same way
as the C demo program camera.c.
I realized I can speed up the C# demo tests by directly
running the executables after I build them, instead of using 'dotnet'.
Added 'vec' field to Equatorial class. I just realized I no longer need
the function VectorFromEquator(), because the vector is now available
as 'vec'. I will get rid of it in another commit.
Created new rotation matrix functions for the C# version.
IdentityMatrix creates a new instance of the 3x3 identity matrix
1 0 0
0 1 0
0 0 1
Pivot transforms a rotation matrix by pivoting it about
one of its coordinate axes by a specified angle.
Still need to port the C version of the "camera" demo.
Added global/local solar eclipse functions to topic indexes for
C#, JavaScript, and Python.
Revised wording "eclipse found may be" --> "eclipse may be".
Python:
- Added missing Attributes section in class GlobalSolarEclipseInfo.
- Added classes EclipseEvent, LocalSolarEclipseInfo.
- Added stub functions SearchLocalSolarEclipse, NextLocalSolarEclipse.
Can now calculate the heliocentric Solar System Barycenter (SSB)
and Earth/Moon Barycenter (EMB).
Changes made in C, C#, JavaScript and Python:
Added new body codes SSB, EMB.
Added support for calculating both in HelioVector functions.
Verified that all calculations match NOVAS.
Verified that all calculations match each other across languages.
More work on new functions for converting orientation systems.
Changed a few classes to structs for memory allocation efficiency.
Moved stuff around in astronomy.cs so the Astronomy class comes
last. This is helpful when I want to add new functions, so I
don't have to search for the end of the class.
Starting to work on rotation functions in C#.
Added class RotationMatrix.
Split precession() into precession() and precession_rot().
Fixed problem in csdown handling type double[3,3].
