Jump to content
Wouter

String To Character Array (String Package)

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

.

'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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...

Important Information

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