Concatenating tunnel mode that allow string type

[Ironman99]

I finally found the time to download a trial version of LV2012. I find that the new 2012 features are really useful and interesting. Good job NI!

One of the greatest for me is definitely the new "concatenating tunnel mode".

I've noticed that it cannot be activated with a variable of scalar type, and this obviously makes sense for almost every type of variables. However, strings are only formally scalar variable. I have lots of VI where the concatenate string vi has exactly the same use (on strings) that Build array has on numerics type of data, particularly when the concatenation had to be conditional. Obviously it is possible to convert the string into a U8 array before to connect the wire to the tunnel, and reconvert it into a string out of the loop, but this convertion probably can be internally managed without too much effort.

The attached snipped can show you what I mean. So, in my opinion, if tunnels could accept strings also when in Concatenating (conditional or not) mode would be great.

Cheers.

[Ironman99]

Sorry, in my message I've attached the snippet instead of making it visible in the post, but I don't know how to do the trick...

[Mads]

Kudos.

One alternative to the current implementation that you have illustrated is to use auto-indexing on the outgoing string, and then wire the resulting string array into a concatinate function that you shrink to have just a single input. The concatinate node will then flatten the array into one string.

This way you can skip the case inside the loop and use the conditional indexing feature of LV2012 (or better; use the OpenG alternative which is drastically more efficient, at least until they fix the way the in-built conditional tunnel works) to generate the array to flatten with the concatinate function.

[Ironman99]

Thanks Mads! Your suggestion makes the implementation even simpler than mine.

However, in my opinion, the focus of my idea remains the same. Perhaps this is so only for me, but all the three options of tunnels seem to me so natural for strings, that it seems to me a pity to have to apply some kind of convertion on the result.

In the mean time I understood how to show a snippet on the post, so I put there a new one, with your suggestion added.

Thanks a lot.

Cheers.

[crossrulz]

Hate to do this to you, but I've added another way to do this.  It would be interesting to see which way is truely the most efficient.  I just don't have time to do a benchmark right now.

[Ironman99]

You are welcome, crossrulz!

One of the benefit of idea exchange (and discussion forum) is the opportunity of learning a lot from other's way to do the same thing.

I took the time of a benchmark (only for speed) of the different proposed methods... and the winner is...

1. the use of shift register (not so surprising) 

2. the use of two conversions String->U8 array->String and the tunnel conditional concatenation

3. (with a time close to the second method) the use of a TRUE FALSE vi, and the external convertion using the concatenate strings.vi

4. the conditional tunnel for building array, and the external convertion using the concatenate strings.vi

I included the snipped of the vi I used, if you want to check results on your PC.

Ok, good to know. However, I must say that I am not always looking for the maximum speed. Often execution time is not the primary performance to look at. From the point of view of software maintenance, the clarity of the diagram may be very important. Don't you think that it would be great if it were possible to write our example as follow? Neat, isn't it?

Cheers.

[Ironman99]

I forgot the snipped...

[wevanarsdale]

Your test involves short strings.  Do longer strings with variable length affect your results?  Please post times if possible.  Thanks

[Ironman99]

Although the tests proposed are very interesting, I think we're going a bit off topic.

The point in the proposed idea is:

since (unlike other variables) it is absolutely legal to concatenate strings together, why LV does not allow us to do that operation, using the new tunnel's features?

If NI has implemented these new features efficiently or not, is another (interesting) topic. Of course, knowing the performance of different methods, you can choose the one that best suits your situation. For those who can not open the attached snippet, I write with pleasure the results of four different methods:

1. the use of shift register (not so surprising)  = 156ms

2. the use of two conversions String->U8 array->String and the tunnel conditional concatenation = 185ms

3. (with a time close to the second method) the use of a TRUE FALSE vi, and the external convertion using the concatenate strings.vi = 207ms

4. the conditional tunnel for building array, and the external convertion using the concatenate strings.vi = 425ms

wevanarsdale:   Obviously these results can vary a lot, case by case. In the example VI, for each iteration, the lenght of the added string is "small" (1 to 6 chars) but the resulting string grows a lot, because of the 1000000 iterations, up to about 3M chars. For each iteration the concatenating tunnel has to manage such a big string. I tryed to increase the lenght of the added string (up to 50 chars), but the the podium positions didnt change. The method that more suffers of the increased added string len is (obviously) the one with str-> U8 convertion. As far this test is significant, the new tunnel concatenating mode seems to work efficiently enough for my purposes.

Cheers.

[AristosQueue (NI)]

The conditional tunnel for building an array will (standard caveats about promising future functionality) be more efficient in 2013. We followed the standard pattern of "make it work, then make it work efficiently" which tends to be the least bug-prone path to high speed code.

[Ajay_MV]

I'm still looking forward for this feature in LabVIEW 2015.  I don't have idea if it's implemented in LabVIEW 2016.

Regards,

Ajay.