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

[Alexey Khudyakov]

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.
>
> I think it's true that quarternions are equivalent to using Cartesian
> coordinates (I'm thinking of them as a generalization of complex
> numbers.).
>


> 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.
>
I think that euqlidean vectors with norm 1 are better suited for 
representation of points on the sphere. They are more compact (3 instead 
of 4 numbers), do not suffer from ambiguity and easier to correct for 
refraction.

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.


Even better. There is no need to recalculate horizontal coordinates for 
each star. Coordinate transformation could be hidden into quaternion.
In pseudocode:

> q = q_{to horiz.} * q_{precession} * q_{nutation}
> x_{projected} = q * x * q^{-1}
> (x,y) = project( x_{projected} )

Projections should be faster as well. There is no need to use 
trigonometry. Equirectngular projection is an exception it'll became 
slower asin/acos are expensive.

As for quaternion implementaion IMHO we should use eigen.


P.S. I really should to write summary which describe all the math.