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

[Aleksey Khudyakov]

Forgot to CC list


---------- Forwarded message ----------
From: Aleksey Khudyakov <alexey.skladnoy at gmail.com>
Date: Wed, Nov 9, 2011 at 6:59 AM
Subject: Re: [Kstars-devel] Plans for threading in KStars
To: Daniel-Marian Baboiu <daniel.baboiu at shaw.ca>


On Wed, Nov 9, 2011 at 6:34 AM, Daniel-Marian Baboiu
<daniel.baboiu at shaw.ca> wrote:
> Quaternions are adequate for rotations if the object is in rectangular
> coordinates, and have advantages when composing rotations. For this
> particular coordinate transform, quaternions have no advantage over
> "traditional" coordinate transform. To use quaternions, the spherical
> coordinates of the point have to be converted to rectangular, rotation
> applied, and conversion back to spherical. These conversions account for
> all trig calls, except for a sincos.
>
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.

There are infinitely many rotations which move one point on sphere to
another one. This is where we get additional degeneracy. One way to deal
with it is to require z=0 in addition to |q|=1. I'm not sure how easy is to
implement such constraint.

So for coordinate transformation one need to multiply two quaternions.
No need to go through Cartesian space. I suspect that projections should
be cheap as well but I didn't actually write down transformations.

Obvious downside is that calls to retrieve RA/dec becomes more expensive
but they shouldn't appear in tight loops.


> There is place for optimization by caching the sincos for latitude -
> there is no point to call sin(lambda) and cos(lambda) for every point in
> the sky. It would make sense to have these stored when current location
> is initialized.
>
That's surely relatively cheap optimization.