LabVIEW Developers Feature Brainstorming

[Jaegen]

---

altenbach wrote:

Maybe I don't quite understand your code, but I think you're a bit unfair here, because your code is more complicated than needed. From what I can see, the entire case structure can be omitted without any change in outcome. Why would you need to replace an element with itself in the array if it is > 10??? That's equal to a NOOP.

---

... where is that "oops" smiley when I need it ...

You're right, my example is less than perfect.  However, the ">10" check was just meant to represent some operation to be performed in order to create an array out of the loop.  The shift register/replace array element/array subset business is of course just to use memory more efficiently.  This points out the significant difference between my example of a for loop with a break and your example simply using a while loop:  Internally, the for loop knows the maximum number of iterations it will run (the length of the input array), and therefore can still preallocate memory for the output array.  The while loop does not know this, and will have to dynamically allocate memory.

In short, the two benefits of having an "early" break in a for loop (which my examples were supposed to display) are:

1. Preallocated memory for auto-indexed output arrays

2. No need to check for 'i == [array size] - 1" as is necessary to stop a while loop

Jaegen

[altenbach]

Sorry, I attached the wrong picture above. Of course we need to check if we run out of array elements:

Top code: while loop version. Still much simpler than your code

Bottom code: loop free version.

One would need to do some benchmarking to test for efficiency. The bottom does not need to reallocate anything for the DBL array, but the cost is allocation of a full-sized boolean array.

Yes, your FOR loop can make some assumption for the allocation of the output array, because it cannot be greater than the input array. This is not the case for the while loop. There might be  a slight advantage.

Message Edited by altenbach on 08-31-2006 09:18 AM

[altenbach]

Of course if you don't want to test during the loop if you run out of elements, you could predetermine if a match will occur and just skip the entire loop in the other case.

Message Edited by altenbach on 08-31-2006 02:16 PM

[EJW2003]

One of the options for the while loop that would be nice to have is a "terminate on true" (or false).

Many of my programs have multiple while loops, and it would be a whole lot easier if when my main while loop stopped, all the rest of the while loops would gracefully come to an end with it.

[NickH]

1. Separate entity, not a mode
2. Use the same icon.
3. Call it "stop"
4. No, it wouldn't be confusing.

[AristosQueue]

> Of course if you don't want to test during the loop
> if you run out of elements, you could predetermine
> if a match will occur and just skip the entire loop
> in the other case.

Um... what do you think the Min/Max prim does to find the minimum and maximum values? It loops over the array. Only instead of short circuiting when you got to the value >10, you'd keep going to find the maximum and minimum values. This bit of code *increases by a lot* the time complexity ... goes from N to 2N.

[altenbach]

True, but the situation is not that clear here.

• Atomic operations such as "array min/max" are typically faster than loops.
• The loop will run faster if we can save the size comparison and the extra boolean operation.

Here's a quick benchmark comparing three code alternatives.

(1) Pretest, (2) test in loop (3), search+subset.

The details depend on the debug setting. Debugging slows down case (2) proportionally more (compare slopes and result if we don't cut). Pre-testing wins only if we typically cut very late. Still, the difference is much less than a factor of two.

Clearly, code (3) "compare+search+subset" is best.

The input array is a linear ramp from 0 to 1. A threshold above 1 returns the input array.

Of course there might be some other algoritm that is even faster.

Message Edited by altenbach on 05-30-2007 02:43 PM

[Joris Robijn]

Using extra operations to decide pre-loop how much to loop... Yes that usually works nicely, but not always.

A couple of times I have written highly optimized code where you could not do this. It was essential to only loop over the data a single time. The reason was that the CPU can burst-read and cache sequential data perfectly. It can then do a couple of actions on that data and continue with the next block. If you need to go through the same data more than once it can be much slower, no matter how highly optimized the NI function node is. For large datasets the bottleneck has moved from executing a loop to retrieving data from memory. A freely available example of this is the first NI coding challenge where I was in the winning team.

NickH, I don't think it's really smart to respond in this way. It seems to me you have not read the rest of the thread, because then you would have considered our thoughts in your answer and replied to arguments. Anyway it's nice you brought new life into the thread. Let me then ask, why do you not think it is confusing if the loop can be terminated at an unknown point ? Remember the compiler schedules the instructions in an unknown order, resulting in an undetermined amount of executions of a subVI. It's not procedural coding like in C...

Joris

[gmiles@invente…]

Here is a link to the code

http://www.inventeering.com/LabVIEWexamples/ForWhileLoopExample.llb

[altenbach]

---

gmiles@inventeering.com wrote:

Here is a link to the code...

---

Sorry, I don't quite understand the meaning of your linked code in the context of this thread. Can you elaborate a little bit?

Also, the use of "concave" subVI icons is somewhat irritating. What are the benefits?.