12-19-2017 04:26 PM
Hi all, I rarely do any bitwise manipulation with LabVIEW, so I wanted to see if there is a better way to do what I want to do.
My goal is to to take eight 4-bit numbers (8-bit numbers constrained to decimal value 15) and create a U8 array which my device can interpret. Here is a picture, showing that I want to end up with a U8 array of length 4.
I have a solution that gets me the correct array size. Is there anything in here that seems like a very roundabout way to do things? I am going to scale this up to work with an input array with 8192 elements, so If there is a way better on memory that would be useful too.
Solved! Go to Solution.
12-19-2017 04:50 PM - edited 12-19-2017 04:53 PM
@Gregory wrote:
Hi all, I rarely do any bitwise manipulation with LabVIEW, so I wanted to see if there is a better way to do what I want to do.
My goal is to to take eight 4-bit numbers (8-bit numbers constrained to decimal value 15) and create a U8 array which my device can interpret. Here is a picture, showing that I want to end up with a U8 array of length 4.
I have a solution that gets me the correct array size. Is there anything in here that seems like a very roundabout way to do things? I am going to scale this up to work with an input array with 8192 elements, so If there is a way better on memory that would be useful too.
I guess you could take the U32 number and typecast it as an array of U8, but I don't know if that's any more efficient...
edit:
Actually, I think it is. Doesn't typecast just re-interpret the bytes? That would be more efficient than splitting up the number and re-assembling it.
12-19-2017 05:16 PM - edited 12-19-2017 05:22 PM
This code works as well. I benchmarked it and it was considerably faster, running 1 mil calculations in 0.51 seconds vs 4.31 seconds.
Edit: My output array is reversed from yours for some reason though. If this is going to hardware I'd do a sanity check to make sure you're getting the bits in the correct order.
This method also uses considerably less memory. You have one extra byte that is getting thrown away at the end of each conversion whereas "Number to Boolean Array" causes each bit to be stored in memory as a byte (Booleans are stored as bytes in memory)
12-19-2017 05:24 PM - edited 12-19-2017 05:25 PM
12-19-2017 05:27 PM
Here's my "Extreme minimalist" edition. Didn't benchmark it though. Should scale to any input array size so long as it's even (if not, it'll need to be padded or it clips the last one).
12-19-2017 05:36 PM
@Kyle97330 wrote:
Here's my "Extreme minimalist" edition. Didn't benchmark it though. Should scale to any input array size so long as it's even (if not, it'll need to be padded or it clips the last one).
I was curious so I did the benchmark compared to my solution. Mine is still a tiny bit faster (2.413 seconds for 5mil calculations vs 2.523). SO, I made a combination of our two methods... trashed the "Decimate 1-D array" and kept the indexing because it is faster. Then trashed my Join Numbers, Rotate, Split method because the "Or" was much faster.
Result was down to 1.65 seconds on 5mil calculations!
12-19-2017 05:55 PM
This seems like more work than it's worth.
You want to scale up to a total of 8192 elements. That's 8192 bytes. 8KB. If you save half of that, you're saving 4KB. Is that actually beneficial to you?
The purpose of the boolean array to number (and vice versa) is the exact opposite of what you're looking at. There isn't a reasonable way to save a single bit. Each boolean becomes a byte. You're taking something that is currently 1 byte and expanding it out to be 4 bytes by representing it as four booleans. If you want to transfer a good number of booleans, you can use the boolean array to number and use that number to use fewer bytes to transfer your data.
Back to my original question. Are you short enough on space that ANY amount of computation time is worth the 4KB you're trying to save?
12-19-2017 05:59 PM
@Gregory wrote:
My goal is to to take eight 4-bit numbers (8-bit numbers constrained to decimal value 15) and create a U8 array which my device can interpret.
I assume that's why he's doing it 🙂
12-19-2017 07:55 PM
Thanks for all the suggestions so far! I am excited to go through these when I get back to the office tomorrow.
Natasftw: It was not up to me what the data format was, I just have a document telling me very specifically how to format the data. The 8192 elements represent an array of pixels with 8192 pixels. The data represents a pattern that the device displays over time, and that can be up to 65000 time points, multiplied by the 8192 pixels. In that case the data will be ~520MB so any unnecessary copies could crash the program.
12-19-2017 08:50 PM - edited 12-19-2017 09:19 PM
What about a simple Look Up Table. Did not do a benchmark, but I would guess it's as fast as the other examples.
EDIT- If you don't like the bit/byte endianness, you can transpose the LUT.
EDIT - Just ran a benchmark and it took 25 milliseconds to pack a 5 million byte array
This is the resulting array (shown as Hex).