It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
Added Kotlin and Java demos for calculating Jupiter's moons.
Illustrates correcting for light travel time.
I added named getters for the 4 moons in `JupiterMoonsInfo`,
because in Java it was really ugly to write
`jm.getMoon()[0]`, etc.
I had to add a new method `Vector.withTime` to work around
the error checking that throws an exception if vectors
from different times are added.
Also made Kotlin constants public:
MINUTES_PER_DAY
SECONDS_PER_DAY
MILLISECONDS_PER_DAY
Direct use of arrayOf can be a bit more efficient than calling map and toTypedArray.
It could be faster if JupiterMoonsInfo was holding a list but better to use direct
typed array initializer for more efficiency.
Used IntelliJ IDEA's linter to perform code cleanup.
There were unused variables, `var` that could be replaced with `val`,
and other minor code style issues.
While doing this, I also discovered that a lot of documentation
links were broken. The fix is to stop intenting the text after
a `@param`.
When documentation refers to a Body value, e.g. Body.Earth,
link to its information page. I'm not sure this is super helpful,
but it is an attempt to provide better linking.
Added more explanatory text about the SSB and EMB values.
I found that a blank line splits the extra text onto the
dedicated pages for SSB and EMB, while leaving the "brief"
description on the list of all Body enum values. That is nice.
Added functions:
searchPlanetApsis
nextPlanetApsis
I discovered that I had an unnecessary special relaxation
of apsis error tolerance for Pluto. It turns out that currently
0.1 degrees of orbital rotation is enough for all the planets.
Search for times when the Moon ascends or descends
through the ecliptic plane. These are called
ascending and descending nodes. Added the functions:
searchMoonNode
nextMoonNode
Also corrected comments in the unit tests that
incorrectly stated nodes occur when the ecliptic
longitude is zero. They should have said the
ecliptic latitude is zero.
The existing lunar libration functions in the
other languages (C, C#, Python, JavaScript) were
calculating the Moon's ecliptic latitude and longitude
in radians, not degrees as intended. They have been fixed.
Implemented the libration function for Kotlin.
Calculate the position and velocity of any
of the five Lagrange points for a pair of
Solar System bodies. Added the functions:
lagrangePoint
lagrangePointFast
Implemented the `illumination` function, which calculates
visual magnitude, illuminated phase angle/fraction, and
ring tilt for Saturn.
Implemented `searchPeakMagnitude` for finding when
Venus appears brightest in the sky.
This function calculates how easy it is to see a given planet
with respect to the Sun: how far apart they are in the sky,
and whether the planet is easier to see in the morning or evening.
This function is especially helpful for spotting Mercury,
but it works with any body.
Implemented searchRelativeLongitude, which finds
planetary conjunctions and oppositions.
Discovered I can make all languages' unit tests
more strict: 6.8 minute error tolerance instead of 15.
Fixed documentation mistake in C# function SearchRelativeLongitude:
the function cannot return null. It either finds a solution time
or throws an exception.
Simplified Kotlin unit tests: use a more compact pattern of
scanning space-delimited tokens in lines.
Added geoEmbState: calculates the geocentric
state vector of the Earth/Moon Barycenter (EMB).
Added baryState: calculates the barycentric
state vector of a body.
Unit tests now support parsing JPL Horizons
state vector text files.
The Kotlin version of Astronomy Engine was using Java
classes like `Date` and `GregorianCalendar`.
Reworked the code to use a completely self-contained
representation of calendar date/time, just like the C version does.
Now Astronomy Engine does not depend on anything outside of
the Kotlin standard library. This should allow us to use
Astronomy Engine for Kotlin Native apps, Web Assembly, etc.
Updated Java demo to use the new method Time.fromMillisecondsSince1970.
Added functions:
searchGlobalSolarEclipse
nextGlobalSolarEclipse
These functions find a solar eclipse that is visible
somewhere on the Earth. They report the time of the
eclipse, what kind it is (partial, annular, total),
and if annular/total, the geographic location where
the eclipse is greatest.
Added functions:
searchLunarEclipse
nextLunarEclipse
These allow searching for a series of consecutive
lunar eclipses, including penumbral, partial,
and total eclipses.
Added a few extra functions that will be used soon
to search for solar eclipses (global and local) and
transits of Mercury and Venus.
Renamed AstroTime to Time.
Renamed AstroVector to Vector.
For some reason this breaks the Java demo build.
I'm pushing the broken build anyway to see if
ebraminio can help me fix it.
Changed RotationMatrix.identity from a variable to a function.
I want to leave open the possibility of mutating matrices
in the future, for the sake of performance critical code.
That means it is a good idea to create a new matrix to avoid
unintended side effects.
Removed redundant function equatorFromVector.
It was the same as Vector.toEquatorial.
Moved nextMoonQuarter to be right after searchMoonQuarter.
Somehow other functions had ended up between them.
Simpler syntax for initializing SearchContextPeakAltitude.
Added `Observer.toStateVector` and `Observer.toVector` for converting
an observer's geographic location to position and velocity vectors
relative to the Earth's center.
Reworked the C unit test to output a text file that can be used
as reference, to make sure the Kotlin output matches.
For years before 1582 or years after 3668, the Seasons functions
were unable to find many equinoxes and/or solstices.
The problem was that over time, the Earth's axis precesses
enough that the calendar dates of these events drifts outside
the fixed search ranges I had provided for them.
I expanded the search ranges so all season changes can be found
for a much wider range of years, as verified by unit tests:
C/C++: -2000..9999
C#: 1..9999
JavaScript: -2000..9999
Python: 1..9999
Kotlin: 1..9999
Note: C#, Python, and Kotlin currently do not allow
years values below +1. In fact, I discovered we were not
noticing when an invalid year was passed into the Kotlin code.
I updated that code to throw an exception when the year does
not match what was expected. It is disturbing that the
GregorianCalendar class silently ignores invalid years!
Constricted the search tolerance from 1 second to 0.01
seconds for the seasons search, to ensure more consistent
behavior.
Fixed a bug in the Kotlin search() function's
quadratic interpolation that was causing the convergence
to be slower than it should have been.
Added Astronomy.searchAltitude, which enables more generic
searches for altitude events. The most common use for these
are finding civil, nautical, and astronomical twilight times.
Implemented the following Kotlin functions:
Astronomy.searchHourAngle
Astronomy.searchRiseSet
The Kotlin code can now search for rise/set
times for a given Earthbound observer for the
Sun, Moon, or any planet.
It can also search for times when a given body
reaches a desired hour angle. This has its own
value (for example, culmination), but is also
used to assist finding time brackets that bound
rise/set events.
Added special case exception type:
EarthNotAllowedException.
This follows the pattern of the other languages,
and makes diagnosing a violation easier than
the more generic InvalidBodyException.
Minor simplifications to the C# function
Astronomy.InternalSearchAltitude.
Improved the comments for the C# unit test
function RiseSetTest. They make the algorithm
easier to understand.
Added the following Kotlin functions:
equatorialToEcliptic
pairLongitude
moonPhase
searchMoonPhase
searchMoonQuarter
nextMoonQuarter
Discovered I could tighten the tolerance for the moon phase
unit tests from 120 seconds to 90 seconds and they still pass.
