NaN as opposed to 0.0

[LordFerret]

I've noticed a number of times when doing orbital plane alignment that "NaN" will appear rather than 0.0 degrees. Do I take it that internally it's trying to tell me I'm at -0.0 degees and "NaN" is "Not a Number"? I've also seen mention of the 'NaN Kraken'... is there some manner of risk or bug related to this? If so, I've not run across it yet. Just curious.

Edited November 29, 2014 by LordFerret

[robopilot99]

Now that you mention it I've noticed that too. Not sure what the deal with it is.

[TythosEternal]

When calculating the angle between two planes, one operation that is performed will return NaN if the planes are aligned within numerical tolerances of zero. NaN is like a stain--once one of your calculations returns NaN, everything else that is computed from that calculation will result in NaN, too, including the end solution.

For differential orbit calculations, there are some basic checks you can perform to fall back on simpler, more robust calculations for cases like aligned planes. However, a lot of basic, casually-implemented astrodynamic routines (like those likely underlying your calculations here) don't bother implementing anything other than the generic solution.

There are some other, similar instances where you will see certain elements reported as NaN not for numerical reasons, but rather because Keplerian formulations have singularities for certain cases. (Singularity, in this case, means that one possible state in inertial space maps to multiple states in Keplerian space.) For example, for zero-inclined orbits, RAAN and AoP are now redundant--when trying to back out the equivalent elements, some frameworks will just compute one and report the other as NaN, or zero, because it is no longer necessary.

[Taki117]

NaN is in fact "Not a Number" this means that the rounding is so close to -0.0 that it doesn't register. As far as the NaN Kraken more information can be found here.

[GoSlash27]

NaN is KSP's error message for "I can't divide by zero". Your match to the target's inclination is perfect. I always shoot for NaN when intercepting.

Best,

-Slashy

[John FX]

It is when numbers get so low (or high) that they need a power to represent them like `1.2*10^-12` and KSP does not see that as a number so it flags a NaN error. If the number was zero then that is a number and so causes no error.

This can crash your game.

[SciMan]

AFAIK, a NaN result in KSP can only cause an error if it shows up outside of the plane alignment display or a debug log message that says something like "Error: Dt is NaN!" (which usually shows up when you target or un-target things).

From experience, those two NaN errors are quite harmless. I've had both of them show up several times around 20 minutes after I started KSP, and I continued playing without any odd behaviour happening for several hours, all while running several mods.

Some NaN's are more harmful than others. In my experience the two I pointed out above are totally and completely harmless.

NullReferenceExceptions, on the other hand, are ALWAYS problematic. If you go into the debug log and see red text with that phrase in it, it means that some part of the game is looking for something that isn't there. These probably will eventually crash your game, and they always mean something isn't working right.

[LordFerret]

With only two exceptions (orbit adjustments out of Kerbin's SOI), it appears most often while I'm trying to match orbit planes of other craft/stations. Sometimes I get 0.0, others (less frequent) I get NaN. So basically it is what I thought. Thanks for clarifying that. I've not yet run into the NaN Kraken (and hope to keep it that way lol).

Thanks Slashy, that saves me additional head-ache trying to hit 0.0 instead.

And thanks also Taki117, I'm off to go read that now.

[numerobis]

It is when numbers get so low (or high) that they need a power to represent them like `1.2*10^-12` and KSP does not see that as a number so it flags a NaN error. If the number was zero then that is a number and so causes no error.

This can crash your game.

A number that is too large will be represented as inf, whereas a number that is very small will become 0 (or -inf if by small you mean a large negative number).

NaN is for numbers that aren't reals, such as sqrt(-1) or log(-1) or asin(2). The issue here isn't that the machine accuracy is limited, but that mathematically you have asked a question with no answer (in the reals), so the computer responds by saying the answer is "not a number".

And as explained above, any arithmetic operation involving a NaN returns a NaN, so a NaN will propagate if you aren't careful.

This may cause problems, or it may be completely harmless; it depends on what parts of the code use the NaN. You can't easily determine that.

Apparently, the calculation of the AN/DN angles aren't problematic. So I aim for NaN -- that means I've precisely matched the planes! I rarely hit it; usually I'm at 0.0 or worse.

[Nuke]

you can detect nans an change the value to 0 for example or stop calculations all together. you can also just ignore nans and put in some logic in the ui that checks if a number is a nan and replace it with a 0 or whatever for display purposes. but i think that is one of those spit and polish things that shouldnt be done until later in beta.

Edited November 29, 2014 by Nuke

[pvtnum11]

NaN is basically the best inclination match possible, I've had it happen a few times, makes for some great orbital rendezvous.