03-21-2011 10:23 AM - edited 03-21-2011 10:26 AM
@akeister wrote:
1. There's a coercion dot on the "Number to Hexadecimal String" function. It expects I32's, it seems. I suppose this coercion dot is justified, since it'll only happen once, but it would still be nice if there wasn't one, since it'll be converting an entire array to I32's.
There is no coercion, that dot is meaningless and probably a bug, IMHO.
akeister wrote:altenbach,
It actually works just fine without wiring anything to the "width" input.
Only if all characters have an ASCII code larger than x09. Maybe you can guarantee that in your specific application, but it's not clean code to leave it out.
As an example, imagine the following two string (in hex)
A: 0102 0304 0506 0708
B: 1234 5678
WIthout the lenght wired, both would give the same result "12345678". Only if you set the lenght=2, the result will be correct and unique for both strings.
03-21-2011 10:25 AM
altenbach,
Ah, I see. Thanks!
03-21-2011 10:38 AM
So, here's my scratch VI that converts from original string to ASCII hex codes and back. If anyone has any comments/suggestions for improvement, I'd greatly appreciate it. The two functions used in the For loop are the String Subset function, followed by the Hexadecimal String to Number function. The code appears to work fine.
Thanks!
03-21-2011 10:44 AM
It looks pretty decent. You don't need to wire the size of the array to the N parameter on the loop. With auto-indexing the loop will automatically iterate over the entire array.
03-21-2011 11:02 AM - edited 03-21-2011 11:04 AM
@akeister wrote:
So, here's my scratch VI that converts from original string to ASCII hex codes and back.
Looks a it complicated. try this instead:
Of course the back conversion should be done using a lookup table for even less code and more efficiency. 😄
03-21-2011 01:22 PM
Nice! So the first type-cast divides the string into groups of two characters each, and then you re-cast into U8's and finally get back to the original string.
04-08-2024 03:26 AM
I have found that concatenating an array of strings results in the same performance increase as working on a pre-allocated string of a fixed length with the added benefit of much clearer code.
This is the best I have managed (Average iteration time of 0.00015s on my laptop for processing 10000 elements, the OP's version takes 0.12s on my laptop)
04-08-2024 04:45 AM
@Worle wrote:
I have found that concatenating an array of strings results in the same performance increase as working on a pre-allocated string of a fixed length with the added benefit of much clearer code.
This is the best I have managed (Average iteration time of 0.00015s on my laptop for processing 10000 elements, the OP's version takes 0.12s on my laptop)
Yes, since a number of versions the memory management or specifically For-loops is quite optimized.