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.
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.
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.
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.
Implemented two new C functions for generic correction
of light travel time:
1. Astronomy_CorrectLightTravel
This is a completely generic solver that is passed
a pointer to a function that returns a relative
position vector for a given time.
The generic solver keeps calling the function
whose address is passed, until the light travel
solution converges. This usually takes 3 or 4 iterations.
2. Astronomy_BackdatePosition
This is a more specific solver that uses Astronomy_CorrectLightTravel
to backdate the position of a target body as seen from an
observer body at a specified observation time.
It implements the aberration option needed by Astronomy_HelioVector.
Astronomy_HelioVector now uses Astronomy_BackdatePosition,
instead of having a redundant light travel solver,
so the code isn't much larger than it was before.
Corrected a mistake in the explanation of the
C function Astronomy_GravSimInit: the `bodyStates`
parameter is NOT barycentric -- it is relative to the
originBody parameter.
Python had improperly formatted documentation for
Time.FromTerrestrialTime parameter `tt`.
The Python markdown generator `pydown` did not
correctly handle links to compound symbols like
`#GravitySimulator.Update`. It also was trying
to link to `StateVector[]` instead of `StateVector`.
Removed unnecessary and unhelpful documentation
for C# internal class constructors. They do not appear
in the generated markdown documentation anyway.
Other minor wording revisions in the documentation.
The C# markdown generator (csdown) was not generating
documentation about constructors. This was especially
needed for the new GravitySimulator class.
Also added markdown for properties like
GravitySimulator.NumSmallBodies
GravitySimulator.Time
Made several constructors internal so they don't
need to be listed in the markdown docs.
C# builds for .NET Framework 4 were broken because
the Math.Cbrt function does not exist there.
.NET Core provides a standard cube root function,
but Framework doesn't. Added conditional compilation
to fall back to a less efficient substitute function
on Framework builds.
The Python version of the GravitySimulator class
is now passing all unit tests. This completes
the initial coding. I still need to review
documentation across all the language implementations.
Finished coding the Python version of the gravity simulator.
No unit tests have been written yet.
Cleaned up documentation in the other languages.
Made some functions static that did not need to be members.
Started implementation of the Python gravity simulator.
Updated the `pydown` markdown generator to include
class constructors `__init__` when they contain docstrings.
The JavaScript version of the gravity simulator is
now working. I had one bug in the acceleration formula.
Finished the unit tests and also streamlined them a little.
Implemented half of the GravitySimulator unit tests.
Fixed a bug in the GravitySimulator constructor.
Did some refactoring of test.js:
- Wrote Debug() function as shortcut for conditional output.
- Created generic JPL Horizons state file reader.
Starting the C# version of class GravitySimulator.
There are no unit tests for it yet.
Added a fix to the C# markdown generator `csdown`
to show `void` as a function return type.
This is the first time I have had any function
in the C# version of Astronomy Engine that has
a void return type!
Fixed and improved documentation in the Kotlin version
of the gravity simulator. Fixed some comments too.
Added the following functions:
GravSimTime
GravSimNumBodies
GravSimOrigin
GravSimSwap
The GravSimSwap function allows an instantaneous "undo"
of a simulation step, which required refactoring the internal
data structures of the simulator. I did this because I realized
I needed a way to undo exploration of time steps near a fixed
current time. This will make it easier to implement a
light travel time solver.
I have decided the ability to select different
collections of gravitating bodies causes far
more complexity in the code than it is worth.
So now the gravity simulator always calculates
the Sun and all planets except Pluto.
This greatly simplifies the core code, gets
a good balance between efficiency and accuracy,
and makes the test matrix much simpler.
The GravSimOriginState function was doing too
much work for bodies that weren't already calculated
and cached. Instead of always calling Astronomy_BaryState,
it is possible to do a lot less work for most bodies
by recycling the SSB calculation that has already
been done.
Other minor code cleanup -- mostly stuff that makes
the code easier to read and understand.
Starting implementation of a generalized gravity simulator.
Already calculating the movement of Ceres, but with less
accuracy than I had hoped. I don't know if the lack of modeling
pull of the other asteroids has a larger effect than I expected,
or there is just something wrong with the implementation.
Added the following iterator functions that wrap
search/next pairs of functions:
GlobalSolarEclipsesAfter
LocalSolarEclipsesAfter
LunarApsidesAfter
LunarEclipsesAfter
MoonNodesAfter
MoonQuartersAfter
PlanetApsidesAfter
TransitsAfter
I updated the following C# demos:
moonphase.cs ==> MoonQuartersAfter
lunar_eclipse.cs ==> LunarEclipsesAfter
Fixed an issue in the C# Markdown generator
so that it can now handle generic types like
`IEnumerable<MoonQuarterInfo>`.
Added the following iterator functions that wrap
search/next pairs of functions:
globalSolarEclipsesAfter
localSolarEclipsesAfter
lunarApsidesAfter
lunarEclipsesAfter
moonNodesAfter
moonQuartersAfter
planetApsidesAfter
transitsAfter
I updated the following Kotlin demos:
MoonPhase.kt ==> moonQuartersAfter
LunarEclipse.kt ==> lunarEclipsesAfter
However, I have not yet figured out how to use these
functions in the corresponding Java demos.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
It makes more sense to report Jupiter's moons with
individually named structure fields rather than an array.
It reduces the overall code and documentation size,
and outside of unit testing, there are few cases
where iterating over an array of moons is more
lucid than using the names of the moons.
This is a breaking change, but hopefully very few
developers are using this function yet.
Fixing the breakage is very simple.
Also added operator overloads for adding and
subtracting StateVector, just like we already had
for Vector.
