Fixed problems converting AstroTime to calendar dates and back.
Also expose struct CalendarDateTime to outside callers,
for convenience dealing with Gregorian calendar dates.
More work standardizing the nomenclature of the
orientation systems across all language documents.
Added C functions to calculate rotation matrices
for EQJ/ECT and ECT/EQJ.
Define ECT = True Ecliptic of Date in the documentation.
I will soon convert the Ecliptic() functions to return ECT instead of
ECL, but I will retain ECL support via rotation matrix functions.
Added EclipticGeoMoon as output to the temp/*_check.txt files as 'm' lines.
This ensures that all the languages calculate nearly identical values.
Optimized EclipticGeoMoon a little more by eliminating a redundant
call to mean_obliq.
The documentation for SearchRiseSet and SearchAltitude needed
clarification about refraction and the part of the body solved
for (center versus limb). The JavaScript version was especially
lacking compared to documentation for the other languages.
Also documented SearchAltitude's limitations; it does not
work at or near maximum/minimum altitude.
Mention that user-defined stars are allowed for
SearchRiseSet, SearchAltitude, and SearchHourAngle.
Fixed a couple places where the Kotlin documentation had
broken links to other functions.
I had a copy-n-paste typo in the `dec` parameters
for all of the DefineStar functions. Fixed it.
The TypeScript version of HelioState did not handle
user-defined stars. Added support there.
Because we instantly know the heliocentric
distance of a user-defined star, there is no
need to convert it into a vector and then take
the length of the vector.
All of the HelioDistance functions now return
the distance directly, as an optimization.
Also, I decided it didn't make sense to have a
default definition for user-defined stars.
If the caller doesn't define a star, it should
be treated as an invalid body.
This is a whole new algorithm that efficiently finds
all rise/set events, even near the poles.
It uses a recursive bisection search that limits
recursion depth by knowing the maximum possible
|da/dt| = change in altitude with respect to time.
The .NET type System.DateTime is limited to the years 0000..9999.
The Astronomy Engine type AstroTime was using System.DateTime to
convert a (year, month, day, hour, minute, second) tuple into a
fractional day value. This caused an exception for years outside
the supported range 0000..9999.
I ported the NOVAS C 3.1 functions julian_date and cal_date to C#,
and removed the dependence on System.DateTime.
Now we can create AstroTime for a much wider range of year values.
Allow converting AstroTime to string for years before 0 and after 9999.
The following C# functions now support searching
in forward or reverse chronological order:
Astronomy.SearchRiseSet
Astronomy.SearchAltitude
Astronomy.SearchHourAngle
Also fixed places where I forgot to update documentation
for the corresponding changes to the C code.
Enhanced the C# function Astronomy.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.
Provide shield.io badges for pypi, npm, and nuget packages.
On the main README page, moved the badges into the supported
languages grid.
Added link and badge on each language documentation page.
The csdown utility was not generating the correct ID
string that matched the C# compiler's XML output file
when a parameter was of a generic type.
Because the GravitySimulator constructor has a bodyStates
parameter of type IEnumerable<StateVector>, we were not
generating the correct method ID string:
CosineKitty.GravitySimulator.#ctor(CosineKitty.Body,CosineKitty.AstroTime,System.Collections.Generic.IEnumerable{CosineKitty.StateVector})
This caused the constructor to not show up in the markdown docs.
I fixed this and now the constructor is documented.
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.
The C# markdown generator (csdown) was not generating
documentation about constructors. This was especially
needed for the new GravitySimulator class.
Also added markdown for properties like
GravitySimulator.NumSmallBodies
GravitySimulator.Time
Made several constructors internal so they don't
need to be listed in the markdown docs.
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 C# demos:
moonphase.cs ==> MoonQuartersAfter
lunar_eclipse.cs ==> LunarEclipsesAfter
Fixed an issue in the C# Markdown generator
so that it can now handle generic types like
`IEnumerable<MoonQuarterInfo>`.
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.
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.
