[Kstars-devel] Precision in KStars

[Aleksey Khudyakov]

On 25.06.2013 18:09, Henry de Valence wrote:
> On Tue, Jun 25, 2013 at 4:46 AM, Aleksey Khudyakov
> <alexey.skladnoy at gmail.com>  wrote:
>> On 25 June 2013 08:56, Daniel Baboiu<daniel.baboiu at shaw.ca>  wrote:
>>> The level of precision for single precision, if we are talking only
>>> computations related to rendering, and if there are only a handful of
>>> steps, would be sufficient. The precision is 1e-8, for a full circle,
>>> leads to an error of about 0.01-0.02 arcsec.
>>>
>> It's 1e-7 actually. So quantization will be at level of 0.1 arcsec. It's
>> not prohibitive but dangerously close. Would we lose precision it could
>> lead to problems. Probably calculation of projections should will
>> be OK. Everywhere elese we should user double just to be safe.
>> It would be difficult enough to detect precision related bug.
>>
>> Is it possible to select between float/double at compile time by using typedef
>> and maybe bunch of #defines? This way it's possible to use float for speed
>> and fall back to double it won't work out.
>
> I suppose that this is possible, but I don't think that it's a great
> idea. It would be better from a code maintenance point of view to just
> have one set of codepaths. IMO if floats are good enough, we should
> always use them; if not, we should just accept the speed losses.
>
Floats are definitely not suitable for use everywhere. It's too easy to 
run into rounding issues. In my opinion they should be treated as 
optimization. They could be used speed up compulation on GPU (they 
aren't fast on CPU AFAIK) or to reduce memory footprint.

Also simplest way to check for rounding errors in code using floats is 
to replace floats with double and compare result. Another trick is to 
switch rounding mode.




> So yes, indeed the main optimization target will be OpenCL on the CPU,
> at least for now. However my suspicion is that using quaternions +
> good memory layout + parallellism already will give us a huge boost
> over the current setup, so I'm not too worried, and I don't really
> want to think too much about detailed optimization at this point, just
> general principles.
>
Surely. Simply replacing five(?) trigonomatry calls with quaternion 
multiplication O(20) floating point operations could give order of 
magnitude speedup.