I wrote a quick Python program based on an original reference
paper defining the galactic orientation system.
It generates a rotation matrix from first principles
that matches one inside the NOVAS function equ2gal(),
within the expected 2.3 arcsecond difference between
ICRS and EQJ.
NOVAS equ2gal matrix:
double ag[3][3] = {
{-0.0548755604, +0.4941094279, -0.8676661490},
{-0.8734370902, -0.4448296300, -0.1980763734},
{-0.4838350155, +0.7469822445, +0.4559837762}};
This program's generated matrix:
B1950 = 1949-12-31T22:09:21.346Z
-0.0548624779711344 0.4941095946388765 -0.8676668813529025
-0.8734572784246782 -0.4447938112296831 -0.1980677870294097
-0.4838000529948520 0.7470034631630423 0.4559861124470794
Also added some JPL Horizons test data to confirm
conversion back and forth between EQJ and GAL, which
I will use for future tests.
Starting work on support for galatic coordinates.
Generate a test data file using calculations made
by the NOVAS function equ2gal(). Later I will use
this data to verify the conversion functions I
write for Astronomy Engine.
When I merged from calendar2 branch into master branch,
I forgot to run the unit tests locally and commit the
code generation changes it caused. This has been fixed.
The calendar enumerator demo now includes inferior and superior
conjunctions of the inner planets (Mercury and Venus), along
with the conjunctions and oppositions of the outer planets
(Mars ... Pluto).
Once a collator has been created, and a caller starts
enumerating events, it does not make sense to be able to add
another enumerator to the collator. So I removed EventCollator.Append().
It was just opening up the possibility of bugs for no good reason.
Client code should decide up front what kind of events it wants
to enumerate and provide a complete list of enumerators.
Then it may use FindFirst/FindNext as many times as it wants
and everything will just work.
Added MoonQuarterEnumerator, which finds new moon, first quarter,
full moon, and third quarter events.
Changed the calendar start date to May 2021, so it is
more relevant to the time I'm testing it.
This is an example of how multiple enumerators can be combined
into an EventCollator. The collator does the minimum amount
of work to keep searching for one event at a time, while always
emitting them in chronological order.
Decreased the minified browser code from 94918 bytes to 94221 bytes.
Did this by using a more efficient encoding of the IAU2000B nutation model:
instead of making {nals:[_], cls:[_]} objects, make lists of lists [[_], [_]].
Ran 'npm audit fix' to resolve some security vulnerabilities
in the developer tools in the 'generate' directory.
None of the vulnerabilities affect the npm package
astronomy-engine, because it has no external dependencies.
The risk was only to developers who run the code generation
tools, not end users. Even then, the risk is minimal because
these tools run with well-defined inputs that are not subject
to external tampering.
Finished the script demos/python/lunar_angles.py
that shows how to search for times when the Moon and other
solar system bodies reach apparent ecliptic longitude separations
as seen from the Earth.
This is also a good demo of how to perform a custom search
for events using Astronomy Engine. This is the same technique
used internally by Astronomy Engine to search for lunar phases,
eclipses, solstices, etc.
Started work on a Python demo for finding when the moon
reaches relative longitudes with other solar system bodies
that are multiples of 30 degrees. It is not finished yet,
but getting close.
Added operator overloads for the Python Time class so
that times can be compared against each other.
This makes it easier to sort a list of times, for example.
This script will help me figure out how to tune the search algorithm
I'm about to write for searching for times that a pair of bodies
reach a given relative apparent ecliptic longitude.
This function is a generalization of Astronomy_LongitudeFromSun,
which it replaces. It calculates the relative ecliptic longitude of one body
with respect to another body, as seen from the Earth.
After implementing the same function in C#, JavaScript,
and Python, I will come back and create a generalized
search algorithm to find the next time two bodies are
at a given apparent relative longitude. Even though this
is a generalization of SearchRelativeLongitude, I will have
to figure out a more general way of tuning the search.
The test build failed because diffcalc reported a small
discrepancy between the C and C# output.
So I made the threshold more lenient for now.
I want to come back later and figure out if I can get back
to exact agreement between C and C# code.
Told wget not to output rediculous progress bar stuff
that eats thousands of lines of log output.
I ran into a problem recently that was confusing to debug.
It turned out that I was calling fgets() providing a line buffer
that was not long enough for all of the lines in the input file.
This caused the unread portion of the long line to appear as if
it were the beginning of another line, failing the test in
a weird way.
So I replaced all calls to fgets() in ctest.c with a new
wrapper function ReadLine(). It checks for this issue
and immediately aborts with a helpful diagnostic.
It turns out different Node.js versions do math differently,
which caused a Travis CI build failure.
Scale topocentric distance the same way I scale heliocentric distance.
Adjusted diffcalc bash script and diffcalc.bat Windows batch file accordingly.
The differ now prints the final "score" so I'm less likely to make
a mistake spotting the correct maximum difference.
Removed unused variable in ctest.c DiffLine(): maxdiff.
When comparing calculations of body vectors, scale
the size of the difference by the minimum orbital
radius (or typical radius in the case of the Solar
System Barycenter).
This concludes my investigations of discrepancies between
the various language calculations. I have done as much
as I can without implementing my own trig functions,
which is not worth the effort (or the loss of efficiency
in JavaScript).
Scaling the errors relative the measurement units reveals
that the discrepancies are reasonable for the 16-digit
precision one expects from 64-bit floating point numbers.
The worst case is C vs JavaScript, with a scaled error
of about 7.2e-15. I can live with that.
A given amount of error in an angle measured in
sidereal hours is 15 times more important than the
same numeric error in an angle measured in degrees.
Scale angular errors by the range of values they
could take on. Longitude-like angles in degrees
have a range of 360, while latitude-like angles
range over 180 degrees (-90 to +90).
Split out separate Windows batch file diffcalc.bat,
just like I already split out bash script diffcalc.
