cbcacc4b57
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.
JavaScript examples for Node.js
The source file
astronomy.js
works as a Node.js module. Download the file into your project directory.
Then in your own source file, do this:
const Astronomy = require('astronomy.js');
or install the package with npm i astronomy-engine and:
import { SearchMoonQuarter } from 'astronomy-engine';
There are no external dependencies!
Astronomy Engine is completely self-contained, and it always will be.
(By the way, you can use the same file astronomy.browser.js for
astronomy calculations inside the browser.)
Culmination
Finds when the Sun, Moon, and planets reach their highest position in the sky on a given date, as seen by an observer at a specified location on the Earth. Culmination is also the moment a body crosses the meridian, the imaginary semicircle in the sky that passes from due north on the horizon, through the zenith (straight up), and then toward due south on the horizon.
Horizon Intersection
This is a more advanced example. It shows how to use coordinate transforms to find where the ecliptic intersects with an observer's horizon at a given date and time.
Lunar Eclipse
Calculates details about the first 10 partial/total lunar eclipses after the given date and time.
Moon Phase Calculator
This example shows how to determine the Moon's current phase, and how to predict when the next few quarter phases will occur.
Positions
Calculates equatorial and horizontal coordinates of the Sun, Moon, and planets.
Rise/Set
Shows how to calculate sunrise, sunset, moonrise, and moonset times.
Seasons
Calculates the equinoxes and solstices for a given calendar year.
API Reference
Complete documentation for all the functions and types available in the JavaScript version of Astronomy Engine.