I tried more distant objects like Jupiter ... Neptune.
This revealed that at increasing distances, the convergence
threshold in inverse_terra needed to increased also.
So now I use 1 AU as a baseline, and scale up linearly
for more distant objects.
Asking the latitude and longitude directly beneath
the Sun causes inverse_terra not to converge, because the
convergence increment `W` never got below 1.48e-8, but the
convergence limit was 1.0e-8. I increased the limit to 2.0e-8
in all programming language versions.
I'm hoping that is a big enough tolerance for all cases now,
but I will do more testing to see if further fixes are required
for even more distant bodies than the Sun.
Include TypeScript type definitions in the exported files.
This might be a fix for #294, but I'm not sure.
The only real way to test is to publish on npm and see what happens!
On the Raspberry Pi 4, using latest versions of cppcheck
and pylint, a few more minor fixes were needed for eliminating
warnings.
Also had to soften a tolerance for the Kotlin unit tests.
Applying the same recent fixes to C and C# to the Python code.
I'm also changing my philosophy of representing times.
From now on, they will be truncated to the floor millisecond,
not rounded to the nearest millisecond. This means we don't reach
another calendar date until we have had 60 full seconds after
the last minute. Otherwise there is too much nasty logic for
rounding up calendar dates. I will follow suit across all languages.
The generated code for the Pluto state table in Python
now uses a class `_pstate` for better type checking.
It also makes the code easier to understand.
Moved class _TerseVector higher in the source file to
reduce the need for quoted forward type declarations.
I added the mypy option `--disallow-untyped-defs` to fail
any function lacking complete type hints.
Then I fixed all the resulting errors.
I ended up changing the Python code generator to create
some tuple types instead of list, because it is possible
to write stricter type checks that way. This was in
the Pluto and Jupiter Moon tables.
I still should come back and do the same thing for the VSOP tables.
The type checking revealed a couple of places where I wasn't
checking for a search failure. I fixed those too.
Pylint discovered that I was raising Exception,
which was overly general. I didn't mean to do that;
it was supposed to be my custom exception type
astronomy.Error instead. So I fixed that case.
There were also some deprecated settings in the
pylint configuration file, so I fixed those too.
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.
I bootstrapped based on the pretty good optimizations that
codegen did for the Python version of the (now truncated)
IAU2000B nutation formula. I will do the same for the other
nutation formulas.
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.
