LabVIEW Idea Exchange

Dragis · ‎08-18-2009

LabVIEW loops are quite flexible and allow me to do just about anything I want, but I often find myself writing the same code over and over again trying to iterate across different data types and data structures. There are several situations where smarter looping constructs could greatly simplify my code. One simple example is stepping by a delta between a minimum and maximum value. Currently, I have to calculate the number of iterations required ahead of time (for a for loop) or do a comparison with the maximum (with a while loop) and use shift registers to maintain the intermediate value. I'd like to be able to wire the max, min, and delta to my loop and have LabVIEW do the required calculations for me. The iteration terminal could also adapt to the proper data type given the input parameters. Perhaps the iteration terminal would have two outputs, one with the current iteration count and the other with the proper iteration value.

Another useful feature would be allowing me to wire a queue reference to the loop count terminal of the for loop and having it automatically pop each value from the queue and feed it to me through the iteration terminal. It would do this until there are no values left in the queue or until the code stops the loop. One could write an algorithm that pushes new points into the queue from within the loop or push the current value back onto the queue for later processing.

I'm sure there are other useful iteration strategies that are fairly common, please share them with the community.

altenbach · ‎08-18-2009

Some related ideas from early 2006.

LabVIEW Champion.

JackDunaway · ‎08-18-2009

So, altenbach, we see you came up with the idea, but do you Kudos this one? I really like the top idea... wiring a queue ref is completely off the original topic, and I don't know if I like that. Being able to adjust the representation of the iteration terminal is awesome. So, can you wire an enum to the "Max" and "Min" terminals? For instance, as a state machine?

altenbach · ‎08-18-2009

I will kudos it in time, when the points are a bit clearer. 😉

What I want, is a FOR loop with:

* Settable representation. The [I] above is orange, so that's a good start.

* Do we need all these terminals?

* Maybe a cluster ([x0, dx, xmax] or [x0, dx, N]) would be cleaner?

* remember, in 2009 we also have the [P] terminal. It's getting crowded!

* How about being able to wire a waveform and it'll take x0, dx and iterate over the data array while giving the current [x] at the iteration terminal?

* ... just some random ideas...

I am not sure about the queue thingy. You can do that today by placing a flush queue before the loop and then autoindex over the output. Same difference.

LabVIEW Champion.

AristosQueue (NI) · ‎08-18-2009

> remember, in 2009 we also have the [P] terminal. It's getting crowded!

I made the comment during development that it is nice that the For Loop is now NP complete...

😉

tst · ‎08-19-2009

> the For Loop is now NP complete...

i don't find that funny.

...

It's unfortunate there's no way to make a lowercase i more prominent. 😞

😄

P.S. As I'm sure some people won't get it - yes, I do think it's funny.

___________________
Try to take over the world!

tst · ‎08-19-2009

Also, if memory serves, the Ramp VI which ships with LabVIEW can do the example shown in the idea (which isn't to say that such a feature would be bad).

___________________
Try to take over the world!

Dragis · ‎08-20-2009

Thanks everyone for the input so far. I'd like to clarify from my original post that I'm not necessarily expecting NI to implement the 'smart' iterators exactly the way I've expressed them. Instead, I want to get the community to post about their common use cases and as a community and with NI we can come up with a nice implementation.

That said, I'll comment on a few posts above (in order) and add a bit more information.

> I really like the top idea... wiring a queue ref is completely off the original topic, and I don't know if I like that.

I guess the original topic you're referring to is the document altenbach linked to. It's definitely not off topic with this idea because I expect this idea to make it easier to deal with any 'iterable' objects. Arrays, Queues, Classes implementing an Iterable interface (Aristos) 😉

> Settable representation. The [I] above is orange, so that's a good start.

I don't know if a settable representation is necessarily required by this feature. What is required is that the iteration terminal (or some new 'item' terminal) change to the data type specified by the loop configuration.

> Do we need all these terminals? Maybe a cluster ([x0, dx, xmax] or [x0, dx, N]) would be cleaner?

It would be nice if one could hide/show terminals that aren't in use. I'd be content with the loop allow a specific cluster or waveform datatype as well.

> remember, in 2009 we also have the [P] terminal. It's getting crowded!

I guess this is something to consider, but most of my loops are large enough that there could be a good number of terminals and it wouldn't make that much difference.

>1 I am not sure about the queue thingy. You can do that today by placing a flush queue before the loop and then autoindex over the output. Same difference.

>2 Also, if memory serves, the Ramp VI which ships with LabVIEW can do the example shown in the idea (which isn't to say that such a feature would be bad).

As I mentioned in the original post, you can do just about anything you want with what LabVIEW has today already. The idea presented here is to make things easier and to bring LabVIEW in line with other popular programming schemes.

When I first started using LabVIEW back in 2001 one of the first things I noticed was that I couldn't iterate across an arbitrary set of points like I could with Matlab loops (can I say Matlab on this forum!).

for i = 0:0.5:10,
    <do something>

Java and C# recognized the common use case of iterating over containers and built a 'foreach' into the language.

void cancelAll(Collection<TimerTask> c) {
    for (Iterator<TimerTask> i = c.iterator(); i.hasNext();)
        i.next().cancel();
}

void cancelAll(Collection<TimerTask> c) {        for (TimerTask t : c) 
       t.cancel();
}

> I made the comment during development that it is nice that the For Loop is now NP complete... 😉

I laughed!

Message Edited by asco on 08-20-2009 09:07 AM

Darin.K · ‎08-21-2009

Every so often I would like to iterate through a string one character at a time. I would not mind being able to 'Enable Indexing' on a string and get one character at a time. It's one of those things that can already be done in about six different ways, but it seems to me a string is already a U8 array with a different color wire.

tst · ‎08-22-2009

I'm pretty sure that enabling indexing on strings was explicitly requested in another idea.

___________________
Try to take over the world!

minnellac · ‎08-25-2009

After reading this, I had the same comment I did back in 2006 when something similiar came up. I'll just point to it (it's the last post on page 4 or Altenbach's linked thread): http://forums.ni.com/ni/board/message?board.id=features&thread.id=7&view=by_date_ascending&page=4.

Essentially, I was just saying that the idea of using floating point types for loop iteration may lead to some unexpected behavior. So I'm not a fan. I've attached an image with some examples of [possibly] unexpected behavior (these loops terminate rather quickly, but you expected that, didn't you 🙂 ).

Chris

LabVIEW Idea Exchange

Smart Iterators with Loops