[Kstars-devel] Handling the "data unavailable" cases with NaNs.

[Akarsh Simha]

Hi Aleksey

> >I think it might be better to replace these by NaNs, so errors in
> >these objects will not propagate. Of course, we should add code
> >everywhere to handle these NaNs properly.
> >
> >This is a drastic change because it could result in segfaults
> >everywhere. So I thought I should discuss it before I do something
> >like this.
> >
> Defining characteristic of NaNs is that they are contagious. Every
> computation with NaN will produce NaN. So one way to handle NaNs is
> to perform calculations as if they are normal numbers and then check
> whether result is NaN. It's reasonable if there isn't many NaNs and
> if it reduces number of checks

Yes! This makes it really good at unearthing bugs. I just unearthed 2
bugs yesterday by making the dms class (which handles angles)
initialize the angle to NaN. And you can just check at the end of the
computation if NaN was encountered or not. I find this pretty useful.

> To my knowledge NaNs and floating point numbers in general cannot
> cause SIGSEGV. But if handling of floating points is enabled (I've
> checked and it seems to be off by default) you'll get SIGFPE signal.

True. I didn't know this, but after playing around, I see that it
doesn't cause any crashes.

> All in all it seems reasonable to me but floating points are tricky
> so care is needed

In what sense? You mean, for example, comparisons involving NaN almost
always yield "false" and the law of trichotomy doesn't hold for NaNs
:D?

Regards
Akarsh