During development, when I just want a quick build/test cycle,
I don't need to waste time regenerating documentation.
So I removed the dokka steps from the 'rebuild' scripts.
The dokka steps are still executed when running the full
build process before pushing to GitHub.
I didn't realize Dokka doesn't clean up its output directory
before writing documentation files. This caused stale documentation
to still exist from previous builds. The result was a failed
unit test because the generated documentation did not match
what was checked into git.
In general, I want to make sure that builds I run on my development
system exactly match what GitHub Actions does on its cloud platform.
So before running the `gradlew` build step, I delete the entire
directory source/kotlin/build. This directory is always absent
on GitHub Actions, which makes my local build better match the
remote build.
Merge a custom Markdown prefix with documentation
generated by dokka from Kotlin source code into
the published GitHub page. See the new script:
generate/kotlindoc/format_kotlin_doc.py
The result is not yet quite what I want, but it
is much better than nothing.
Things to improve:
The `object Astronomy` link should not be hidden
in the middle of the other types. It should be
expanded and promoted to the top level.
Converting between radians and degrees.
Clamping angles to a desired range of degrees.
Converting between vector, spherical, horizontal.
Refraction and inverse refraction.
Implemented most of the RotationMatrix functions.
Added unit tests for combining rotation matrices, using a
rotation matrix to rotate a vector, and pivoting a rotation
matrix around its axes.
Replaced AstroVector operator '*' with infix function 'dot',
because it removes ambiguity between vector dot products
and vector cross products.
Later I will add a 'cross' infix function too.
Corrected minor typo in documentation for Python, C, C#, JavaScript.
"trasnform" -> "transform"
Moved Astronomy object to bottom of source file.
This object is going to end up with a lot of functions,
so it's best to keep outer classes above it.
Removed unnecessary empty {} after classes.
Replace Array<Array<Double>> with Array<DoubleArray>.
This is more efficient because Array<Double> boxes the numbers
inside it, whereas DoubleArray is unboxed.
The main README.md now includes Kotlin as a supported
language.
Pivoted the table so languages are listed vertically
instead of horizontally, because this fits better on
a screen, especially using the GitHub mobile app.
There is a link to Kotlin demos, but there are no
demos implemented yet.
Likewise, there is a link to Kotlin documentation,
but the generated documentation is not stored in Git yet,
so there is no actual documentation generated from docstrings
in the code yet.
Allow floating point values for seconds when initializing
an AstroTime from (year, month, ..., seconds).
AstroTime can now represent date/time to millisecond resolution.
Represent AstroTime strings in ISO 8601 format:
yyyy-mm-ddThh:mm:ss.sssZ
Minor docstring fixes.
Rename target file to 'astronomy.kt'.
Generate astronomy.py directly in the package directory.
I realized it doesn't make sense to generate it in the
parent directory and then copy it; just generate it where
it will end up anyway.
Updated documentation so people know they can just do
pip install astronomy-engine
to install Astronomy Engine in their Python project.
Removed the GitHub Actions status badge because it is redundant with
the checkmark/X indicator.
Now that private symbols are no longer exported, I had to
fix a couple of places where the unit tests still accessed them.
I realized that the way I structured the pip package
in version 2.0.15 made the private symbols (those whose
names begin with an underscore) to be visible by the importer.
I reworked the package structure so this no longer happens.
This is now fixed in:
https://pypi.org/project/astronomy-engine/2.0.16/
The pip package was broken!
I violated ancient software development wisdom:
"If you haven't tested it, it doesn't work."
It is now working in:
https://pypi.org/project/astronomy-engine/2.0.15/
Version 2.0.15 of Astronomy Engine for Python (pip)
and Node.js (npm) add support for the new SiderealTime
function. This was previously an internal function,
but now it is exposed for outside callers.
Implemented the Body enum, with documentation strings
in comments. Reworked the Gradle build to generate
GitHub Flavored Markdown (gfm) instead of html.
There was already an internal function for calculating
Greenwich Apparent Sidereal Time (GAST). By request,
I have exposed this function for outside users.
Added a minimal unit test to verify the function is
callable and returns the correct result for one case.
This function is already exhaustively tested by unit
tests that verify other functions that already called
this function when it was internal, so minimal testing
is sufficient in this case.
The way I was publishing the Python package was annoying.
I found a better way to authenticate myself to pypi.org,
but I needed to test it. This required bumping the version
numbers of the packages. There is no difference between
2.0.12 and 2.0.13.
Added the following new functions to all 4 languages:
MassProduct: find the GM product for all Solar System bodies.
LagrangePoint: calculate L1..L5 state vectors for a pair of bodies.
LagrangePointFast: calculate L1..L5 state vectors given
state vectors and GM products of a pair of bodies.
In languages that support it, using hypot(x,y) is a little
easier to read than sqrt(x*x + y*y). Some documentation
(e.g. the man page for the C function) leads me to believe
hypot might also be better behaved than sqrt in some cases.
The JavaScript Math.hypot() is especially nice because it works
for any number of dimensions, so I can use it in 2D and 3D cases.
C only allows 2D usage, as does Python 3.7. Python 3.8 added
support for any number of dimensions, but I don't want to break
compatibility with Python 3.7 just yet. Therefore, in C and Python,
I am only using hypot for 2D cases.
C# does not appear to have any kind of hypot function,
so no changes were made to the C# code.
Thanks to https://github.com/ebraminio for this suggestion.
There is no function double.IsFinite() in .NET Framework.
Reworked the sanity check in Astronomy.Pivot so the C# code
builds in these older .NET platforms.
My custom Markdown documentation generator for C had
a bug when emitting the listing of a #define.
It is not valid to try to hyperlink to other symbols,
because the Markdown syntax gets listed literally inside
the context of a C code block.
In most cases, people calculating Lagrange points will just
want to pass in the bodies and not have to worry about calculating
their state vectors and masses.
Renamed Astronomy_LagrangePoint to Astronomy_LagrangePointFast.
Added new function Astronomy_LagrangePoint that accepts body enum
values instead of state vectors and masses. It knows to optimize
the precision of the calculation by calling GeoMoonState for the
Earth/Moon case.
It is conceptually simpler to take cross products to
generate 3 coordinate axes (essentially a rotation matrix)
that represent radial, tangential, and normal directions
with respect to the major and minor bodies.
Now correctly calculating L4 and L5 positions, but
there is a large error in their velocity vectors.
Refactored ctest.c LagrangeTest() to be a lot easier
to understand and modify. A new function VerifyStateLagrange()
allows passing test parameters in a more function-oriented way.
Confirmed that L4 and L5 always lie in the same plane with
the position vector and velocity vector.
