See issue #378 - suddenly newer versions of Python no longer
match C, C#, JavaScript, Kotlin, and Java in terms of calculations.
We only get about 12 decimal places of agreement instead of 15.
For now I'm going to relax the precision requirement so the unit
tests still run to completion. But I need to come back diagnose
where Python doesn't calculate things the same way as C.
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.
I propose to add some helpful information so users can easily create correct Date objects, as the JavaScript Date class can be confusing. This class contains a timestamp (the number of milliseconds since Jan 1st 1970 at midnight), which is timezone-agnostic, but the methods to interact with this number do involve timezones.
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!
Prevents crashes due to dereferencing NULL time pointers.
Passing in NULL for a `time` pointer will no longer cause
a crash in an Astronomy Engine function.
Wherever possible, a NULL time pointer will result in a
status code `ASTRO_INVALID_PARAMETER`.
`Astronomy_Horizon` has no way to report a status code,
so a null pointer causes it to return all NAN values.
Perhaps it should return a status code (considering for separate commit).
Thanks to [Steven Booth](https://github.com/sbooth) for suggesting this!
I suddenly realized today that I could eliminate lots of red wavy
lines in the source editor when working on generate/template/astronomy.*
files, by tweaking the $ASTRO_... tokens to look like comments.
For some reason, I didn't think of doing this before now.
I was motivated by the Go language support, where the tokens were
breaking `go fmt`.
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.
