In many of my Windows batch files, I used the following
construct to detect failures:
do_something
if errorlevel 1 (
echo.An error occurred in do_something
exit /b 1
)
I discovered that it is possible for a Windows program
to exit with a negative integer error code.
This causes the above construct to miss the failure
and the batch file blithely continues.
So I have replaced that construct with
do_something || (
echo.An error occurred in do_something
exit /b 1
)
This way, if the command exits with any nonzero error,
we correctly detect it as a failure.
While trying to convert ecliptic coordinates from mean
equinox of date to true equinox of date, I ran into excessive
overhead from the IAU2000B nutation model. The fact that it
uses 77 trigonometric terms made the calculations a lot slower.
https://apps.dtic.mil/sti/pdfs/AD1112517.pdf
Page 4 in the above document mentions a shorter series
“NOD version 2” that has 13 terms instead of 77 as used in IAU2000B.
I had not noticed NOD2 before, because it appears only in
the FORTRAN version of NOVAS 3.x, not the C version.
After reading the FORTRAN code, I realized NOD2 is the same
as IAU2000B, only it keeps the first 13 of 77 terms.
The terms are already arranged in descending order of
significance, so it is easy to truncate the series.
Based on this discovery, I realized I could achieve all of
the required accuracy needed for Astronomy Engine by
keeping only the first 5 terms of the nutation series.
This tremendously speeds up nutation calculations while
sacrificing only a couple of arcseconds of accuracy.
It also makes the minified JavaScript code smaller:
Before: 119500 bytes.
After: 116653 bytes.
So that's what I did here. Most of the work was updating
unit tests for accepting slightly different calculation
results.
The nutation formula change did trigger detection of a
lurking bug in the inverse_terra functions, which convert
a geocentric vector into latitude, longitude, and elevation
(i.e. an Observer object). The Newton's Method loop in
this function was not always converging, resulting in
an infinite loop. I fixed that by increasing the
convergence threshold and throwing an exception
if the loop iterates more than 10 times.
I also fixed a couple of bugs in the `demotest` scripts.
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.
The help pages for the Java and Kotlin demos mention
a Windows batch file `rundemo.bat`, but they did not exist.
I created them, so now the documentation is correct.
Three of the lunar eclipse demos (Python, Java, Kotlin)
provided a less than ideal example of efficient computation.
They were wasting a lunar eclipse search by calculating it
but not printing it. Now after printing exactly 10 lunar
eclipses, stop running immediately.
Added Java demo to search for rise/set/culmination
of the Sun and Moon.
Also added the missing entry for the Kotlin
rise/set/culmination demo that I had forgotten.
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
I also reworked how the Java and Kotlin demos
process errors in the command line arguments.
Using exceptions that are caught by main() rather
than directly exiting the process where the errors
are detected.
I found that it is possible to use the "||" operator
in Windows batch files, and it works the same as the
"||" operator in bash scripts.
This inspired me to rework the bash scripts and
Windows batch files for running the Java/Kotlin demo
tests to be much more compact using functions/subroutines.
The best part is, the new approach will make it much
easier to add more demo tests in the future.
Removed the "now" test from Java demos, because it
does not follow the same pattern as the other demos,
plus it is not really demonstrating astronomy calculations.
Starting working on the Positions.kt demo; but not finished yet.
We are having difficulty getting Kotlin code to build for
both JVM and Native. For now, the priority is to support JVM,
so I am turning off installation of the Kotlin Native compiler.
The Mac OS tests failed because the Kotlin Native
compiler created an unexpected directory:
demo/kotlin/native/moonphase.kexe.dSYM/
I fixed this by adding *.dSYM to .gitignore.
Also, the GitHub Action `fwilhe2/setup-kotlin@main`
defaults to an older version of the compiler.
I added an option to specify using version 1.6.20.
Nothing very interesting yet.
Just building a very basic Kotlin Native app
to make sure build and execute work on GitHub Actions,
on Linux and Mac OS. I will worry about Windows later.
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.
