closed review String To Character Array (String Package)

[jgcode]

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.

I know it is a small change, but I don't think that is a good enough reason to justify a(ny) feature.

[Wouter]

Well the reason Ton gave is a pretty strong one imo.

[Darin]

I know it is a small change...

Just so we are all on the same page, the change is not as small as advertised (not that it is that big a deal). The number of iterations must be calculated, handling the case where the data size is not commensurate with the chunk size (padding or clipping). The offset must be multiplied by the chunk size as well.

These changes add significant overhead to the single char case, too much to justify a simple change IMO. You could add a comparison and handle the single char case separately.

A Chunking tool would be useful but it should be polymorphic IMO. Certainly a candidate for an XNode, but my philosophy is that XNodes are fun to play with, but they have a lot of baggage when it comes to distributing them. Someday NI may allow us to place one at the top level in a Packed Project Library (that would be sweet) so we could distribute them as a single file. I would suggest a simple polymorphic VI that handles the usual suspects (strings, ints, floats, booleans).

I lean against bloating this one. I was already less enthused about it once I determined that the obvious method was also the most efficient.

[Jim Kring]

My preference would be to start simple and only address the most basic, and widely useful, functionality of splitting the input string into an array of single characters. If it's determined that people would benefit from additional functionality, it can always be added later. But, we don't want to risk adding features that people won't need, since every feature must be designed, documented, tested, and maintained, which takes development resources away from other high-value features/activities.

[jgcode]

I would also like to conclude this review with the original (simple) code as well.

As Darin pointed out, there are a few behaviors to consider.

Would this 'chunking' feature be better suited to a new function?

If so, let me know, and it could be reviewed in the future.

Cheers

-JG

[asbo]

I think the fundamental functionality of this VI (split into single elements) is the way it should stay. Once the data is broken up, it's relatively trivial to reassemble it into desired chunk sizes.

[Wouter]

Ok so this VI stays the same... then this maybe could be a candidate to cut a string into chunks.

Also when this ToCharacterArray VI is implemented then also http://lavag.org/topic/14875-shuffle-string/ could be implemented.

Edited September 27, 2011 by Wouter

[GregSands]

I think you need to use sign( R ) like this:

[jgcode]

Just so we are all on the same page, the change is not as small as advertised (not that it is that big a deal).

Yes, it was not a big deal to implement the multi-character functionality (that is what I meant).

I think you need to use sign( R ) like this:

I did it similar to this when I coded it, but I like the above better.

handling the case where the data size is not commensurate with the chunk size (padding or clipping). The offset must be multiplied by the chunk size as well.

This is the part that will generate some discussion on how to handle it.

I have gone ahead and created a separate thread for a Chunking VI so please continue this discussion there (I also posted some code to get the above mentioned functionality).

I am going to go ahead and close this review in a couple of days.

OpenG will be using the original String To Character Array function (note the name change) as below:

[jgcode]

This review is now closed - thanks to Wouter for the original contribution and thanks everyone for their input.

Significant contributions will appear in the copyright of the released version.

Cheers!

[jgcode]

You can track this new VI here: ID: 3419755