In the unit tests for searching forward and backward
for moon phases, in addition to new moons, also test
first quarter, full moon, and third quarter.
Verify that forward and backward searches work for
100 start times between a single pair of consecutive events.
In the unit tests for searching forward and backward
for moon phases, in addition to new moons, also test
first quarter, full moon, and third quarter.
Verify that forward and backward searches work for
100 start times between a single pair of consecutive events.
In the unit tests for searching forward and backward
for moon phases, in addition to new moons, also test
first quarter, full moon, and third quarter.
Verify that forward and backward searches work for
100 start times between a single pair of consecutive events.
In the unit tests for searching forward and backward
for moon phases, in addition to new moons, also test
first quarter, full moon, and third quarter.
Verify that forward and backward searches work for
100 start times between a single pair of consecutive events.
In the unit tests for searching forward and backward
for moon phases, in addition to new moons, also test
first quarter, full moon, and third quarter.
Verify that forward and backward searches work for
100 start times between a single pair of consecutive events.
The following Python functions now support searching
in forward or reverse chronological order:
SearchRiseSet
SearchAltitude
SearchHourAngle
Made some minor performance improvements to the
other implementations: return sooner if we
go past time window.
The following C# functions now support searching
in forward or reverse chronological order:
Astronomy.SearchRiseSet
Astronomy.SearchAltitude
Astronomy.SearchHourAngle
Also fixed places where I forgot to update documentation
for the corresponding changes to the C code.
The following C functions now support searching
in forward or reverse chronological order:
Astronomy_SearchRiseSet
Astronomy_SearchAltitude
Astronomy_SearchHourAngleEx
The function Astronomy_SearchHourAngleEx replaces
Astronomy_SearchHourAngle, adding a new `direction` parameter.
A #define for Astronomy_SearchHourAngle preserves backward
compatibility for older code.
Implementation notes:
Astronomy_SearchRiseSet and Astronomy_SearchAltitude used
to call a private function InternalSearchAltitude.
That function has been split into two functions:
BackwardSearchAltitude and ForwardSearchAltitude,
for searching both directions in time.
Fixed a bug where it was possible to report a successful
altitude event that went outside the time limit specified
by `limitDays`.
The quadratic interpolator used by `Search` was returning
an unused output: `x`. Search does not need this dimensionless
value; it only cares about the time solution `t` and the slope
of the function at `t`. Removed `x` from the return value
to make slightly smaller/faster code.
Enhanced the Kotlin function searchMoonPhase
to allow searching forward in time when the `limitDays`
argument is positive, or backward in time when `limitDays`
is negative.
Added unit test "moon_reverse" to verify this new feature.
Enhanced the Python function SearchMoonPhase
to allow searching forward in time when the `limitDays`
argument is positive, or backward in time when `limitDays`
is negative.
Added unit test "moon_reverse" to verify this new feature.
Enhanced the JavaScript function Astronomy.SearchMoonPhase
to allow searching forward in time when the `limitDays`
argument is positive, or backward in time when `limitDays`
is negative.
Added unit test "moon_reverse" to verify this new feature.
Enhanced the C# function Astronomy.SearchMoonPhase
to allow searching forward in time when the `limitDays`
argument is positive, or backward in time when `limitDays`
is negative.
Added unit test "moon_reverse" to verify this new feature.
Enhanced the C function Astronomy_SearchMoonPhase
to allow searching forward in time when the `limitDays`
argument is positive, or backward in time when `limitDays`
is negative.
Added unit test "moon_reverse" to verify this new feature.
The C version of Astronomy Engine does not work correctly
when gcc "fast math" optimizations are enabled.
The problem is that Astronomy Engine uses NAN values to
represent invalid/uninitialized floating point numbers.
The -Ofast option breaks the ability of the runtime to
check for NAN values, resulting in multiple failures
and incorrect behaviors at runtime.
Added a compile-time check for the __FAST_MATH__ preprocessor
symbol, which gcc defines to signal that the optimization
was enabled. If detected, this results in a compiler error
to make it obvious that something is wrong before invalid
code would be executed.
This is not an ideal fix for two reasons:
1. I don't know if this will detect similar problems for
other compilers than gcc.
2. If individual risky math optimizations are enabled, instead
of the combination of options included in -Ofast, the
__FAST_MATH__ preprocessor symbol will not be defined
and no compiler error will occur. I could not find a
way to detect individual risky optimizations.
However, this change is much better than nothing, and
hopefully it will prevent most cases of overly-aggressive
optimization.
I encountered a build/test failure in the Kotlin
code due to the JVM running out of memory.
I configured gradle to allow using more memory:
1GB instead of the default 256MB.
Definition of vsopModel constant on Body enum items constructors
makes cyclic dependency with constants defined later in the code
and makes application crash when things are not initiated in the
correct order.
This fixes the issue by turning vsopModel into a property which
will have almost the same internal API for the rest of the code
and resolves crashes I'm getting when certain part of my app
is initiated sooner than usual.
GitHub user `hidp123` submitted the following pull request:
https://github.com/cosinekitty/astronomy/pull/240
The problem was I had documentation for the Python enum
`Refraction` where I incorrectly wrote `Refraction.None`
instead of the correct name `Refraction.Airless`.
The fix in the pull request was correct, but it was
applied to generated source code, so it did not correctly
update the template file or the online documentation.
This commit fixes the mistake in all the affected files.
In the Windows build process, I finally realized why
I was having so much trouble sorting JavaScript
functions in the generated markdown documentation.
The script `makedoc.bat` had several cases where
I thought I was running Python programs, but I wasn't.
On my own Windows system, I can do something like:
program.py args...
And it runs the program. But in the GitHub Actions
environment, not only does this NOT run the program,
it leaves the errorlevel at 0, so I don't detect
anything bad happened.
In `run.bat`, I had already made this work by doing:
py program.py args...
Following suit in `makedoc.bat`. Hopefully this finally
works! It is also scary that all along, I wasn't running
several steps in the build process for Windows
and I had no way to detect it.
The JavaScript functions were appearing in unsorted
order in the markdown documentation.
The `jsdoc2md` tool does not have an option for sorting them.
So I wrote a new script `sort_js_functions.py` that post-
processes the markdown to sort the functions.
It turns out that "sed" does not work on Mac OS,
and I wasn't even trying to patch the version
numbers on Windows. I decided to write a Python
program for this task, so it will work identically
on all 3 operating systems.
Added a new file generate/version.txt that contains
the current Astronomy Engine version number.
Now when I run the build/test process, the version
number is patched in all the places it needs to
be changed to keep all the packages and documentation
up to date.
This means when I want to change the Astronomy Engine
version number, I just need to edit version.txt, then
execute the generate/run script.
Provide shield.io badges for pypi, npm, and nuget packages.
On the main README page, moved the badges into the supported
languages grid.
Added link and badge on each language documentation page.
Now that I have retargeted astronomy.csproj from
net5.0 to netstandard2.0, there are a couple of
other little improvements that are now possible:
1. In my manual Framework 4 test project, instead
of directly pulling in the source file astronomy.cs,
add astronomy.csproj as a project reference.
This demonstrates that the same binary astronomy.dll
works in both Framework and Core.
2. Now there is no need/use for conditional compilation
directives in the Astronomy.CubeRoot function.
Instead, always use my own implementation since the
Math.Cbrt function is never available.
From a testing standpoint, this was probably
the better option all along.
https://www.nuget.org/packages/CosineKitty.AstronomyEngine/2.1.2
This is my first attempt at publishing a NuGet package.
I have never done this before, so I'm not sure it is going to work.
Changed astronomy.csproj to target netstandard2.0, which still
works fine with all my net6.0 unit tests.
Simplified the Jupiter moon raytraced image demo
by using Astronomy_BackdatePosition to directly
calculate the vector while returning the backdated
time directly. This eliminates a redundant calculation
using the distance divided by the speed of light.
Fixed 3 of the language implementations where I forgot
to make GeoVector return the observation time, not the
backdated time. This is important to preserve existing
behavior.
