The following build error occurred in Mac OS:
Compiling altazsearch.cpp
clang: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]
Added options to explicitly perform mixed C/C++ programming.
See the following discussion for context:
https://github.com/cosinekitty/astronomy/discussions/308
Added a demo program that shows how to search for when
a body enters a window defined in terms of an observer's
horizontal frame of reference, given a range of altitudes
and a range of azimuths.
The newer version of cppcheck reported that I was assigning
a value to a variable that was never used before another
assignment occurred. Fixed this to eliminate the warning.
The star database changed again, which causes my hash check
to fail. This time I locked on to the specific commit of the
file, so my build process won't break if it is changed again.
The camera demos all have a bug where I was calculating
the angle of the sunlit side of the Moon incorrectly.
The arguments to atan2 were backwards.
Added test data for Florida, New Zealand, and Canada
that are backed up by photographic evidence and
my first-hand observation.
The star database file hygdata_v3.csv has been updated.
Updated the expected checksum for it.
Reworked the downloader to check for checksum disagreement.
If checksum doesn't match, delete the file and download,
then try the checksum again.
This change will automatically fix obsolete files that have already
been downloaded on contributor's development systems.
Now that we use Python type hints, I discovered that
Python 3.11.2 includes the placeholder type `Any`
in the metadata reflected by `importlib`.
In order to generate consistent documentation with
older versions of Python, I exclude `Any` if it is present.
This change affects only the documentation and has
no effect on the Astronomy Engine package itself.
Because I plan on adding metersAboveGround as a parameter
that defaults to 0.0 in the other languages, and I want
the language implementations to be reasonably consistent,
I moved the metersAboveGround parameter to the end of
the parameter list for the C version of SearchRiseSetEx.
I realized I had to rework the RiseSetEx function so that
it accepts a height above ground level, rather than a generic
altitude angle correction, because atmospheric effects are
important both for the horizon dip angle and for the amount
of refraction at ground level.
The atmosphere calculations were interesting enough that
I made them public as a new function Astronomy_Atmosphere.
This returns the idealized temperature, pressure, and relative
density of air at the given elevation above/below sea level.
This is the first step toward calculating body rise/set times
for an observer that is significantly above the ground.
It figures out the angular correction of the horizon
using both parallax and refractive correction of a light
ray from the horizon to the observer's eye.
Enhanced the Time class to correctly calculate calendar
dates for the year range -999999 to +999999.
Made unit tests in C, C#, and Kotlin all exercise
the full year range, for February 28 and March 1 in each year,
to make sure we cover before and after each potential leap day.
The C functions for calculating calendar dates used the
type `long` to perform calculations that require 64-bit
integers. However, in some C compilers, `long` is still
32 bits. This caused a failure in Windows for extreme
year values. So I now use the type `int64_t` to explicitly
require a 64-bit integer.
In many of my Windows batch files, I used the following
construct to detect failures:
do_something
if errorlevel 1 (
echo.An error occurred in do_something
exit /b 1
)
I discovered that it is possible for a Windows program
to exit with a negative integer error code.
This causes the above construct to miss the failure
and the batch file blithely continues.
So I have replaced that construct with
do_something || (
echo.An error occurred in do_something
exit /b 1
)
This way, if the command exits with any nonzero error,
we correctly detect it as a failure.
Applying the same recent fixes to C and C# to the Python code.
I'm also changing my philosophy of representing times.
From now on, they will be truncated to the floor millisecond,
not rounded to the nearest millisecond. This means we don't reach
another calendar date until we have had 60 full seconds after
the last minute. Otherwise there is too much nasty logic for
rounding up calendar dates. I will follow suit across all languages.
Fixed problems converting AstroTime to calendar dates and back.
Also expose struct CalendarDateTime to outside callers,
for convenience dealing with Gregorian calendar dates.
With more rigorous testing, I discovered more bugs
in the C functions for converting calendar dates
to times and vice versa.
Astronomy_UtcFromTime():
When the year went before -4714, the value of the variable
`djd` went negative, causing the typecast `(long)djd` to
round toward zero instead of taking the true floor.
Changed this to `(long)floor(djd)`.
Astronomy_MakeTime():
Reworked the logic so that none of the integer divisions
involve negative values over the year range -999999..+999999.
Addressed limitations of the logic I copied from NOVAS cal_date().
Its formulas did not work for years much before -12000 due to
integer division going negative. I figured out how to make the
formulas work for plus or minus 1 million years from the present era.
Implemented and added tests for the following methods:
AstroTime.TryParse()
AstroVector.TryParse()
I still need to implement StateVector.TryParse().
Fixed a bug in CalendarDateTime: the NOVAS cal_date
function worked well, except when years go below
somewhere near -12000. Then the formulas start making
negative numbers, which messes up the calculation
of the month and day.
So to fix this, I figured out that any multiple of
400 years added to any calendar date gives the exact
same calendar date. And 400 years always has the exact
same number of days in it: 146097.
Because one million years = 400 * 2500 years, I can
add 2500*146097 days at the front of the formula
and subtract 1000000 years at the back, and everything
works for the entire range of years plus or minus
one million years from the present.
Because my date format allows for no more than a 6-digit
decimal year, this is perfectly adequate.
Replace the abstract class with a parameter of function type.
This allows the documentation to fully explain how to use
`CorrectLightTravel` without having to look at the code.
