In the unit tests for searching forward and backward
for moon phases, in addition to new moons, also test
first quarter, full moon, and third quarter.
Verify that forward and backward searches work for
100 start times between a single pair of consecutive events.
The following Python functions now support searching
in forward or reverse chronological order:
SearchRiseSet
SearchAltitude
SearchHourAngle
Made some minor performance improvements to the
other implementations: return sooner if we
go past time window.
Enhanced the Kotlin function searchMoonPhase
to allow searching forward in time when the `limitDays`
argument is positive, or backward in time when `limitDays`
is negative.
Added unit test "moon_reverse" to verify this new feature.
I encountered a build/test failure in the Kotlin
code due to the JVM running out of memory.
I configured gradle to allow using more memory:
1GB instead of the default 256MB.
Definition of vsopModel constant on Body enum items constructors
makes cyclic dependency with constants defined later in the code
and makes application crash when things are not initiated in the
correct order.
This fixes the issue by turning vsopModel into a property which
will have almost the same internal API for the rest of the code
and resolves crashes I'm getting when certain part of my app
is initiated sooner than usual.
Fixed 3 of the language implementations where I forgot
to make GeoVector return the observation time, not the
backdated time. This is important to preserve existing
behavior.
Corrected a mistake in the explanation of the
C function Astronomy_GravSimInit: the `bodyStates`
parameter is NOT barycentric -- it is relative to the
originBody parameter.
Python had improperly formatted documentation for
Time.FromTerrestrialTime parameter `tt`.
The Python markdown generator `pydown` did not
correctly handle links to compound symbols like
`#GravitySimulator.Update`. It also was trying
to link to `StateVector[]` instead of `StateVector`.
Removed unnecessary and unhelpful documentation
for C# internal class constructors. They do not appear
in the generated markdown documentation anyway.
Other minor wording revisions in the documentation.
Finished coding the Python version of the gravity simulator.
No unit tests have been written yet.
Cleaned up documentation in the other languages.
Made some functions static that did not need to be members.
Starting the C# version of class GravitySimulator.
There are no unit tests for it yet.
Added a fix to the C# markdown generator `csdown`
to show `void` as a function return type.
This is the first time I have had any function
in the C# version of Astronomy Engine that has
a void return type!
Fixed and improved documentation in the Kotlin version
of the gravity simulator. Fixed some comments too.
Added the following iterator functions that wrap
search/next pairs of functions:
globalSolarEclipsesAfter
localSolarEclipsesAfter
lunarApsidesAfter
lunarEclipsesAfter
moonNodesAfter
moonQuartersAfter
planetApsidesAfter
transitsAfter
I updated the following Kotlin demos:
MoonPhase.kt ==> moonQuartersAfter
LunarEclipse.kt ==> lunarEclipsesAfter
However, I have not yet figured out how to use these
functions in the corresponding Java demos.
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`.
In anticipation of releasing the Kotlin version,
I set the version numbers for the following to 2.1.0:
Kotlin
Node.js / npm
Python / pip
The intention is to keep matching releases of
Astronomy Engine at a common version number.
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.
I found that there were a bunch of lingering 'jvm'
tags in the generated markdown documentation.
Got rid of them with another change to format_kotlin_doc.py.
I missed a couple of places where I want to remove
private constructor calls from enum members.
Also, discard [name] and [ordinal] links while preserving
other properties that are intentionally exposed.
