Jump to content

String To Character Array (String Package)

Wouter

By Wouter
in OpenG Developers

Recommended Posts

  • Popular Post
Wouter Newbie

Wouter

Posted
  • Popular Post
Posted

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:

gallery_17774_56_6628.png

Code:

String to Char Array.zipFetching info...

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?

  • Like 3
Jim Kring Rookie

Jim Kring

Posted
Posted

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?

  • 2 weeks later...
  • Popular Post
Fab Newbie

Fab

Posted
  • Popular Post
Posted

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

I made the following modifications for speed:

post-17236-0-35159000-1316193044.png

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:

post-17236-0-94825400-1316193379.png

Modified code:

post-17236-0-62736800-1316193401.png

I am attaching the Benchmark VIs I used:

TEST - To Character Array-modified.viFetching info...

BenchMark-To Character Array-modified.viFetching info...

BenchMark-To Character Array.viFetching info...

Fab

  On 9/16/2011 at 4:18 PM, Darin said:

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

post-26690-0-66519300-1316189881.png

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

  • Like 3
  • Popular Post
Darin Newbie

Darin

Posted
  • Popular Post
Posted
  On 9/16/2011 at 5:20 PM, Fab said:
But hey, great minds think a like

I have also been told that fools seldom differ. :D

  • Like 3
Fab Newbie

Fab

Posted
Posted
  On 9/16/2011 at 5:29 PM, Darin said:

I have also been told that fools seldom differ. :D

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 Newbie

Darin

Posted
Posted

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 Newbie

jgcode

Posted
Posted

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:

post-10325-0-32207400-1316307795_thumb.p

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).

  • Like 1
Darin Newbie

Darin

Posted
Posted
  On 9/16/2011 at 9:00 AM, jgcode said:
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.

  • Like 2
jgcode Newbie

jgcode

Posted
Posted
  On 9/18/2011 at 5:30 AM, Darin said:

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.

  On 9/18/2011 at 5:30 AM, Darin said:

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.

  On 9/18/2011 at 5:30 AM, Darin said:

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 Newbie

jgcode

Posted
Posted

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 Rookie

Jim Kring

Posted
Posted

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 Newbie

jgcode

Posted
Posted
  On 9/20/2011 at 9:10 PM, Jim Kring said:

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 Rookie

Jim Kring

Posted
Posted
  On 9/20/2011 at 10:00 PM, jgcode said:

.

'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.

  • Like 1
jgcode Newbie

jgcode

Posted
Posted
  On 9/20/2011 at 10:27 PM, Jim Kring said:

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 :P

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.

  • Like 1
Fab Newbie

Fab

Posted
Posted
  On 9/16/2011 at 6:46 PM, Darin said:

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.

  On 9/20/2011 at 10:27 PM, Jim Kring said:

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 Newbie

Wouter

Posted
  • Author
Posted
  On 9/20/2011 at 9:10 PM, Jim Kring said:

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 Newbie

Wouter

Posted
  • Author
Posted

Btw anyone any thoughts about the note in the OP?

  Quote
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 Contributor

Phillip Brooks

Posted
Posted
  On 9/22/2011 at 10:07 AM, Wouter said:

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

jgcode Newbie

jgcode

Posted
Posted

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 Newbie

Wouter

Posted
  • Author
Posted

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.

post-10325-0-53415300-1316309682.png

Guest
This topic is now closed to further replies.
Go to topic listing
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept