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.
I forgot that Mac OS does not have sha256sum
installed by default. This caused the worldmap
demo test to fail, trying to confirm that I got
the output PNG image I expected.
The demo worldmap.cpp now also prints out the
geographic locations where the Sun/Moon appear
to be straight up (at the zenith) for the given time.
This illustrates that Astronomy_VectorObserver can
turn a geocentric vector into a location on the
Earth that is in the same direction from the Earth's
center that a given celestial body lies.
The worldmap.cpp demo was calculating each pixel's
observer location twice. Now it does so only once.
Added verification that the output PNG file is
exactly as expected, using a sha256 checksum.
The new demo worldmap.cpp generates a PNG image of
a Mercator projection of the Earth, showing color-coded
intensity of sunlight (yellow) and moonlight (blue).
This sample program shows how to efficiently calculate
horizontal altitudes of the Sun and Moon across many
different geographic locations, for a given observation time.
Backported fixes to the Seasons functions in
C, C#, Python, and JavaScript. They were failing
to find equinoxes and/or solstices for distant
year values.
Also brought over some other minor code cleanup.
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.
There were a few more places where C# code called
Search() but did not check for a search failure.
Throw InternalError exceptions if these ever occur,
because these particular searches should always succeed.
Added an InternalError class to explicitly indicate
that an exception occurs due to an internal assertion
failure inside Astronomy Engine. Any InternalError
should be considered a bug in Astronomy Engine, not
a bug in calling code.
Upon reviewing the code for searching moon phases,
I discovered that there was inconsistent behavior
in SearchMoonPhase. It was sometimes returning null,
other times throwing an exception. Because the caller
passes in `limitDays`, it makes sense to simply
return `null` in any case where the search fails.
This is to support callers that intentionally want
to find whether or not a moon phase occurs in a given
small window of time.
Updated internal callers of SearchMoonPhase to throw
an InternalError when they know they should always
find an event.
Internal function FindSeasonChange did not check to
make sure SearchSunLongitude succeeded. There is no
known case where this failure happens, but if it did,
a null AstroTime would have been stored in SeasonsInfo.
It is better to fail early with an explicit InternalError.
Other miscellaneous C# code cleanup.
In the Python code, I found a couple of `raise Error`
that needed to be changed to `raise InternalError`.
Dokka preserves leading whitespace in the text after
`@return` comments. This causes these fields to render
as preformatted text. Removed the leading whitespace so
this text is rendered as normal markdown.
Implemented the following related functions in Kotlin:
sunPosition
searchSunLongitude
seasons
C#: fail Astronomy.Seasons with an exception if any of the
equinox/solstice searches fail. If this ever happens, it is
an internal error. It should not be the burden of the caller
to check for nulls! Fixed mistake in documentation for
searchSunLongitude.
The previous commit added the NOVAS check for
Kotlin output to the bash script unit_test_kotlin,
which is executed in Linux and Mac OS.
This commit adds the same check to run.bat,
which is executed on Windows.
Instead of relying only on diffcalc to catch calculation
errors, call `generate check` before proceeding with other
unit tests. This way, breakage can be more quickly isolated
to the Kotlin code, if it is the culprit.
Implemented the low-level search function that will be used
to implement all the special-purpose search functions to come.
Added missing documentation to class NodeEventInfo members.
Minor cleanup in the C# function `Astronomy.Search`:
- removed an unused output parameter.
- deleted confusing sentence in documentation.
While working on the Kotlin implementation, I have
found a few documentation mistakes in the other language
implementations. These have been accumulating in the
`kotlin` branch. I migrated these changes back into
the released code for now, because I don't want to wait
until Kotlin is ready.
Starting to add the functions that create rotation
matrices to convert from one orientation to another.
Here are the ones implemented in this commit:
rotationEqjEcl
rotationEclEqj
rotationEqjEqd
Also starting to add missing documentation to
resolve Dokka warnings.
Defined consistent __repr__ methods for
Astronomy Engine Python classes.
Each string representation is reversible:
eval(repr(x)) -> x
The main goal is to facilitate interactive
debugging and experimentation for developers
working directly in the Python interpreter.
Fixed documentation mistakes in the following classes:
IlluminationInfo
LunarEclipseInfo
The GitHub Actions test comparing C and Kotlin
output failed for the Mac OS platform.
The test failed locally on my Windows 10 system
for the same reason.
Relaxed the constraints on both so they will pass again.
The `horizon` function was taking the sine and cosine
of the right ascension, but treating it as degrees.
This was wrong because right ascension is in sidereal hours.
Fix: multiply hours by 15 to get degrees.
Keeping the unit test that confirmed this bug.
Added comparison of C and Kotlin output to `diffcalc`
and `diffcalc.bat`. This test now passes on Linux.
This is a big milestone!
The function getPlutoSegment had a bug simulating gravity
in the forward direction. It was creating an array `seg`
that was one item too long: 202 instead of 201 elements.
This caused states from inconsistent time steps to be mixed.
I discovered this via the `diffcalc` script.
I added a new unit test that quickly reproduced this issue.
This was helpful for debugging and finding the problem.
I'm keeping the new unit test, in case it helps detect
breakage in the future.
