It’s getting harder to find CI that can easily run 2.6 (without burning
CPU building it from source), so let’s just do it locally. Hopefully
I’ll remember to run it before each release.
Make low-accuracy results like those mentioned in astropy/astropy#10292
less likely by consistently asking for epoch-of-date coordinates every
time `apparent()` coordinates are generated. And add exactly such an
example to the docstring of the `radec()` call itself, since that is
where users are likely to look.
Instead of splitting every time scale into two floats, let’s keep only a
single master `whole` number and then a series of fractions, each that
when combined with the whole gives the time in a particular scale. This
saves memory, keeps the attribute list smaller, is conceptually simpler,
and avoids the problem I just encountered with wanting a high precision
two-float version of `ut1` — `ut1_1` or `ut11` would look confusing to
others reading the code, and given that the UT1 timescale at least
includes a number, folks reading `tt1` and `tt2` might have thought
those were different timescales instead of simply two parts of a single
number. So I will be using `whole` and `fraction` consistently in the
code from now on.
More work will be necessary to carry through the extra precision
everywhere, but this is a start that addresses the most visible
manifestation of the previously low precision.
This eliminates an awkward `+=` maneuver that was preventing me from
improving the internal representation of time objects. Hopefully this
is not one of those magic conveniences I come to deeply regret later.
The previous way it was written was great for displaying the error in
failing cases, but, it turns out, would error out for successful cases
when the test should pass (whoops).
Also made a few tweaks:
1. Switched to “start” and “end” for the two bounding times, to stay
consistent with the underlying `jplephem` library; otherwise it will
take more effort to read code as I switch between them.
2. Added “Ephemeris” to the exception name to make it more specific and
descriptive.
3. Used the name “mask” for the binary array to match NumPy terminology.
4. Also decided to return the SPK segment, in case the user wants to
more closely inspect exactly which ephemeris segment their program is
trying to use (in case it’s the wrong one).
Though I am loathe to introduce yet another dependency to Skyfield,
issue #317 would seem to require it unless I want to guide users through
updating their system certificates themselves, or want to introduce yet
more options and variations in the download routines. Alas that it
incurs 308k of disk, which most users will never benefit from since
their system certificates were working fine! But the simplicity of
giving all users the same experience seems at this point preferable.
And the extra disk space is just 1/200th of the cost of NumPy, right?
Users had no idea what it meant when they saw raw `ICRF` vectors created
in the examples for `separation_from()`, so let’s pivot to an example
that will be relevant: two normal observed positions.
Why did I think that people would want the maximum and minimum? Having
just printed this myself, I expected it to be the first and last value,
so I’m pivoting to that meaning instead.
Brandon Rhodes
Brady Burnsides
Jérôme Deuchnord
Erik Tollerud