"Undefined" as a new value

[peos]

Double variables can have the non-numerical values NaN, +Inf and -Inf. I would also like to be able to give them the value Undefined, and that applies to all kinds of variables (integer, boolean, string, etc.). This could solve issues that other users have posted:

- To make a test for inputs of subVIs if they are wired or not. Give them Undefined as the default value.

- A ternary boolean.

- If you want to force the user to fill inn data in the main program, there must a way to see if data has been entered and not a default value. This can be done by setting Undefined as the default value.

How to handle the Undefined value:

Any operation on an Undefined value should give Undefined as a result. The only exceptions are two test blocks [Is Undefined] and [Is Defined].

This can also be useful for debugging in a tangled block diagram to see if input A really has a connection to output B. If it is, then B should be Undefined if A is set to Undefined.

[JackDunaway]

Could this be a way to use the two types of NaN (quiet and signalling) defined in IEEE 754? I'm ignorant, waiting from an answer from someone who knows.

[F._Schubert]

Hmmm, I'm more thinking about the idea of a multiplicity of [0..1]. I still didn't find the time to release a bunch of Ideas considering multiplicities.

As a side note, in JAVA they program a multiplicity of [0..1] with a Set-Flag, an accessor isSet to read this flag and an Clear to reset this flag (it's set during the Write operation of the property).

Felix

[Marc Blumentritt]

This idea is really interesting. One possible way could be making every datatype a class (I read about this in some other idea, but forgot in which one). Classes give you a simple way for these kinds of special features and users can even expand them by creating children of these base datatype classes. Of course you have to change the outlook of classes in LabVIEW...

[shb]

For a ternary boolean I use a (typedef) enumeration of type U8 with three values. The size is the same as a boolean (one byte).

In SubVIs I set the default value to something I can ignore (like 0 for building a sum) or to something that makes no sense (which I check in the diagram, example 0xFFFF).

[Brian_Powell]

I'm not particularly supportive of this idea, but I'll provide some discussion points...

* I would not want any such new value to interfere with what users can do today.  That is, I do not want to remove any existing functionality to support this.  So, for example, our integer data types could not support this unless we added a bit to their encoding.  A U8, for example, uses all 8 bits to encode the 0..255 values.  A ninth bit would be needed to encode "undefined"; I'm not willing to sacrifice 0, say, to support "undefined".

* I would also not want this new value to affect performance.  Today, I can do operations efficiently because I am using data types native the processors on which they run.  Implementing a nine-bit integer is not going to be as efficient as an eight-bit integer.

* I would think that an enumeration would be a better answer than a ternary Boolean.

* Knowing what I know about the LabVIEW internals, I would avoid signaling NaNs.  We aren't prepared to deal with the resulting exceptions.  However, using the payload part of a NaN in IEEE-754 is an interesting idea.  It would probably affect performance.  It would probably be a lot of work to figure out how the payload propagates.  For example, if I have an "undefined" added to a "NaN", should we propagate "Undefined' or "NaN"?  We'll have to add code to the Add primitive (and every other primitive) to enforce these rules.

[Norbert_B]

I do share Brians view regarding integers. While it was a really useful feature, sacrificing a bit for NaN is not possible (altering existing code). The U8 is a very good example for this. And Brians arguments regarding adding a bit (to represent NaN) is also well elaborated.

Nevertheless, it could add really good features for capturing problems within a code execution. This example might have a decent workaround if all numeric data types could have a NaN:

Instead of '0', 'NaN' could have a better result for the following algorithm directly indicating the developer that he is dealing with an empty array.

Currently since only floating point numbers have NaN, it makes perfectly sense that '0' is returned. Always, for every numeric data type....

Norbert

[X.]

• You can make an input "required".  Then you don't need to check whether something has been wired or not. It always has to be or your diagram is broken. I have argued elsewhere that outputs should be allowed to be "required" too but that's another discussion.

• If you are talking about UI, there are other ways to "force" a user to enter values in a control. Like not do anything until the value is changed...
• NaN as an input of pretty much any primitive will give NaN as an output, won't it? But isn't it safer to do error checking and passing rather than test the result of a computation and  left guessing what the source has been (if I understand you, you would pass an "undefined" result through dozens of VIs uncaught)?

I have no stake in this discussion, BTW, but apart from the technical aspects discussed above, it seems to me that you want to solve UI, programming and debugging issues with a cute feature that does not really seem to be necessary.