closed review String To Character Array (String Package)

[Wouter]

This OpenG Review is now closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread.

VI Name:

String to char array

Total VIs:

1

Description:

This VI creates a array of characters of a string. It splits a string every character.

Note:

Maybe there should be added another input with which you can tell that the string needs to be splitted every 2/3/4... chars instead of every char. This can easily be done by using the counter in the for loop together with modular arithmetic and a case structure.

Blockdiagram:

Code:

String to Char Array.zip

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• In which package should it be included?
  
• Should it be rejected?
  

[Jim Kring]

This looks like an interesting idea. Playing devil's advocate:

Are there any examples of similar functions in other programming languages/libraries? (if there are a lot of other languages that have a similar function, then it's probably indicative of it having a lot of use cases)

What are some common use cases for such a function?

[Wouter]

Currently I use it to split a string into chars and then randomize the array. Shortly put to shuffle a string. Further it can probably be used to spit a binary string to afterwards cast it to a integer. Further: http://www.dotnetperls.com/tochararray

[jgcode]

I (personally) think this VI is a good OpenG candidate.

Therefore I have OpenG'd the code and included a Test VI.

Please discuss.

I was unable to optimise the code further - can anyone make it faster?

To Character Array.vi

TEST - To Character Array.vi

Code is in LabVIEW 2009.

[Darin]

Simple String Subset is almost 3X faster in this case. Subroutine priority makes it slightly faster as well.

To Character Array_DK.vi

[Fab]

I find the VI useful and I think it should be part of OpenG.

I made the following modifications for speed:

But when I benchmark it some times it is faster, but some times it is not. It seems that the original version is more consistent:

Original code:

Modified code:

I am attaching the Benchmark VIs I used:

TEST - To Character Array-modified.vi

BenchMark-To Character Array-modified.vi

BenchMark-To Character Array.vi

Fab

Simple String Subset is almost 3X faster in this case. Subroutine priority makes it slightly faster as well.

I guess I need to learn to post a lot faster !!! But hey, great minds think a like

[Darin]

But hey, great minds think a like

I have also been told that fools seldom differ.

[Fab]

I have also been told that fools seldom differ.

hey, like my mom says: (translated from Spanish) "I raised you like a palm tree and you threw me like a coconut"

seriously, how did you benchmark your code to determine it was 3x times faster?

[Darin]

I use the benchmarking code provided in the Trim Whitespace thread. So I found that the fastest times for String Subset are roughly 3x (2.6 once I made both subroutine priority) faster than the fastest Byte Array times.

[jgcode]

Hey Guys, that's great!

On the topic of execution priority - I am not sure we want to this set as subroutine priority like we did with the Trim Whitespace change.

One of the reasons we did this was that NI's Trim Whitespace uses that setting:

I think this setting should be reserved for special cases only.

When do you use Subroutine priority? is a LAVA thread that Jim pointed me too.

Feel free to chime in there too with your experiences.

Of course please discuss in this thread if you think To Character Array should use this setting (highlighting pros and cons is helpful).

[jgcode]

Ok here is the updated candidate thanks to the improvements made by Darin and Fab.

Included in the ZIP is the benchmarking VI Darin mentions.

To Character Array.vi

To Character Array.zip

Code in LabVIEW 2009

[Darin]

can anyone make it faster?

Don't say I didn't tell you a way to make it faster. Personally I would not use subroutine priority in either case, I typically am satisfied with disabling debugging.

I do however benchmark code using that setting, I found it to be the fairest and most consistent comparison. In completed code, I almost always find myself wanting to run subVIs standalone at some point.

[jgcode]

Don't say I didn't tell you a way to make it faster.

lol... ok I won't however, your (s and Fab's) reply for code changes was what I was after.

I do however benchmark code using that setting, I found it to be the fairest and most consistent comparison. In completed code, I almost always find myself wanting to run subVIs standalone at some point.

Great tip, that should be noted as a valid use case of Subroutine Priority.

Personally I would not use subroutine priority in either case, I typically am satisfied with disabling debugging.

I like that an end used could easily read, follow or debug code, of course they could always switch this option back on.

Anyone else got a preference for this option - when to use it etc... (or bench marking) - feel free to start a new thread if needed.

[jgcode]

I think we have some good code.

I will change this review to pending and close it in a few days if there are no further comments.

Then add this VI to an upcoming OpenG String Library package release.

Cheers

-JG

[Jim Kring]

Should this VI be called "to Character Array" or "String to Character Array"?

If there is any interest in making the VI polymorphic, to accept other input data types, then "to Character Array" is preferable (I think). However, if it will only work on strings, it seems that it might make sense to make the name specific and go with "String to Character Array".

That said, are there any other input data types that we might want to support? I don't want to over-engineer this, but it's a question worth asking.

[jgcode]

Should this VI be called "to Character Array" or "String to Character Array"?

.

'If' this VI is in the string palette and only accepts string (as is) then this can be implied - much like Trim Whitespace (from string)?

I am open to this change.

[Jim Kring]

.

'If' this VI is in the string palette and only accepts string (as is) then this can be implied - much like Trim Whitespace (from string)?

I am open to this change.

That's true, that it's implied by virtue of it being in the string palette, but it's name is not scoped to "OpenG String.lvlib" so there's the possibility of a name collision with some other OpenG VI. Also, if someone is using QuickDrop (Darren Rocks!!!) then they won't know that "to Character Array" takes a String as an input.

[jgcode]

That's true, that it's implied by virtue of it being in the string palette, but it's name is not scoped to "OpenG String.lvlib" so there's the possibility of a name collision with some other OpenG VI. Also, if someone is using QuickDrop (Darren Rocks!!!) then they won't know that "to Character Array" takes a String as an input.

With a reference to QD you have won my vote

No, I think they are all valid points you have made to update the name 'if' it only accepts string input.

Also a valid case for .lvlib namespacing.

[Fab]

I use the benchmarking code provided in the Trim Whitespace thread. So I found that the fastest times for String Subset are roughly 3x (2.6 once I made both subroutine priority) faster than the fastest Byte Array times.

Thanks for the tip, I like that and I will use it in the future for any benchmarking.

That's true, that it's implied by virtue of it being in the string palette, but it's name is not scoped to "OpenG String.lvlib" so there's the possibility of a name collision with some other OpenG VI. Also, if someone is using QuickDrop (Darren Rocks!!!) then they won't know that "to Character Array" takes a String as an input.

I agree that adding the String to the name will provide clarity and I do use Quick Drop and like it when the vi names are more descriptive.

[Wouter]

Should this VI be called "to Character Array" or "String to Character Array"?

If there is any interest in making the VI polymorphic, to accept other input data types, then "to Character Array" is preferable (I think). However, if it will only work on strings, it seems that it might make sense to make the name specific and go with "String to Character Array".

That said, are there any other input data types that we might want to support? I don't want to over-engineer this, but it's a question worth asking.

Maybe we want to be able to split numbers as well?

Like; input a integer 33747283; output a integer array [3,3,7,4,7,2,8,3].

But if this is very usefull I don't know. I never needed this in practice.

[Wouter]

Btw anyone any thoughts about the note in the OP?

Maybe there should be added another input with which you can tell that the string needs to be splitted every 2/3/4... chars instead of every char.

[Phillip Brooks]

Btw anyone any thoughts about the note in the OP?

The only use case I can think of might be related to unicode or multi-byte char sets, but that brings byte order into play, and I think this dark side community doc has some functions that can do this already...

https://decibel.ni.com/content/docs/DOC-10153

[Ton Plomp]

OTher use cases are chunking of data into data-sections.

Ton

[jgcode]

Just a quick note: I want to make sure we avoid feature-creep (in any review), just adding features we think we need.

Keeping in mind we can always update VIs in the future if needed.

Having said that, if you feel strongly that a feature should be added, now is the time to let everyone know about it.

Cheers

-JG

[Wouter]

I think it should be added. It can be added easily to the current code. Just make the 1 constant a input variable and set 1 as a default.