Unknown values in the shared variable monitor?

[Hacti]

Hi,

After deploying the library and running the app I get values in the shared variable monitor for which i don't know their meaning. Some values are displayed correctly and some display the following: -1.#QNAN and -1.#IND. Tried searching the web and NI, didn't get an answer.

Also, I can't write values in the monitor for variables with above values.

Does anyone know their meaning?

Thanks a lot.

Hacti

[David Boyd]

QUOTE(Hacti @ Sep 13 2007, 05:25 AM)

Hi,

After deploying the library and running the app I get values in the shared variable monitor for which i don't know their meaning. Some values are displayed correctly and some display the following: -1.#QNAN and -1.#IND. Tried searching the web and NI, didn't get an answer.

Also, I can't write values in the monitor for variables with above values.

Does anyone know their meaning?

Thanks a lot.

Hacti

I know their meaning, but I'm not sure it will help. The indication -1.#QNAN is a string formatted output of an IEEE-754 floating-point value of Quiet NaN (not-a-number). Broadly speaking, it's the floating-point value that IEEE-754 compliant floating point libraries (or silicon) will output when performing certain operations, like dividing zero by zero, or computing the square root of a negative number, where there is no numerical answer. The IEEE standard guarantees that NaNs are propagated through further processing, so NaN plus, times, divided by, etc anything also returns NaN. Also of note, all numeric comparisons involving NaN return FALSE, even "does NaN equal NaN?". NaN doesn't "equal" anything, though there is an "IsNaN?" test. LabVIEW, I believe, is fully compliant to the IEEE-754 standard. Whenever displayed by a numeric indicator or converted to string, the output appears as NaN. There's some encoding magic I don't understand in the standard that classifies NaNs as either "quiet" or "signalling" - I think LabVIEW only generates "quiet" NaNs.

The -1.#IND is another IEEE-754 value that represents "indeterminate", though I'm less sure about how that's generated. I believe it is the string conversion of a floating-point "denormalized" number, which I believe signals a limits-of-precision condition in a calculation. I'm not a computer science major - so you'll have to look that one up for more information. I know that LabVIEW never displays indeterminates in the way that it does NaNs, so they may just be quietly converting underflows into zero.

There are also flag values for positive and negative infinities in the standard, which LabVIEW does implement (as +Inf and -Inf). Again, the encoding you're seeing in the shared variable monitor is from some standard C library and uses the formatting -1.#xxx, so you'd see that as -1.#INF.

Where your initial values are coming from, though, I couldn't say.

Sorry for the long ramble...

Dave

[Hacti]

QUOTE(David Boyd @ Sep 13 2007, 07:30 PM)

I know their meaning, but I'm not sure it will help. The indication -1.#QNAN is a string formatted output of an IEEE-754 floating-point value of Quiet NaN (not-a-number). Broadly speaking, it's the floating-point value that IEEE-754 compliant floating point libraries (or silicon) will output when performing certain operations, like dividing zero by zero, or computing the square root of a negative number, where there is no numerical answer. The IEEE standard guarantees that NaNs are propagated through further processing, so NaN plus, times, divided by, etc anything also returns NaN. Also of note, all numeric comparisons involving NaN return FALSE, even "does NaN equal NaN?". NaN doesn't "equal" anything, though there is an "IsNaN?" test. LabVIEW, I believe, is fully compliant to the IEEE-754 standard. Whenever displayed by a numeric indicator or converted to string, the output appears as NaN. There's some encoding magic I don't understand in the standard that classifies NaNs as either "quiet" or "signalling" - I think LabVIEW only generates "quiet" NaNs.

The -1.#IND is another IEEE-754 value that represents "indeterminate", though I'm less sure about how that's generated. I believe it is the string conversion of a floating-point "denormalized" number, which I believe signals a limits-of-precision condition in a calculation. I'm not a computer science major - so you'll have to look that one up for more information. I know that LabVIEW never displays indeterminates in the way that it does NaNs, so they may just be quietly converting underflows into zero.

There are also flag values for positive and negative infinities in the standard, which LabVIEW does implement (as +Inf and -Inf). Again, the encoding you're seeing in the shared variable monitor is from some standard C library and uses the formatting -1.#xxx, so you'd see that as -1.#INF.

Where your initial values are coming from, though, I couldn't say.

Sorry for the long ramble...

Dave

Thank you very much for the clarification.

Now that I know their meaning i can hopefully find the error in our code. I think the problem lies in the initialization, we run many numerical algorithams.

Regards,

hacti

[Grampa_of_Oliva_n_Eden]

QUOTE(David Boyd @ Sep 13 2007, 01:30 PM)

...

Sorry for the long ramble...

Dave

Don't appologize and feel free to ramble more often. :thumbup:

Ben

[Hacti]

QUOTE(Ben @ Sep 14 2007, 02:13 PM)

Don't appologize and feel free to ramble more often. :thumbup:

Ben

I agree:)

Hacti