[Kstars-devel] Precision in KStars

[Henry de Valence]

Hello all,

What level of precision is needed in KStars?

Currently, almost all of the code uses double-precision floats. As I'm 
rewriting the computation code, should we stick to using double-precision 
floats or move to single-precision?

The upside to single-precision is mainly that when we want to do processing on 
a non-CPU device, we run much, much more quickly. For instance, AMD's Southern 
Islands GPUs run 16x slower with double precision. I think that this is a 
worst case, though, and nVidia hardware is somewhat better, maybe a factor of 
8, but I don't recall exactly.

For instance, in the unit test for the quaternion-based conversion between 
B1950 equatorial coordinates and galactic coordinates, I have to do something 
like the following (here c is a quaternion giving the rotation between B1950 
equatorial coordinates and galactic coordinates):

void TestConvertCoord::testRotB1950ToGal()
{
    CoordConversion c = Convert::B1950ToGal();
    ...
    g = c*Convert::sphToVect(-28.916790*DEG2RAD, 265.610844f*DEG2RAD);
    Convert::vectToSph(g,&lat, &lon);
    QCOMPARE((float)lat.Degrees() + 1.f, 1.f); // discard 1 digit precision
    QCOMPARE((float)lon.Degrees() + 1.f, 1.f);
    ...
}

since there is an error term that creeps in, which is, as I recall, about 
0.025 arcseconds. I'm also not sure if that error is from floating point 
issues, or just inaccuracies with the parameters used to construct the 
conversion.

If we just use double everywhere, then we don't need to worry about precision 
issues, but it has costs, and if the input data to KStars isn't that precise 
to start, it may not even have any meaning. So I'd like to get some input on 
what the astronomical considerations regarding precision are. At what point 
does added precision give no benefit to due inaccurate measurements of the 
source data?

As an aside, I'm planning to (transparently) store the data for the larger sky 
components in OpenCL buffers, which are kept on the GPU. This way, we can do 
the bulk of our computation on the GPU, and we only have to send data over the 
bus when we want to e.g., load a new block of stars or the lie. This means 
that it's actually important to consider what the performance impact of the 
precision issue is, since it's not like we'll just do all this math, and then 
at the end convert it to floats and send it to the GPU -- it'll hopefully* 
already be there.

So, any feedback about this would be appreciated. At the moment, changing this 
is fairly simple, but as I do more work, it will obviously take more effort to 
change. For now, I'll continue using floats, unless there's a compelling 
reason not to do so.

Cheers,
Henry de Valence.

*: In the event that we don't have hardware OpenCL support, we can use a 
software implementation such as pocl (http://pocl.sourceforge.net/). To be 
very clear, even though this architecture is aimed to run entirely on the GPU, 
this is not required.