Build Array from 2D to 3D. Unexpected size.

[Ben]

Nobody else evens want to comment?

I passed this around in the office ....

and nobody got the answers right, including (4) CLA's.

So are you telling me that everyone knows this already? If so Y'all are much smarter than I thought.

Ben

[altenbach]

---

Ben wrote:

I passed this around in the office .... and nobody got the answers right, including (4) CLA's.

---

 What was the question? 🙂

• Why would you write code like this?
• Why is the FOR loop and its output not folded?
• What's the "final i count" after running?

[Ben]

---

altenbach wrote:

---

Ben wrote:

I passed this around in the office .... and nobody got the answers right, including (4) CLA's.

---

 What was the question? 🙂

• Why would you write code like this?
• Why is the FOR loop and its output not folded?
• What's the "final i count" after running?

---

All very good questions but it was the final Q "What is the final "i" count after running?" was the question I got wrong and everyone else I asked got wrong. After thinking about this since Monday night, I have adjusted my mental model but there is a big gap in that model that will help me recall this special condition when I'm reading code.

Ben

PS: I logged SR# 1505401 to try and get an explanation.

PPS: Anyone have LV 5.1 around to try this experiment? In LV 6.0 there wehere major optimization changes implemented and that (LV 6.1) is the earliest version I readily available.

Message Edited by Ben on 03-24-2010 11:06 AM

[altenbach]

OK, we all know how LabVIEW stores arrays in memory.

We start out  with N 32 bit integers, one for each dimension (I thought they were I32 (vs. U32), but the help pages does not make it clear. I still think they are I32, because that's what the index datatype is on the primitives). There is nothing preventing any of the dimensions to be nonzero for an empty array, and it might even be desirable to e.g. initialize an array in an SR as e.g. 5x0 if we later grow it as 5x1 ... 5x2 ... 5xM. A FOR loop blindly looks at the relevant field to decide on the number of iterations.

There seem to be some inconsistencies in that under some conditions (e.g. after reshaping), the dimensions get "normalized" for lack of a better word. This is somewhat unexpected.

[Ben]

---

altenbach wrote:

OK, we all know how LabVIEW stores arrays in memory.

We start out  with N 32 bit integers, one for each dimension (I thought they were I32 (vs. U32), but the help pages does not make it clear. I still think they are I32, because that's what the index datatype is on the primitives). There is nothing preventing any of the dimensions to be nonzero for an empty array, and it might even be desirable to e.g. initialize an array in an SR as e.g. 5x0 if we later grow it as 5x1 ... 5x2 ... 5xM. A FOR loop blindly looks at the relevant field to decide on the number of iterations.

There seem to be some inconsistencies in that under some conditions (e.g. after reshaping), the dimensions get "normalized" for lack of a better word. This is somewhat unexpected.

---

Sorry but this topic is too much for me to handle in one sitting. I just composed a long reply citing app note 154 and then closed the reply without posting. (O' bummer !)

I think part of what is getting in my way is how I visualize the data. A 4d array with dimensions (0,10,10,10) would have a thousnad elements in a non-existing space and then my brain explodes again.

Re: Reshaping down

Wouldn't consecutive dimSize be multiplied and combined into one to do the re-size in-place?

Ben

[Ben]

And I thought I had already exceeded my "blow your mind" quota for the week and then I got this update from support.

Are you sitting down?

---

 

I've escalated your question about uninitialized arrays causing For loops to iterate and was told by R&D that it is indeed a bug. I have filed CAR# 216411. They are of the same opinion that we had - autoindexing on an uninitialized array of any dimension should still iterate 0 times, as there are no elements to iterate on.

---

So this IS a bug.

Ben

Wrong two times in the same thread. Such is life with bugs and running in the dark.

[atigert]

Ben,

Thank you for submitting that bug report.  I didn't know how to properly submit a bug report, or I would have done it myself.  Plus, I was afraid to submit it too soon in case someone was going to chime in with a plausible explanation for the For loop behavior.

I am glad to hear that R&D agrees with us that it is a bug.

Andrew

[Ben]

---

atigert wrote:

Ben,

Thank you for submitting that bug report.  I didn't know how to properly submit a bug report, or I would have done it myself.  Plus, I was afraid to submit it too soon in case someone was going to chime in with a plausible explanation for the For loop behavior.

I am glad to hear that R&D agrees with us that it is a bug.

Andrew

---

In my case, R&D changed my mind. I was looking the wrong way, backwards toward where the array was created figuring "garbage in garbage out" while in fact the array was corect and proper but is was the garbage disposal that was behaving badly.

I congratulated the Application Engineer since he is probaly the only person in his group to find a bug in LV 6.1 since all of the AE's that were around for LV 6.1 have probably moved on.

The good news is, "All of the CLA's I work with right after all." I just have to teach them to question me when I feed them bull.

Ben

[Snamprogetti]

Exactly what do the R&D consider a bug: just the For autoindexing, or the whole non-zero size behavior?

I think all the behavior is not intuitive and not desirable, size should be zero. I just had problems with these empty arrays with non-zero size, and the cause was very very hard to find (I hadn't seen this thread).

If you create a constant from one of these weird arrays, the constant will not have the non-zero size. The array behaves different from its own copy, certainly not a good thing

[TroyK]

This bug still exists in LabVIEW 2011 and LabVIEW 2012.

LabVIEW 2013 too? Maybe even 2014?

When will it be fixed. How can I check the status?

I just tracked down a bug that was caused by a for loop executing on a pseudo-empty 2D array.

Surely this deserves some attention?