02-21-2006 07:52 PM
02-22-2006 07:48 AM
I would like to echo some of Dean's comments.
The idea is really cool (both when I heard about it earlier, and some of the new ideas discussed here). Let's say we made it a visible-items right-click option on the for loop to "show break terminal" or something. With this not shown (or when not using various other suggestions we might also implement), the performance must be as good as the existing for loop.
One of the optimizations that LabVIEW makes, for example, is allocating all memory for all auto-indexed output arrays on a for loop before it begins executing. This is much more efficient than having an auto-indexed output of a while loop, since the while loop doesn't know how big the arrays are going to be. If the for loop now isn't always going to generate N elements on the output arrays, things may not be as efficient anymore. This may be OK, as long as we can keep the performance hits to a minimum and limit them to when the new features are actually being used.
02-22-2006 08:41 AM
The for loop with break should be as efficient as possible,
no problem with extra time for testing the condition,
no problem with extra time if the break condition holds and memory is deallocated from an already allocated array.
I guess we can leave that to the compiler, anyhow we will gain more readable programs and that helps to find the other bugs.
02-28-2006 12:22 PM
One thing I would like to add: I would like to have the option to terminate a while loop when it is finished autoindexing an array. I realize this is essentially the same thing as the for loop changes previously discussed, but it just starts from the other end (a while loop, not a for loop). The only thing you would have to do is right click on an autoindexed array input and select "Limit iterations to array size" or something like that. This might be easier to explain as changes to the while loop than changes to the for loop.
02-28-2006 01:00 PM
03-08-2006 09:19 AM
A for loop with a break would be great. I also have a few other thoughts on how to improve the for loop structure. Right now the loop count is set up by directly attaching a value to the loop count terminal or through array indexing. An alternative to this could be terminals for ("i start", "i stop", and "i count") or ("i start", "i stop", and "i increment"). The first option would auto-calculate the increment and the second option would auto-caluculate the count. Each option would feed the "i" value for use within the loop.
It could also be useful to have an option where the break condition could be described on the outside of the loop. A condition could be described based on a variable within the loop. The variable could be tagged to any wire within the loop. For this matter, you could set up many independent conditions with many wire tags. One way to tag a wire could be like naming a net in a schematic capture program.
03-14-2006 12:36 AM
03-14-2006 08:52 AM
03-29-2006 07:48 AM