06-22-2015 04:25 PM
That's a neat trick! Oddly, it's ~2x slower than even the build array methods. Still way faster than the regex though.
06-22-2015 05:07 PM
@igagne wrote:
Oddly, it's ~2x slower than even the build array methods.
That might be very well possible but I typcially don't believe statements like that unless I have a chance to see the benchmarking code used. 😄
(90% of benchmarks posted here are completely wrong or meaningless)
06-22-2015 05:27 PM - edited 06-22-2015 05:43 PM
Normal priority. Debug off. Warning: RegEx takes a long time, reduce string length/array size for timely results.
06-22-2015 09:46 PM - edited 06-22-2015 09:48 PM
Dear Altenbach,
Thanks for nice idea.
I have one doubt. I think it wont work if string length is odd.
I think input string length is always even (i.e. 1FFDC802 instead of 1FFDC82).
EDIT: Sorry I have not read your comment.
(of course tweaks might be needed if the number of input characters is not even or if the last space is unwanted, for example)
06-23-2015 09:00 AM
I tried Altenbach code and correct it does not work if sting lenght is odd
06-23-2015 10:28 AM - edited 06-23-2015 10:47 AM
@jbore08 wrote:
I tried Altenbach code and correct it does not work if sting lenght is odd
I always said that the code would need to be tweaked if the string is of odd lenght so I don't understand why you are repeating it. No need to even test. 😄
Have you tried the decimate/interleave code? It also truncates the input data to an event number and thus has the same problem. Nothing wrong with that if the lenght is guaranteed to be even.
The original problem was to add a space between every two characters, implying that the lenght is even. If odd lenghs can occur, we need specifications on how to handle it.
From the default data in the original problem, the string looks hexadecimally formated, exclusively containing the characters 0..F. A pair represents a byte. It is very rare to have a stray nibble these days, so I think string of uneven lenghts are highly unlikely unless an error occurred somewhere else. How can you possibly get half a byte?
06-23-2015 10:36 AM
Just add a space character at the end of the string. If string lenght is even it will be ignored, if odd then the last character of the original string will be present at the output followed by this space character. You can delete or not this space character after depending on the requirement.
Ben64
06-23-2015 11:14 AM
@altenbach wrote:
@jbore08 wrote:
I tried Altenbach code and correct it does not work if sting lenght is odd
I always said that the code would need to be tweaked if the string is of odd lenght so I don't understand why you are repeating it. No need to even test. 😄
Have you tried the decimate/interleave code? It also truncates the input data to an event number and thus has the same problem. Nothing wrong with that if the lenght is guaranteed to be even.
The original problem was to add a space between every two characters, implying that the lenght is even. If odd lenghs can occur, we need specifications on how to handle it.
From the default data in the original problem, the string looks hexadecimally formated, exclusively containing the characters 0..F. A pair represents a byte. It is very rare to have a stray nibble these days, so I think string of uneven lenghts are highly unlikely unless an error occurred somewhere else. How can you possibly get half a byte?
I agree.
Feature creep. We just can't get away from it can we
10-16-2024 05:04 PM - edited 10-16-2024 05:05 PM
I found myself DIY'ing a solution that had me iterating over all kinds of gotchas, but then found the best and simplest solution is nicely canned in the 'variant data string' primitive....
Create a VI with variant input type, wire to 'variant data string' primitive, add data string output formatted as hex display.
Now i32s will print as "0000 0000" and i64s will print as "0000 0000 0000 0000" automatically