Merge Waveforms with NaN Padding

[minnellac]

I'm looking for a more efficient way to merge an array of waveforms that are padded with NaN's. Each waveform has the same number of samples and dt, but each one contains a fragment of a signal, padded by NaN's. The actual signal fragments do not overlap. It seems like there has got to be a more efficient way to do this, but I'm stumped, and it's Friday.

The graph in the example (LV8.5) contains each individual waveform, and then a merged waveform.

Any suggestions?

Chris

 

Message Edited by C. Minnella on 12-12-2008 04:32 PM

[Matthew_Kelton]

Do you have control over these input waveforms?  If you used 0 instead of NaN, you could simply add the Y values together (assuming no overlap which you stated won't occur).

[minnellac]

I thought about that, but zeros plot, and nan's don't.

Chris

[Matthew_Kelton]

It's probably faster to do a search and replace of 0's right before you plot than than try to handle every NaN before you merge.  With searching, you'll skip over the "good" data elements.  You didn't really explain the big picture of what you are doing and why the waveforms are padded to begin with.

You may also find it better to use non-padded waveforms then create an array of NaN's and, using replace subset, insert your good, non-padded waveforms into the NaN array.  You'll have to do some math and/or use some of the waveform VIs to find the proper insertion indices, but that's surely faster than what you are trying to do.  The coding may be worse, but once it's done, it's done.

Message Edited by Matthew Kelton on 12-12-2008 05:55 PM

[altenbach]

You could eliminate the inner loop as follows:

 

(This brings me to the curious observation that if an array is 100% NaNs, array max returns zero instead on NaN (???). This does not sound right, but maybe there is a good reason.

If it would return NaN in this case, the code would only need the array max, and not the trimmings above it. :))

Message Edited by altenbach on 12-12-2008 02:59 PM

[smercurio_fc]

---

altenbach wrote: 

(This brings me to the curious observation that if an array is 100% NaNs, array max returns zero instead on NaN (???). This does not sound right, but maybe there is a good reason.

If it would return NaN in this case, the code would only need the array max, and not the trimmings above it. :))

---

I remember this having been brought up before, so I did a quick search and found this message, but it looks like an official answer was never given.

[altenbach]

Thanks for the link, I must have missed that. It is not entirely the same, because it does not touch the situation where there are NaN and valid values present at the same time.

Clearly, there is some error handling, because the indexes are "-1" in the case of 100% NaNs. But if there is a single valid value in the array, it will be returned as min and max, thus the NaNs are ignored. Many times we are only interested in the max value and not its position so the index of -1 can be easily missed. I strongly feel that is incorrect to return a valid output (zero) for invalid inputs. I would feel much better if it would return NaN as min and max in this case.

Another edge case is an input of an empty array. This also returns zeroes with -1 indexes. Even here, NaN would be more approriate. 🙂

It is probably OK to ignore NaNs and operate on the valid values as if nothing is wrong if at least one value is valid. This behavior should be retained.

The output of -1 under problem conditions in not documented in the LabVIEW help. In addition, the labview help contains the following sentence:

"The function compares each data type according to the rules for Array Comparison.".

This seems misplaced and should be deleted, because the rules for array comparisons talks about aggregate vs elements and boolean outputs.

All this is completely irrelevant for array min&max. Right?

In summary:

• The function should return NaN for empty array or arrays containing 100% NaN. (unless there is some common standard that needs to be followed)
• LabVIEW help page for "array min&max" needs to document the "-1" index output for invalid inputs
• The "comparison" sentence needs to be deleted from the help page on "array min&max".

[minnellac]

Thanks for all the feedback guys. I should be able to implement Altenbach's improvement to eliminate the inner loop, but I'm thinking about the other "big picture" suggestions. I've got to get off that project for a while, but I'll post back if any revelations come to me.

Thanks,

Chris