When I load TOP2013.dat, I have to simulate regenerating the output
in order to find discrepancies and fix them.
This is a total hack, but it satisfies multiple goals:
1. Generate identical output as the loaded input.
2. Confirm that what we loaded is what we meant to load.
3. Allow saving modified/calculated models correctly.
I want to make sure I can load and save a TOP2013 data set perfectly
before proceeding with calculation, truncation, etc.
I'm really close, but there are occasional rounding problems
writing floating point numbers back to the file in the weird
format they use.
Adding infrastructure for loading TOP2013 models of planets
and calculating them. Will start with a unit test to verify
I'm calculating the formulas correctly.
I'm starting to work on a replacement for Pluto calculations that
are not bounded in time. I'm trying the TOP2013 model that calculates
elliptic parameters of the outer planets Jupiter..Pluto.
I needed to download the 24MB file TOP2013.dat.
I already had redundant download logic for two files, and this was a third.
So I eliminated the redundancy and generalized the download logic
in the new bash function Download.
Use much tighter pruning to figure out when a transit might be
possible, based on a smaller angle between the planet and Sun
at the moment of inferior conjunction.
Including aberration makes little difference in the transit calculations,
so I turned that off to be a little more efficient.
All the other languages have a lookup table that allows
any specific test to be run by name, or all tests to be run
using "all" as the name. Now the C# unit test does the same.
To be consistent, when calculating the geocentric position of the Sun,
we do need to correct for light travel time just like we would for any
other object. This reduces the maximum time error for predicting transits
from 25 minutes to 11 minutes.
Also had to disable aberration when calculating moon phases
(longitude from Sun) in order to keep a good fit with test data.
I had to modify norm.py to handle some oddities in the input data.
The error threshold (26 minutes) is still surprisingly large.
I want to investigate more before porting to the other 3 languages.
Does not pass unit test yet.
I had to rework norm.py because I misunderstood the data format.
The date given is not for the beginning of the transit, but
for the peak. This means the normalized data files need to
keep the start time, peak date/time, and finish time.
The unit test needs to adjust start time and finish time
to make sense with respect to the peak time, by adding/subtracting
a day as needed.
Wrote stub C functions for finding transits.
Updated html files containing Espenak test data for Mercury, Venus.
Updated norm.py to convert the html files to easy-to-use text files.
I was irked by how a seemingly passing unit test was not actually
doing anything because something of the form
if (diff > threshold) ...
was never firing when 'diff' was NaN. This made me paranoid
that other things could be broken. Added strategic checks
that values that are supposed to be numbers are indeed numbers.
Added global/local solar eclipse functions to topic indexes for
C#, JavaScript, and Python.
Revised wording "eclipse found may be" --> "eclipse may be".
Python:
- Added missing Attributes section in class GlobalSolarEclipseInfo.
- Added classes EclipseEvent, LocalSolarEclipseInfo.
- Added stub functions SearchLocalSolarEclipse, NextLocalSolarEclipse.
Now I can run any Python unit test by name, or specify 'all'
to run them all. This way I don't have to update scripts
every time I add a new Python unit test.
I like what I did to the JavaScript tests, where I no longer
need to update scripts when I add a new unit test.
So I have decided to do the same for the other languages,
starting with Python.
From now on, it will be simpler to add new JavaScript unit tests.
In most cases, it should no longer be necessary to update the
bash script unit_test_js or the batch file run.bat when new
JavaScript tests are added.
