[Kstars-devel] Quaternions & Co (was: Plans for threading in KStars)

[Akarsh Simha]

On Sat, Nov 19, 2011 at 05:27:56PM +0300, Alexey Khudyakov wrote:
> > So you suggest that we can get away with computing Alt / Az and
> > precessed RA / Dec on-demand, since they are not really required for
> > drawing.
> >
> Exactly. We can make one step further and store only equatorial (for
> stars, planets, etc) or horizontal (zenith, satellites) coordinates. This
> means that we have to store two set quaternions for drawing. One
> for transforming equatorial coordinates and one for horizontal.
> 
> This means that we don't need to keep equatorial and horizontal
> coordinates in sync anymore. Costly EquatorialToHorizontal call
> optimizes to nothing. Code would became vastly simpler.

That makes sense. 

How about refraction corrections? They are altitude dependent, as is
bending of light around the sun.

So do we incur the additional cost of QuaternionToHorizontal()
conversion only when these two settings are enabled? Fair enough, I
would disable these settings for faster speed. Otherwise, we need to
find a way of expressing them in terms of quaternions.

> Again calculation of horizontal coordinates for sky point with
> equatorial coordinates becomes costlier (+28 flops AFAIR) and
> coordinate transformation becomes explicit (which is IMO good
> thing)

That's not a problem, since we are going to project anyway.

Also, it's not hard to keep the "base" quaternion (J2000.0
coordinates) in sync with RA / Dec. We could just sync it at load and
make it private, so nobody can touch it. Also, (RA, Dec) dmses must
become setRA() and setDec() inline functions, so that they can update
the quaternion.

Also, I suspect we have some non-J2000 catalogs. There could be bugs
lying around because of this for ages, without us knowing. Something
we should probably check while implementing this change.

Regards
Akarsh