LabVIEW
Style suggestions for bit array to byte array
Solved!
This was a 12 year old thread and I don't think your code is correct. For example if the tail booleans are all false, they would get dropped. Your To U8 can be omitted if we change the output configuration of boolean array to number accordingly.
Also using an IPE skeleton is a bit odd because it has no function.
If the array size is not divisible by 8, we need to pad with one element. (output A)
Note there is also the 4.x typecast, but the bits in each byte will be reversed (output B)
Of course if the array size is not divisible by 8, you need to somehow retain metadata about the original length, else we cannot correctly reverse the operation. It is very likely that the remainder is zero and we never need to worry about any of this.
@Mumris did not write anything:
- When attaching code, you can dramatically increase the audience if you first do a "save for previous" (e.g. .2019). Many don't use LabVIEW 2024 yet.
- My code does exactly the same with much less code. Have you tried? All you need to know is that "reshape array" will pad or truncate to the new size and my code will pad with one more element if the size is not divisible by eight. Your parallel reshape and split operations and the insert probably cause additional memory allocations for no reason. Your entire song and dance with indices and sizes is convoluted and there are many more places for bugs to hide.
- You still have the problem that you cannot reverse the operation because the original size will get lost in the result. You should output the count of the original input array. The size of the output can be measured at any later time and is redundant.
- It is unusual to use a plain IPE frame, because it has no functionality here. Execution order is already fully determined by dataflow, so why is it there?
- You stull use the to-U8 instead of configuring the output as I already showed you. Also note the coercion dot at the insert into array. The correct function to append an element is "built array" right?
- Please don't just show a picture. Write a small paragraph explaining what you changed and why.
- When inserting images, set the size to large (as I just did)
@Mumris wrote:
Agree with you. Your algorithm is more compact and even faster by 0.5 microseconds. You won!
Speed depends on the size of the input array and the benchmarking procedure (very difficult, many landmines! Start here to learn more.)
Microseconds is not a unit of speed. Also relative times are more useful than absolute differences.
Case 1: A takes 1 nanosecond and B takes 0.5 microseconds.
Case 2: A takes 1 seconds and B takes 1.0005 seconds.
Both cases differ by 0.5 microseconds, but case 1 is much more impressive.
You still did not configure the output representation to U8, causing the creating of a blue array that takes twice as much memory (I16), which then gets coerced back to U8 at the terminal. Did you notice the red coercion dot?
