This change affects internal unit testing only.
It does not affect developers who use Astronomy Engine.
Upgraded the HYG database used for verification of
constellation calculations to v 3.5.1.
See conversation at:
https://github.com/astronexus/HYG-Database/issues/21
When building Astronomy Engine for publication,
I was disabling generation of C documentation by default,
because I used to have issues getting deterministic output
in the CI tests (GitHub Actions). Now I have reason to believe
it will work reliably, so I am turning on C docs generation
by default.
If this fails the CI test, I will have to make the CI test
explicitly disable this step until I figure out how to fix it.
Otherwise (and preferably) the CI test will ensure that the
published C documentation is always up to date, and will fail
the build if there are any issues generating the docs.
I also had forgotten to enable installing dependencies for
my custom tool `hydrogen` in the Windows build. I added a fix
for that.
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.
The npm dependencies required are now
installed locally inside the generate folder.
Cleaned up the Astronomy object closure for TS
and kept it for the Browser bundle.
We will have some usage examples in the website.
I'm starting to work on a replacement for Pluto calculations that
are not bounded in time. I'm trying the TOP2013 model that calculates
elliptic parameters of the outer planets Jupiter..Pluto.
I needed to download the 24MB file TOP2013.dat.
I already had redundant download logic for two files, and this was a third.
So I eliminated the redundancy and generalized the download logic
in the new bash function Download.
I'm using the HYG star database v3 from:
https://github.com/astronexus/HYG-Database
I compare the star constellations it reports against
what I calculate from the star RA/DEC it lists.
When I try this against all stars in the database, I
find 25 disagreements about which constellation contains
the star. Another person found 3 disagreements. See:
https://github.com/astronexus/HYG-Database/issues/21
For now, I'm testing only the stars brighter than mag 4.890,
which eliminates all the disagreements, and still gets me
over 1000 test cases.
Also, now I'm verifying ephemeris file and star database
checksums whether or not they have just been downloaded.
The idea is to catch corruption or unexpected changes
each time I run the unit test.
Once again, existing tools are too complicated and don't do what I want.
It's actually easier to create my own tool for this special purpose.
I also want the documentation to be similar in style to the other languages.
There were 3 calls to _ter2cel(), each of which redundantly
called _sidereal_time, which results in 3 calculations of _e_tilt().
Reworked so there is only one call to _e_tilt().
Minor changes to support using cProfile, which is how I found this.
Force regeneration of planet models in Travis CI,
just to ensure that everything is still working.
This also will detect if the planet models change
unexpectedly on my development machines.
I found out by accident that OUTDIR environment variable tells msbuild
where to put executables. Taking advantage of this so I can control
where generate.exe and ctest.exe end up, instead of having to search for them.
