CLAD sample exam 1

[ajmartin]

Well I proved my answer, but your VI never stops, you need a way to stop it and see how many loops happen, to do this you need to mod your VI, the mod I added proved my answer.

Alan

[NIquist]

I'n not saying the iteration terminal value doesn't change, that's its function after all.  I'm saying that anyone with basic labview experience would (should) interpret the question so that the answer 'C' is pretty obvious.  Could the questrion be phrased better?  Absolutely. 

[ThHagel]

Your answer only focuses on the specific case that the loop stops.

But this is not the "natural environment" of the iteration terminal. The terminal returns its values during each loop execution cycle and this is why I simply do not stop my loop. I do this to brainstorm you guys and make you stop talking about "old" counter values (after an loop stopped).

So try again. Do not change the VI and try to answer the questions.

[NIquist]

---

ThHagel wrote:

Your answer only focuses on the specific case that the loop stops.

But this is not the "natural environment" of the iteration terminal. The terminal returns its values during each loop execution cycle and this is why I simply do not stop my loop. I do this to brainstorm you guys and make you stop talking about "old" counter values (after an loop stopped).

So try again. Do not change the VI and try to answer the questions.

---

I agree with your "natural environment" concept and your overall argument but your VI and questions do nothing to persuade me that 'C' is not the answer that NI expects.  If they were asking about the behaviour of the terminal while a loop is executing they would have specified that in their question.  I'm not defending them, I'm just telling you how I interpret that particular question.  Isn't that what your thread is about?

[ThHagel]

Hi Jeff,

here my comments to your post:

---

there is no direct relation to loop executions and iteration value

---

I disagree: the value of the iteration counter is always equal to the number of already (fully) executed loop cycles.

---

Your argument that itrelates to number of times started is moot

---

It never was my argument, because then iteration count would start with 1

---

can you state with certanty the timing from start of loop to iteration increment

---

no. For sure its more than fast, but this is not relevant at all. If I want to use the iteration count value in my code inside the loop I can be sure that the value returned from it is not an old one. I don't care how long it takes LabVIEW to internally update and return that value.

---

Special case N=0 i=0- run the example to convince youself that the wire out of the loop is filled with the default data for the U32 type when the loop does not execute.  Turn on hightlighting- Of course the tunnel returns the 0 not the i as i does not execute.

---

thats clear so far but not relevant to my question

Regards,

Thomas

[Dennis_Knutson]

It is simply not true that the iteration counter is equal to the number of fully executed loop cycles. If you have a single loop cycle, the i terminal is at 0. If you have two loop cycles, the i terminal is at 1. There is never a case where the i terminal reports anything other than n-1. Every test shows this to be true and nothing that you have posted shows otherwise. Simply create a for loop. Wire any number you want to N. Wire an indicator to i. If you can post an example where i ever becomes equal to the value equal to N, then I will accept your point. Otherwise, let's close this thread down.

[DavidMaidman]

I think ThHagel's point is that if you read the iteration count during the first cycle (cycle 0) and use it to index an array for example the loop hasn't executed everything in the loop and so can not actually be  "number of times the loop has executed minus 1" as at that point 0 COMPLETE iterations have been executed.

It would make sense to say that it returns the number of times the loop has been started minus 1. However i think that seeings as it can't be any of the other answers we can guess what they meant.

[johnsold]

It might be better to refer to "i" as an iteration index rather than a counter.  Since all LV indexes start at zero, this semantic shift should help minimize confusion.

The attached VI (LV 9) shows the values of i at various places and times.  Try running it with Execution Highlighting on. Try hitting Stop immediately after the VI starts running (before the loop starts).

Lynn 

[Dennis_Knutson]

The point being that a the beginning of the first iteration and at the end of the first iteration, the iteration is 0. The iteration does not increment until the loop begins the second cycle.

[RavensFan]

I think Thagel's whole argument is centered around the semantics of what "has executed" means.  When you read the counter in any particular loop iteration, you are in the middle of the (i + 1)th iteration.  and i iterations have completely completed.  So the iteration that you are currently in, has it executed?  That is what Thagel is debating.  Has it started?  Yes.  Has it finished? No.  If something has started but not finished, does that mean it has executed or not?

You can debate that point either way if you want, and depending on what side you lean to means whether you think A or C is the better answer.

Either way, C is the correct answer.   And this is one of those problems with multiple choice tests.  I remember classmates back in high school picking apart multiple choice questions.  The lesson is that if you try to read too much into a question, you are probably going to get it wrong.

If you really want to complicate the debate, or actually confirm that C is correct, what does the i terminal mean for the new parallel For Loops?

 You can have multiple iterations occurring simultaneously.  Let's say 4 for this example.  What does the i terminal return for each iteration?  One is going to have 0, another 1, another 2, another 3.  But with Thagel's argument for "has executed", they would all return 0 because 0 iterations have completely executed before those 4 were started in parallel.  And we know that is not the case.

Message Edited by Ravens Fan on 03-26-2010 02:33 PM