LabVIEW
Possible For loop bug (LV2016)
Solved!
Duplicate post thanks to the forum software claiming there has been an error when posting and to try it again in a minute or so, while it actually posted the message anyways.
@rolfk wrote:
This has been beaten to death several times in the past.!
Some random links in chronological order:
2003: Bug in 'Build Array' function
2006: Two instances of quirky behavior: array size of empty array and tab control freeze
2010: Build Array from 2D to 3D. Unexpected size
2018: Possible For loop bug (LV2016) (this discussion 🐵
I am sure there are many more.... 😄
(Related: There was even a bug with reshape array that gave out too many zeroes. 😄 Have not tested if this is still the case.)
@rolfk
Unexpected for the novice? Yes!
Buggy? Absolutely not!
I don't consider myself a novice as I have been programming in Labview since before Labview had an undo (let that concept sink in for a moment), however, I am learning new things everyday.
The unexpected part is that a FOR loop could iterate more than 0 times for an empty array. I will have re-read the help about FOR loops, as I am pretty sure that this is not mentioned anywhere.
The code below would have to be implemented for every FOR loop that auto-index a multi-denominational array to compensate for this bug.. err, "feature". Is there a better way to compensate?
In all the code posted by "experts" I have never seen code to handle the case where an array is empty but has non-zero elements.
@Frozen wrote:
@rolfkThe code below would have to be implemented for every FOR loop that auto-index a multi-denominational array to compensate for this bug.. err, "feature". Is there a better way to compensate?
In all the code posted by "experts" I have never seen code to handle the case where an array is empty but has non-zero elements.
There is no need to compensate, because the current behavior is desirable.
(Can you attach a better picture, because it is quite blurry and seem to turn the 2D array into a 1D array at the lower branch which is if course not possible)
Here is a bitmap version (with the labels)
Umm... "bmp is not a supported format". Lets try gif?
I cannot think of any single case where iterating more than zero times on an empty array is "desirable"
Here is the use case NI is protecting for by having a for loop run more than 0 times on an empty array, there are other cases of this but this was the first thing that came to mind. Are there other ways to code around this? Sure in this case just put the average into the first for loop. But NI won't be protecting for this type of coding if they change the behavior now, and plenty of legacy code that relies on this feature will suddenly behave differently.
@Frozen wrote:
Here is a bitmap version (with the labels)
Umm... "bmp is not a supported format". Lets try gif?
I cannot think of any single case where iterating more than zero times on an empty array is "desirable"
Most of the examples that complain about this "bug" are fairly academic in their nature. I mean do you really create code like in the above pic for production code? And if you do do you truely care about what the Numeric indicator will contain? Wouldn't it be easier to simply retrieve the array sizes directly and do whatever calculation you want to do (most likely a multiply array elements)?
There is nothing wrong about an array having n * 0 or 0 * n elements, and the way LabVIEW arrays are implemented it is absolutely logical to allow that possibility. The fact that someone finds that alogical is mostly simply an opinion. If your code relies on the fact that it should do something very specific if a single dimension in a multidimensional array can be 0 you should program for that possibility. It's easy enough to do with the Empty Array node. On the other hand programming around the problem that Hooovahh showed if LabVIEW behaved differently would be quite a bit more work, and no it's not always as easy as placing the NaN into the first loop.
But the killer argument, as Hooovahh mentions, is that changing it now would surely break lots and lots of legacy code, so why fix something which is not a bug?
(Ran out of time to edit the post? Really? Continuing...)
@rolfk wrote:
do you really create code like in the above pic for production code
Which part? Yes, I do often auto-index a 2D array to access rows or columns. Is there a better way? As I stated before, I am always willing to learn something new. (If you look at the original post, you will see I was dealing with strings... math operation on strings do not work so well.)
do you truely care about what the Numeric indicator will contain?
Of course I do not care about the value of Numeric. This is simply example code, boiled down to the minimum to demonstrate a point. FYI, when presenting problems, it is considered best practice to distill the issue down to the simplest form. Besides, the Numeric indicates how many times the for loop has run, which was kinda the point of this whole thread.
@rolfk wrote:
There is nothing wrong about an array having n * 0 or 0 * n elements, and the way LabVIEW arrays are implemented it is absolutely logical to allow that possibility. The fact that someone finds that LOGICAL/alogical is mostly simply an opinion.
Totally agree.
@rolfk wrote:
@Frozen wrote:
If your code relies on the fact that it should do something very specific if a single dimension in a multidimensional array can be 0 you should program for that possibility.
You mean, if the array is empty? Hence the code above.
I mistakenly thought a for loop in Labview would not execute if the auto-indexed array was empty. (I am focusing on the empty part.)
Now that I know of this feature, I will have to think about ways to use it, and guard against it, in the future.
"It will be quite a bit more work" to guard against it. 6 of one, half a dozen of another... Awareness is the key!
