[Kstars-devel] Fwd: Plans for threading in KStars

[Daniel-Marian Baboiu]

On Sun, 2011-11-13 at 20:14 +0400, Alexey Khudyakov wrote:
> On 13.11.2011 16:21, Akarsh Simha wrote:
> > On Thu, Nov 10, 2011 at 12:08:04AM +0400, Alexey Khudyakov wrote:
> >> On 09.11.2011 21:18, Daniel-Marian Baboiu wrote:
> >>> On Wed, 2011-11-09 at 06:59 +0300, Aleksey Khudyakov wrote:
> >>>
> >>>> I think there is no need to work with Cartesian coordinates except when
> >>>> doing projections. Point on sphere could be represented as rotation which
> >>>> moves "north pole" (0,0,1) to the desired point on sphere.
> >>>
> >>> A rotation from north pole to desired point on sphere (using  quaternions
> >>> or something else) still involves calculating sincos for both latitude and
> >>> longitude (the quaternion requires sin and cos of half-angle of
> >>> rotation).
> >>
> >> This is the case if location on sphere is stored as ??,?? pair. Then
> >> translation to quaternion form involve trigonometry. But if point
> >> position is stored as quaternion there is no trygonometry involved
> >> in sphere rotations.
> >>
> >> There are no free cake and this representation eats 2x more memory
> >> (maybe it could be reduced to 1.5x). Also ra()&  dec() accessors
> >> becomes expensive and involve trigonometry. They shouldn't appear in
> >> tight loops so its OK.

Quaternions were invented precisely to work in 3D like complex numbers
in 2D.

For efficiency, the star catalogues will have to be translated into 3D
vectors; there is no need to store them as quaternions (first component
is always 0), increasing storage by 50%. On the plus side, solar system
objects are obtained directly in rectangular coordinates.

If object is stored as vector v, then its rotation around vector u by
angle alpha is described by the quaternion 
q=cos(alpha/2) + u*sin(alpha/2)
and its rotated version is
q v q^{-1}
(the ^{-1} simply changes the sign of alpha)

One more thing: the formulas for coordinate transforms using spherical
coordinates are obtained either directly using rectangular coordinates
as intermediary step, or using using the Gauss formulas for spherical
triangle (which, in turn, are obtained using a rotation in 3D cartesian
coordinates...)

> > I also think it's true that we stand to gain if we store the
> > equatorial coordinates themselves as quarternions, i.e. convert them
> > the moment we initialize a SkyPoint. But now, what I'm unsure about is
> > whether Precession, Nutation and all those corrections will like
> > quarternions. Maybe Jean Meeus' book has an answer.

There is no answer in Meeus, he only presents simplified versions, but
precise enough for practical purposes. Precession has the main component
a rotation in the ecliptic plane, but also a much smaller component of
tilting the ecliptic plane. Nutation is a little more complicated, it
has oscillatory terms.

> AFAIU precession, nutation, coordinates transformations (horizontal, 
> equatorial, ecliptic, galactic etc.), viewpoint change all could be 
> expressed as sphere rotation. So all of these could be naturally 
> represented as quaternions. Even better all transformations could be 
> fused into one quaternion.
> 
> Two exceptions are proper motion of the stars and refraction. They have 
> to be applied for each star but it shouldn't be any slower than now.

The final question is the map drawing - do you need a final transform to
spherical coordinates, or you can modify the drawing algorithm to use
directly 3D Cartesian coordinates? On the plus side, it still avoids a
lot of direct/inverse trig calls in the intermediate steps.