Jump to content

Unknown values in the shared variable monitor?


Recommended Posts

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

Link to comment

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

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.