12 replies to this topic

[Aristos Queue]

Having just explained this to someone, I thought this might someday be a good question for the CLD exam. Note that although the question is being asked about Notifiers, it applies to Queues, VI refnums and, indeed, every refnum type in LabVIEW.

I'll post the answer as the first reply so that the answer isn't visible on the main LAVA page.

[Christina Rogers]

[Posted on behalf of Aristos Queue because he can't reply to his own post without the messages joining together]
Answer to Q1: Yes. The "Not A Number/Path/Refnum" function not only tests if the refnum value is equal to zero, it also checks to make sure the refnum is a valid refnum. Thus if you have a non-zero refnum but the refnum has been closed/released then the "Not A Number/Path/Refnum" function will return true but the "Equals" function will return false.

Answer to Q2: No. A block diagram constant of a refnum type always has the value "Not A Refnum," unless you count the special case of the "Static VI Reference" which is not really a constant.

[Yair]

QUOTE (Christina Rogers @ Apr 24 2009, 01:59 AM)

A block diagram constant of a refnum type always has the value "Not A Refnum,"

I always like proving R&D wrong:

I'm posting the VI (8.0), but I suggest you try recreating this yourself first (it's not particularly hard).

As a more general point, what's the relevance of such a question to the CLD and how are users supposed to know the answer? I doubt this appears in the documentation.

[vugie]

QUOTE (Yair @ Apr 24 2009, 11:20 AM)

I always like proving R&D wrong:

I'm posting the VI (8.0), but I suggest you try recreating this yourself first (it's not particularly hard).

As a more general point, what's the relevance of such a question to the CLD and how are users supposed to know the answer? I doubt this appears in the documentation.

Ha! You created a constant from a valid indicator! :ninja:

[Darren]

Also, the CLD is a 4-hour application coding exam, there aren't any "questions" on it to speak of. And this is too specific a question for the CLA. And probably too difficult for the CLAD.

-D

[neBulus]

QUOTE (Darren @ Apr 24 2009, 11:45 AM)

... And this is too specific a question for the CLA. ...
-D

Back in the day...

When I fist passed my CLA (#54) the exam read like a LV trivia test on steroids. That Q would have been appropriate.

Ben

[asbo]

QUOTE (Darren @ Apr 24 2009, 11:45 AM)

Also, the CLD is a 4-hour application coding exam, there aren't any "questions" on it to speak of. And this is too specific a question for the CLA. And probably too difficult for the CLAD.

Have you guys ever considered offering extra credit?

[Aristos Queue]

QUOTE (Yair @ Apr 24 2009, 04:20 AM)

I'm posting the VI (8.0), but I suggest you try recreating this yourself first (it's not particularly hard).

Good catch. I botched question 2. I meant it as follows:

[Yair]

QUOTE (Aristos Queue @ Apr 24 2009, 11:46 PM)

Good catch. I botched question 2. I meant it as follows:

I fail to see the big difference between this and the original form of the question. In any case, you should note that the behavior I demonstrated only occurs until you close the VI. When you reopen it, the constant is equal to 0.

All this circumvents the main issue I and others brought up - should such a thing be asked, at any level of certification? I would say that this is both arcane and unreliable knowledge, as NI could change it, and doesn't have any real value, other than as a trivia question (which as we can see needs to be checked before it can be answered correctly). Ideally, any advanced developer should know to use the Not a... primitive, although I'll admit to using the type-cast-and-compare-to-0 method myself in production code in the past.

[Aristos Queue]

QUOTE (Yair @ Apr 25 2009, 12:48 PM)

I fail to see the big difference between this and the original form of the question. In any case, you should note that the behavior I demonstrated only occurs until you close the VI. When you reopen it, the constant is equal to 0.

The constant's value is always zero. That's the key thing to realize -- if you change a control whose value is non-zero into a constant, for refnums, you always get zero.
QUOTE

All this circumvents the main issue I and others brought up - should such a thing be asked, at any level of certification? I would say that this is both arcane and unreliable knowledge, as NI could change it, and doesn't have any real value, other than as a trivia question (which as we can see needs to be checked before it can be answered correctly). Ideally, any advanced developer should know to use the Not a... primitive, although I'll admit to using the type-cast-and-compare-to-0 method myself in production code in the past.

It better not be something that NI could change. That's equivalent -- to me -- of saying you can't rely on the behavior of the Add primitive because LV might decide to make it do subtraction. These behaviors are exactly the sort of behaviors that I consider "language" as opposed to "editor". Both the "what does the "not a" prim do" and the "what is the value of a refnum constant" ought to be things that a LV programmer can absolutely depend continuing to work in future LV versions. If a change were to occur, this is the sort of thing that (a) would require significant mutation code such that existing VIs continue to operate as they did before, (b) an change to the diagram drawing such that the new primitive or the non-zero refnum constant look substantively different from the existing prim or constant, © "save for previous" functionality, and probably (d) some way to continue to drop the previous functionality in the new LV version.

I did botch the original post, but that was slop on my part, and shouldn't factor into whether or not this is defined LV behavior. Runtime functionality cannot be "just trivia."

The value of the constant is in the same category as behavior of an output tunnel of a For Loop that executes zero times. LV users' ability to read the diagram and understand what was happening would be severely impacted by changes in that functionality, in addition to the runtime logic changes.

The functionality of the primitive falls in the same category as knowing that the "Search 1D Array" primitive does a linear search, not a binary search, and knowing how "Sort 1D Array" behaves on a heterogenous array of LV classes. These are runtime details of these functions that have to be spec'd out and nailed down explicitly.

For both of these categories, any variation in that functionality from NI has to be compensated for by mutation code between LV versions and with changes in draw style on the diagram to highlight the difference.

[jdunham]

QUOTE (Aristos Queue @ Apr 26 2009, 11:56 AM)

The constant's value is always zero. That's the key thing to realize -- if you change a control whose value is non-zero into a constant, for refnums, you always get zero.

Well you can paste in a non-zero value, but it doesn't get saved. So I guess I agree. Still I would never depend on that.

QUOTE (Aristos Queue @ Apr 26 2009, 11:56 AM)

It better not be something that NI could change.

I agree that the Not-a-Refnum primitive needs to be reliably the same between versions, but the internal format of the refnum is opaque, and I wouldn't depend on that. Any use of the typecast function to inspect internal formats is risky, and could be changed by NI without protest from me. Of course it's nice that it hasn't been changing a lot, but my code wouldn't depend a typecast anyway. In some decade it's entirely possible LV could go all 64-bit, and then I would expect typecasting a refnum to a U32 would probably break.

I'd rather have a separate namespace for queues and notifiers, if you're trying to fix stuff.

[Yair]

QUOTE (jdunham @ Apr 26 2009, 10:53 PM)

Well you can paste in a non-zero value, but it doesn't get saved.

Exactly. That was the case which my example was demonstrating. Anyway, as a user, I don't see why a constant refnum MUST have the value 0. I can see the reasoning for it, but if the indicator had a value of 3428753 and I converted it to a constant, the default behavior would be for it to maintain its value (even if it's meaningless and even potentially dangerous). Until this is documented, users can't know that this will be for sure.

Jason also caught the gist of my point perfectly. I was also thinking of the 64 bit reference as an example.

QUOTE

I'd rather have a separate namespace for queues and notifiers, if you're trying to fix stuff.

I thought they do (not that I checked).

[jdunham]

QUOTE (Yair @ Apr 26 2009, 01:49 PM)

I thought they do (not that I checked). [shared namespace]

Well drat. I remember finding this problem but I couldn't reproduce it . Never mind.