decimate array deletes odd element

[Garvacious]

Has anyone noticed that the Decimate Array function deletes the last element of your array if you feed it an array with a odd number of elements?  It seems that the function does this to force the output arrays to have the same number of elements.  I know I could use some extra functions to get around this but is this the proper behavior for this function?  Help file for Decimate Array does not mention this important fact.

[chilly_charly]

Aaaaargh !.. and it's even worse when you try to dispatch the data into a larger number of different arrays. You may loose all the last elements (see attachment) ! There is no objective reason for such a behaviour : having a uniform number of array elements has no meaning. This is is clearly a bug !

Good catch Garvacious !

[EVS]

This message have to be empty 🙂

Message Edited by EVS on 08-26-2005 10:07 PM

[altenbach]

Actually, I think that this is as expected. I you don't like the behaviour, you can simply reshape (=pad) the array to the next higher integer multiple of the desired decimation factor before decimation. 😉

---

However, there is a bug in the documentation:

The online help states that the input  "...array can be a 1D array of any type, except Boolean."

This is no longer true, boolean input arrays work just fine! 🙂

(This must have been a leftover statement from LabVIEW 4.x, where boolean arrays wre stored differently)

While we're at it, the documentation should probably mention that the decimation can cause truncation if the input array is not divisible by the decimation factor.

[altenbach]

Just for reference, the online help for the "sister function" Interleave array is a bit more clear with respect to possible truncation. It states:

"If the input array is not the same size, the number of elements in interleaved array equals the number of elements in the smallest input array multiplied by the number of input arrays."

Message Edited by altenbach on 08-26-2005 01:37 PM

[chilly_charly]

Of course, this could be considered as a matter of convention, but I think that we can give a bit more attention to this issue.

We are used to trucations. For instance in autoindexing FOR loops, where the number of iterations always corresponds to the shorter input array. Truncation is an expected behaviour when the operation requires combining arrays of different sizes, because otherwise  LV would  have to create information.

Examples

 A + B    [1, 2, 3 ] + [4, 5] = [5, 7, ?]  may be 5 could be added to a zero value ?

 A * B    [1, 2, 3 ] * [4, 5] = [4, 10, ?]  should 5 be multiplied by a 1 or a zero ?

 A / B    [1, 2, 3 ] / [4, 5] = [0.25, 0.4, ?]  worse situation with the division if the zero option was choosed...

It's always simpler to truncate, and it's even more justifiable : you can't operate on non-existent elements.

However,  the situation here is exactly opposite, the information loss is deliberate, unjustified and undocumented.

There is no objective reason to eliminate elements. Arrays of different length should be created when required. May be to be truncated at the following step, but not necessarily. This truncation behaviour is similar to a While loop with two autoindexing array inputs of different size that would stop indexing the longer array when finishing with the shorter... see my point ? 

By the way, there are some interesting situations. For instance consider the following diagrams. How do you justify the different results ?

Message Edité par chilly charly le 08-27-2005 01:26 AM

[altenbach]

---

@chilly charly wrote:

However,  the situation here is exactly opposite, the information loss is deliberate, unjustified and undocumented.

I agree, it should be clearly documented.

---

@chilly charly wrote:

By the way, there are some interesting situations. For instance consider the following diagrams. How do you justify the different results ?

Well, these results are exactly what I would expect. 🙂

• The FOR loop iterations are determined by the shortest of N and all autoindexing inputs. This is well documented.
• The while loop ONLY teminates on a boolean condition. If autoindexing arrays are depleted, the default value for that datatype is substituted. (One of my programs actually actively takes advantage of this. It can be useful ;))

What would you expect to happen in these two cases?

Of course there are other conveivable inplementations, but the current one seems quite reasonable.

I can see one possible expansion for autoindexing input tunnels in FOR loops. What if for each autoindexing input tunnel we could right-click and select between active and passive indexing (or some other designation). Active tunnels would force termination when the data runs out (Same as in the current behavior). Passive tunnels would not influence the iteration count and substitute default values once data runs out. If all input tunnels are passive, the VI would be broken unless N is wired, which then would determine the number of iterations. I wonder if this would be useful? 🙂

[chilly_charly]

---

altenbach a écrit

... What would you expect to happen in these two cases? ...

 ... I can see one possible expansion for autoindexing input tunnels in FOR loops. What if for each autoindexing input tunnel we could right-click and select between active and passive indexing (or some other designation). Active tunnels would force termination when the data runs out (Same as in the current behavior). Passive tunnels would not influence the iteration count and substitute default values once data runs out. If all input tunnels are passive, the VI would be broken unless N is wired, which then would determine the number of iterations. I wonder if this would be useful? 🙂

---

I'm so used to this behaviour that I took me some time to realize that the difference between the two loops was something potentially disturbing for a beginner. May be the reconciliation of While and For loop behaviours could be to define a "force" state for the N input, that of course would have the effect you propose with your active and passive input tunnels. Same thing for the while loop, with an "auto stop" condition ?

[tst]

And while we're on the subject, I think I asked this recently, but still: why is it that 2D arrays require padding and 3D arrays don't (each page of a 3D array seems to behave like an indepedent 2D array)?
This makes sense when you look at it visually, but if you consider programmatic handling, this just looks like an inconsistency.

[chilly_charly]

---

tst a écrit:

And while we're on the subject, I think I asked this recently, but still: why is it that 2D arrays require padding and 3D arrays don't (each page of a 3D array seems to behave like an indepedent 2D array)?
This makes sense when you look at it visually, but if you consider programmatic handling, this just looks like an inconsistency.

---

I don't see any difference between 2D and 3D. On a 3D array, each page has the same number of elements, and changing the dimensions of one page affects the others. No independency. Where is the inconsistency ?