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.
I'm taking gcc 12.2 for a test drive today.
It reports a few warnings that slipped through earlier versions.
None of the warnings concern me for actual code safety,
but I went ahead and resolved them to keep the build clean.
Also provide a hook for a CPP environment variable to override
the C++ compiler to use, instead of forcing g++.
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.
Allow floating point values for seconds when initializing
an AstroTime from (year, month, ..., seconds).
AstroTime can now represent date/time to millisecond resolution.
Represent AstroTime strings in ISO 8601 format:
yyyy-mm-ddThh:mm:ss.sssZ
Minor docstring fixes.
Rename target file to 'astronomy.kt'.
Generate astronomy.py directly in the package directory.
I realized it doesn't make sense to generate it in the
parent directory and then copy it; just generate it where
it will end up anyway.
Updated documentation so people know they can just do
pip install astronomy-engine
to install Astronomy Engine in their Python project.
Removed the GitHub Actions status badge because it is redundant with
the checkmark/X indicator.
Now that private symbols are no longer exported, I had to
fix a couple of places where the unit tests still accessed them.
This is just a stub to get started. None of the
necessary macros have been implemented in the Kotlin
code generator. But at least I can start editing the
Kotlin template and generating code from it.
Starting work on support for galatic coordinates.
Generate a test data file using calculations made
by the NOVAS function equ2gal(). Later I will use
this data to verify the conversion functions I
write for Astronomy Engine.
I increased the error tolerance slightly for the Jupiter moons model.
This shrank the model tables significantly, giving me some more
breathing room to stay under 100K download size.
The optimizer makes the Jupiter moons series as short as
possible while keeping error within an acceptable limit.
This should help produce much smaller code, especially
for JavaScript where it really matters.
I want to experiment with truncating the L1.2 series to
sacrifice some accuracy for smaller generated code.
To that end, I implemented the ability to save the
Jupiter moons model after loading it. I added a 'jmopt'
command to the 'generate' program that will do this
optimization. For now, it just loads the model and
saves it back to a different file. Then the code generator
loads from the saved file instead of the original.
This commit verifies that everything is still working,
before I start truncating the series.
The goal is to provide both TypeScript and JavaScript to developers.
Will also provide a type definition file once I figure that out.
This is just the first pass through the code.
It builds and passes all the unit tests, with some minor changes
to the generated README.md.
I forgot that my build process automatically updates
copyright years when the current year changes.
My Travis CI unit tests verify that there are no local
changes after running all the tests.
That test failed because the update_copyrights.py changed
all the "2019-2020" to "2019-2021".
Now that I no longer need to generate Chebyshev models
or TOP2013 models for Pluto, I got rid of all the
code in generate.c that is no longer needed.
This whacked about 1000 lines of code.
The 'ctest pluto' command was testing against slightly wrong coordinates.
Added 'generate topcalc' command to print out exact TOP2013 values.
Used those values as the reference coordinates in 'ctest pluto'.
Sadly, this increased the measured error from 1.347e-02 AU to 1.412e-02 AU.
I was experimenting with an alternative way to calculate Pluto's position.
That idea didn't work out, but in the process, I did make some changes
I want to keep:
1. A typecast in generate/codegen.c that eliminates a build warning
in Windows (Visual Studio 2015).
2. Expanded generate/vsop/vsop.c to calculate both position and velocity
vectors. This was tricky to get working, and could come in handy.
I'm working on a Solar System gravity simulation.
I need very precise position and velocity data for the major
Solar System bodies. I want to write the simulator as a browser-
based animation, so I will code it in JavaScript. This JSON
generator is a bootstrap to provide the initial solar system
state, plus it allows testing how accurate the simulation
is as it unfolds. Plus it may be useful for any program that
can parse JSON easily.
The high-frequency wobble in the Pluto position function was bothering me.
Decreased the arcminute error threshold from 1.0 to 0.5, resulting
in a much larger model, but a lot less ripple:
547 [ 78 140 94 115 21 99]
Now the C version of Astronomy Engine is using the TOP2013 model
of Pluto instead of resampled Chebyshev polynomials.
I added temporary hacks to ignore differences for Pluto between
C output and output from Python, JavaScript, and C#.
I will remove these after all four languages are using TOP2013.
See the variable ToleratePlutoErrors in ctest.c.
ctest.c DiffLine function now understands that longitude-like
angles (right ascension and azimuth) can wrap around, and to tolerate
very small angular differences that happen to straddle the wraparound
value. I should have done this a long time ago, but it never caused
problems before now.
C PlanetApsis has a serious problem with Pluto that I didn't expect.
I need to investigate and understand this before porting to other
languages. For now, I hack around it using ToleratePlutoErrors.
This is another way to explore possible solutions in a random order
so that we don't keep going in the same directions each time.
Found a better solution:
219 [ 27 63 61 58 6 4]
winner: 0.998305 arcmin : 228 [ 37 63 60 58 6 4]
This script keeps running the ray search followed by the nudge search.
If it finds a better solution that the existing one, it replaces it.
Found the above solution after about 30 minutes.
I realized that I still was telling the code to assume the
time coordinate never gets more than 0.2 millennia away from J2000.
But in fact, it is getting 0.5 millennia away. Fixed that, and
immediately found a smaller model that works.
OptimizeTop: 255 terms [ 41 62 71 68 9 4]
Relax apparent angular error threshold from 0.4 to 1.0 arcminutes.
No longer compare TOP2013 to NOVAS while optimizing.
Use worst-case distance between Earth and Pluto:
Pluto radius from Sun, minus Earth aphelion distance.
Sample 503 points intead of 293.
Measure 2 full orbits before J2000 and 2 full orbits after J2000.
Statistics for output/8.top :
OptimizeTop: 268 terms [ 34 57 72 90 9 6]
Created functions for generating random unit vectors in
6-dimensional space. Will use this for trying different
directions along which to do a binary search between
truncated TOP2013 models that have acceptable error
and those which have unacceptable error. Will home in on
the smallest model that is within tolerable error.
Instead of calculating amplitudes and truncating based on them,
I realized when it comes right down to it, all I want to do
is truncate fewer or more terms from each formula until I find
a good compromise between size and accuracy. A term is either
included or excluded. Therefore the degree of freedom is discrete,
not continuous. There is no need to calculate a continuous value
to adjust something with only discrete options available.
