From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
How to convert Hexadecimal String to comma separated Binary number
Solved!
wiebe@CARYA wrote:
But this is done in the creation of the lookup table, so it's only a one time penalty.
After the fist run, the Number To Boolean Array isn't used anymore.
In this specific instance it doesn't really matter. But in general it is in most cases a bad function to use. Easy to understand in its convoluted operation for someone who doesn't know boolean logic but still convoluted in nature.
I would likely do something along these lines instead:
Incidentially that is pretty much the algorithme the Numeric to Boolean will do internally, with the constant 32 adjusted to the size of the incoming numeric. But it produces the desired integer array right away without all kind of intermediate operations and array reversals (which in LabVIEW is just an subarray flag but still)
In fact I fail to see the need of all kind of additional conversions, just turning the boolean elements of the Numeric to Boolean Array into 0 and 1 numerics and reversing the array should be actually enough! The rest is Rube Goldberg code. LabVIEW refuses to Typecast Boolean arrays which would allow to avoid the inherent conversion into 16 bit integers through the Boolean to (0,1) function but Flatten To String works.
@rolfk wrote:
wiebe@CARYA wrote:But this is done in the creation of the lookup table, so it's only a one time penalty.
After the fist run, the Number To Boolean Array isn't used anymore.
In this specific instance it doesn't really matter. But in general it is in most cases a bad function to use. Easy to understand in its convoluted operation for someone who doesn't know boolean logic but still convoluted in nature.
I concur. I avoid the Number To Boolean Array. For a forum post, I don't always go the extra mile though.
@rolfk wrote:In fact I fail to see the need of all kind of additional conversions, just turning the boolean elements of the Numeric to Boolean Array into 0 and 1 numerics and reversing the array should be actually enough! The rest is Rube Goldberg code. LabVIEW refuses to Typecast Boolean arrays which would allow to avoid the inherent conversion into 16 bit integers through the Boolean to (0,1) function but Flatten To String works.
There is the matter of the requirements: the input being a string, and the output being a comma separated string of 1s and 0s.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
There is the matter of the requirements: the input being a string, and the output being a comma separated string of 1s and 0s.
That would end up to be something like this then:
Or a hybrid: strings, but no Number To Boolean Array?
I'm not too fond of the string constant, but that can be replaced with an initialize array (with "0,") and a concatenate. And than deleting that last comma.
Well I was faster 😁
Since in LabVIEW string characters and bytes are really the same I prefer to stay in byte space as long as possible as array manipulations are generally easier to optimize than strings.
As I said, my map generation is a one-time first-run shot with 16 iterations on a simple FOR loop and it can be replaced by a map diagram constant (= no green at all, no scanning or formatting!). Since the keys [0--9, A..F, a..f] are not contiguous in ASCII space, a simple array lookup table needs to either have holes or complicated mapping (no pun intended), so the map is more compact. I think it's pretty good and having the green in the map generation makes the code easier for the layperson. I even cast the comma string instead of using the U8 equivalent for better readability. 😄
In my own code, I would use a diagram disable structure with the map generation in the disabled case and the generated map constant in the enabled case. It is always advisable to keep the code around in case changes are needed or bugs suspected. 😮
The map also allows easy skipping of invalid input characters if desired by simply making the output tunnel of the lookup conditional to the existence of each entry.
(Sorry, just woke up. might have missed some subtleties of all the replies since my earlier posts ;))
The map is more compact than the array, but slower.
A search is (O), a binary tree search is log(O), an index in an array (1). For this example (a LUT of 16 elements), it hardly makes a difference. But in general "I want speed > use a map" doesn't hold.
Speed seemed to be the motivation for that post, and if speed is crucial, an array is faster.
Skipping invalid inputs is just as easy for the array LUT (empty string > don't add).
wiebe@CARYA wrote:
A search is (O), a binary tree search is log(O), an index in an array (1). For this example (a LUT of 16 elements), it hardly makes a difference. But in general "I want speed > use a map" doesn't hold.
Big O notation does not say anything about speed, just the limiting behavior how it scales with the input size. You can have an O(1) process that takes years and TB of storage and a O(N²) process that completes in milliseconds for reasonable inputs. Yes, I probably would have used the 256 entry LUT too (>10x larger!), but using the map is cooler and jogs the memory of readers that we now have this great data structure! 😄 I guess that was the main purpose of my suggestion.
I haven't done any benchmarking but things are not clear cut. The map does have the advantage that we operate on a contiguous U8 array while the strings might be all over the place in memory.... 😉 Concatenating strings is never(?) in-place. If we are worried about the compiler failing to estimate the correct output size of the concatenating U8 tunnel, we could do an explicit in-place solution because we know the size of each LUT entry (and the compiler might not :o). If we pre-allocate the correctly trimmed size before the loop, we can even ignore the last comma handling.
With the same argument, a LUT as 2D array (256 columns, 2, rows) of U8 might be better than a 1D array of strings (256 elements). Hard to tell without actually testing. 😉 How about a LUT with a 8bit key and U64 as elements?
@altenbach wrote:
How about a LUT with a 8bit key and U64 as elements?
Here's how that could look like:
