A bad use of CachingDms would be one where a CachingDms is created or
an angle is changed, but the cached sin/cos values are never made use
of.

Test cases for CachingDms to check various operations.

This reverts commit 11bb5cf4f213277437d7a9b503b49627fe6a0d19.

Is there an improvement if we cache trig values at the cost of one
conditional branch to see if the cache is available or not?

The answer seems to be no! Running this code and comparing the results
printed to the console against the previous one do not seem to
indicate any improvement:

BEFORE:

DeepStarComponent::draw (322) - Spent 0.254752 seconds doing 2233550
trigonometric function calls amounting to an average of 0.000114057 ms
per call

AFTER

DeepStarComponent::draw (322) - Spent 0.229613 seconds doing 2233550
trigonometric function calls amounting to an average of 0.000102802 ms
per call

The difference seems very insignificant. Although there might be a
consistent trend of improvement, it is not staggering.

I rationalize the results as follows (on Intel x86_64):

1. If we assume that a branch mispredict takes about 10 CPU cycles
   (https://gist.github.com/jboner/2841832) and the float comparison
   takes another 10 CPU cycles, we add about 20 CPU cycles by
   introducing the branch.

2. sin() and cos() seem to take about 55 CPU cycles each, sincos()
   taking about 210. So let's suppose 52 CPU cycles on average.

3. Since about 50% of the trig function calls are redundant, and the
   redundant and non-redundant calls are interspersed, the branch
   predictor is very likely to mispredict.

So this suggests that in the 50% cases where we are asked to do a
fresh computation, we spend ~ 72 CPU cycles, whereas in the 50% cases
where we don't need to do any computation, we spend ~ 20 CPU
cycles. The resulting average is about 46 CPU cycles, which is not a
significant improvement from 52 CPU cycles.

This suggests that Experiment 2 should be as follows:

Create an inherited class of dms called FastDms that caches
trigonometric values every time the angle changes. So in this class,
we basically assume that we _will_ call sin() and cos()
eventually. Otherwise, we introduce overhead. The assumption can be
verified by counting calls and profiling.

Avoid recomputing trigonometric functions unnecessarily

While this may as well be done in callgrind, this is simple and works,
and is less of a hassle in running KStars (doesn't slow KStars down as
much as callgrind would).

Under some conditions, KStars output the following:

[24 0:15:36 D] KStars::~KStars (182) - Spent  7.86563  seconds in
13906422  calls to SkyPoint::EquatorialToHorizontal, for an average of
 0.000565611  ms per call

The results seem to be somewhat consistent across runs:

Spent  2.19932  seconds in  3988240  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000551452  ms per call

Spent  2.02403  seconds in  3464395  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000584239  ms per call

Spent  0.261255  seconds in  332259  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000786299  ms per call

Spent  0.464544  seconds in  530146  calls to SkyPoint::EquatorialToHorizontal, for an average of  0.000876257  ms per call

The variations seem to be tied to the number of stars in the
field. The first three results are from the USNO NOMAD artifact patch
in the Sagittarius milky way region. The latter are centered around
regions of lower star density. The variation might be probably related
to cache performance?

Profiling code I: fraction of dms objects that have sin/cos called

This is profiling code to find out what fraction of dms objects hae
sin/cos called on them. This is useful to figure out if it makes sense
to cache sin/cos values in the constructor itself. It turns out that
this might not be a wise decision since the profiling results in at
least some context says that it can be as low as 25%:

[24 0:15:36 D] KStars::~KStars (186) - Constructed  68504224  dms
objects, of which  17021346  had trigonometric functions called on
them =  24.8471 %

In a different run, it was a bit higher, but still less than 50%.

This suggests that it might not be wise to compute and cache sin / cos
values upon construction

Profiling code II: determine how many trig calls on dms are redundant

The initial results of this profiling seem to be staggering! If the
simulation clock is running, so we are actually recomputing
coordinates, nearly 50% of trigonometric function calls seem to be
redundant! This might justify caching the values of sine and cosine
upon first computation within dms() itself. This will add a
conditional, which can lead to a potential branch mispredict, and some
extra stuff, so I'd guess ~ 20 CPU cycles; however, it would save an
expensive (~110 CPU cycles) trigonometric function computation almost
50% of the time. Given that a significant fraction (~27% under some
particular conditions) of KStars' time is spent on computing sine and
cosine, it might be well worth it to save these calls.

CCMAIL: kstars-devel@kde.org

1. Use the correct definitions of Julian epoch and Besselian epoch.

2. Create static methods to convert JD to Epoch and vice versa

3. Create static method to convert an epoch value expressed as a
   string into a Julian Epoch number.

Since epochs are a measure of uniform flow of time, they cannot be
affected by leap years etc.

The peer-reviewed definition of Julian Epoch that this patch uses
comes from Eric Weisstein's World of Science:
http://scienceworld.wolfram.com/astronomy/JulianEpoch.html

(This definition may also be found on Wikipedia). The constant
2451545.0 is identical with the #define J2000 -- i.e. the Julian date
corresponding to the J2000.0 epoch.

Send heartbeat imediately upon reception of watchdog device. Then set the timer only when receiving back the heartbeat value

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

you center and track some object on Android you will be able only to
pinch-to-zoom while the lock is on)

40cf6ad6 introduced a regression where any
version of INDI was accepted, even if it did not meet the minimum version
requirement.

REVIEW: 128523

Allows the tests to pass without a running X server.

REVIEW: 128676

Probable fix of bug with disappearing and re-appearing labels in regular KStars. Need to test on other devices

Using prepared queries and committing a transaction for each 100
trixels processed.

After this change, on my laptop (Intel Core i5 dual core @ 2.5 GHz, 8
GB of RAM), the db generation took about 45 minutes for USNO NOMAD 100
million stars, and the resulting SQLite DB size is 14 GB (i.e. 10x
bloat factor)

SkyNodes, basic nodes and dialogs. Adopted KStars Lite way of searching
to regular KStars.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

to SkyNode derrived classes. Added function for deleting all childNodes
to TrixelNode