LabVIEW
How to split an array into two arrays with alternating elements
Solved!
@altenbach wrote:It is likely that everything can be done much more efficiently directly with complex data, for example most transforms (e.g. FFT) understand complex inputs. Even simpler things such as magnitude and phase are easy to obtain without need of any trigonometry functions. 😄
Well you don't have to deal with trigonometry in that case, but LabVIEW under the hood still does! 😁
@altenbach wrote:
I would typecast it to a complex array instead. Now you only have one array. 😄
My gut feeling is that the typecast solution will be more efficient, because there is no change in memory order of the elements. If you decimate, you create two separate 1D arrays of half size, just to interlace them again into the complex array. Array data is always contiguous in memory, so unless the compiler can see through all that, more allocations are needed for this route.
It has been a long time since I have even considered correcting Altenbach (because he's never wrong) but I recently ran into this issue and was very surprised to see what the LabVIEW help has to say about this.
Apparently decimating an array is an in-place operation which actually outputs two arrays with different offsets and strides but does not create memory copies (unless you do something else with them later). I had been searching for optimisations on some operations and came across this:
Notice the very last sentence that Decimate array creates noncontiguous array slices. This means avoiding data copies, no?
But try as I might, the output of "decimate 1D Array" never shows me "subarray" information. Maybe the help is incorrect?
Edit: If I were a betting man, I'd rather bet on the help being wrong than Altenbach being wrong.
The help for Decimate 1D array itself mentions nothing of this behaviour.
@Intaris wrote:
Edit: If I were a betting man, I'd rather bet on the help being wrong than Altenbach being wrong.
Actually, we might both be right, because with my statement "...unless the compiler can see through all that, more allocations are needed ...", I clearly left the possibility open that some magic could happen under the hood. 😄
In my quoted case we would also need to assume that "RE/IM to complex" would again understand that interlaced subarray again. Who knows?
@altenbach wrote:
In my quoted case we would also need to assume that "RE/IM to complex" would again understand that interlaced subarray again. Who knows?
If it doesn't it will automatically force a subarray to normal array promotion if it was a subarray to begin with. Which means it is working correctly but the possible performance gain of using subarrays, is of course voided in that case.
@rolfk wrote:
Well you don't have to deal with trigonometry in that case, but LabVIEW under the hood still does!
Yes, of course! Except that the internal implementation is highly optimized and well tested.
If you would ask 100 newbie programmers to correctly implement the trigonometry, two can't do it, five will get it wrong, and 40 will create a birds-nest of inefficient code. (wild, but probably good, guess!)
Here's a very clean explicit implementation as mentioned on slide #10 of my 2016 NI Week talk:
More explicit code always means more places for bugs to hide. 😄 Each step can also add additional rounding errors due to the limitations of floating point.
(All that said, I've rewritten quite a few drop-in replacements of the stock analysis algorithms, but it is generally hard to squeeze out significantly more performance.)
