Fascinatingly, I still have discrepancies between a well-tested
high-precision math package 'mpmath' and math.sin, math.cos.
This happens running on my own hardware, which makes me think
there is something wrong with my system, not GitHub's backend.
Here is output comparing mpmath.sin with math.sin,
and mpmath.cos with math.cos.
PY Trigonometry: maxdiff=3.32359e-12, worst angle = 719.9 degrees: PASS
I'm going to commit this to try it on other hardware/OS combinations.
These are replacement trig functions that should work the
same across the platforms I test on. They are much slower
than math.sin and math.cos, but unfortunately I'm having
problems with results that are accurate only to 12 digits,
not the expected 15.
It looks like values returned by VsopModel() are inconsistent
running the same code on different hardware.
On my system, Python and C are producing nearly identical results,
but in GitHub Actions, I'm getting errors on the order of 1e-12.
I'm beginning a series of commits in a separate branch where
I can hack the code to debug my code where it fails, which is
unfortunately only on GitHub Actions.
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.
