It looks like I have been running an unintended version of Python
from GitHub Actions. In Linux/Mac I used `python3`, and in Windows
I used `py`. It appears that I should be executing `python` in
all 3 operating systems.
This is an experiment to see if I can get everyone on the same page.
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.
Before now, the Python demos were tested in Linux and Mac.
Now they are tested in the Windows environment also.
This will be helpful for any contributors who may wish
to use Windows as a development platform for the Python
version of Astronomy Engine.
Use mypy to check all Python demo programs.
Updated the demos to pass type checking.
There were a couple of small mistakes found, so this was worth the effort.
The demo program ecliptic_of_date.py shows how to
calculate the true ecliptic of date (ECT) angular coordinates
of the Sun, Moon, and planets for an observer somewhere on the Earth.
It calculates the equatorial of date (EQD) coordinates, then uses
a rotation matrix to convert the vector to ECT, then converts
the vector to spherical coordinates: latitude, longitude, and distance.
This change affects internal unit testing only.
It does not affect developers who use Astronomy Engine.
Upgraded the HYG database used for verification of
constellation calculations to v 3.5.1.
See conversation at:
https://github.com/astronexus/HYG-Database/issues/21
This reverts commit a7e747c100.
This broke the GitHub Actions automated tests, because they
are using gcc 11 (which does not support level 3 fortification),
and they already predefine another fortification level.
I realize this would also hinder other contributors who
are not using gcc 12. At least I tried it once on my own
system and didn't find any problems, which is nice.
It was possible for certain starting times to have a search
failure in this demo, because it could place more than
one zero-crossing of the function in the same time interval.
So now we iterate over an interval of 10 days at a time
until we find the solution.
This demo shows how to search for the next time
the Moon reaches extreme ecliptic latitude or
extreme declination. In other words, it finds
when the Moon reaches the farthest north or south,
expressed in either ecliptic coordinates or equatorial
coordinates.
Both angles are measured using the Earth's equator of date.
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.
The following build error occurred in Mac OS:
Compiling altazsearch.cpp
clang: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]
Added options to explicitly perform mixed C/C++ programming.
See the following discussion for context:
https://github.com/cosinekitty/astronomy/discussions/308
Added a demo program that shows how to search for when
a body enters a window defined in terms of an observer's
horizontal frame of reference, given a range of altitudes
and a range of azimuths.
The camera demos all have a bug where I was calculating
the angle of the sunlit side of the Moon incorrectly.
The arguments to atan2 were backwards.
Added test data for Florida, New Zealand, and Canada
that are backed up by photographic evidence and
my first-hand observation.
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.
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.
Replace the abstract class with a parameter of function type.
This allows the documentation to fully explain how to use
`CorrectLightTravel` without having to look at the code.
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.
