Jump to content

String To Character Array (String Package)


Wouter

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?

Link to comment
  • 2 weeks later...

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?

Link to comment

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
Link to comment
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
Link to comment

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.

Link to comment

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.

Link to comment

.

'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
Link to comment

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
Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

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