my XNode - Select N Inputs

[o u a d j i]

hi all,

 

here is my last xnode (LV2012) , "Select" ... but with n inputs. (100% polymorphic)

 

2 menus :

 

1) select mode : after&before , only after, only before

  select output : top , center

 

2) add input (after) , remove input

 

ouadji,

 

(for a quick test ... unzip ---> QUICK_TEST.vi)

 

 

SelectNinputs (Ouadji).zip

[hooovahh]

Seems neat, so how is this different than a build array and index?

[o u a d j i]

yes, there are ways to do this another way.

it was just for the fun, nothing else.
(sorry for my bad English, i do my best)

 

"seems neat" ? ... no, it is very neat !

[o u a d j i]

@hooovahh : how is this different than a build array and index? ....

 

with arrays on inputs ... you can build an array of arrays ?

with this xnode, no problem.

[hooovahh]

@hooovahh : how is this different than a build array and index? ....

 

with arrays on inputs ... you can build an array of arrays ?

with this xnode, no problem.

Okay so build array and index won't work for arrays, but build cluster and select will work.

 

 

Don't let me detract from the work you did.  I have yet to make an XNode from scratch and what you learned can be valuable knowledge.  I just won't be using your XNode is all.

[Naity]

Why wouldn't build array and array index work?

 

When you build an "array of array" with the build array fonction, you can either concatenate those array into a bigger one from same dimention or create an array of n+1 dimension. This array could then be indexed again:

 

 

It does have some caveeats, like all the array will get the size of the bigger one, which also might need some additional code tu reduce it to its original size. but it still remains possible.

 

About the XNode, I downloaded the code but I never heard of them before, so I can not be anyhow critical in my review. Still its a great tool and I am also looking for a idea of a function to create with them.

 

[hooovahh]

Tell me that's not actually how you would code the logic to pick a certain input array based on a selector input and pass it to an output. It's Friday, you get the benefit of the doubt here.  

See my previous comment to hooovah 

Oh give me a break.  I wanted something scalable with as few clicks as possible to add new items, using as little foot print as possible.  Normally I wouldn't use such a function but I challenge anyone to come up with a better solution that is smaller, or uses less clicks to add items.

 

ALSO I used a cluster because my arrays are not the same size so a build array function would cause wrong data (without the added code to know the size the output should be) which I don't need to worry about with a cluster.

Edited May 24, 2013 by hooovahh

[Naity]

Well, it is not how I would have built it either, but previous comments sounded like it was not possible at all. I just wanted to check for myself.

[hooovahh]

Well, it is not how I would have built it either, but previous comments sounded like it was not possible at all. I just wanted to check for myself.

It is possible, given the limitation that all arrays have the same number of elements and are the same size.  If I have 4 3D arrays to choose from they all need to be the same size in each dimension.

 

But using clusters does have another runtime issue.  A cluster can be mixed data types, so if Item 1 is a string, and Item 2 is a double an error will occur with my method if you select item 2 because the Variant to Data will throw an error at runtime, but still allow the VI to run, where your method will create a broken arrow.

Edited May 24, 2013 by hooovahh

[hooovahh]

Bundling n-arrays into a cluster is scalable just because it is possible?

I don't know what you mean by this.  Yes it is possible to scale up the example to support any number of items for any data types.

 

Your new method is the most obvious, but I was originally trying to stay true to the XNode feel, where there is a terminal that is added, then the new data is wired to it, and the selector chooses which one.  This method has two operations to add a new item to the selector.  Add the new terminal, and connect the data to the new terminal.  Your method is similar but if I needed to select from a large number of items (say 50) then making the bundle to be of that size is easier then adding a new 50 cases to a case structure.  

 

Of course if I needed to select from 50 different items I may do something altogether different.

 

But to be honest I use your method all the time, and made my method for the first time today.

Edited May 24, 2013 by hooovahh

[hooovahh]

To quote Jerry Seinfeld: I think if you've got a T-shirt with a bloodstain all over it, maybe laundry isn't your biggest problem

Thanks for that, it is Friday.

[o u a d j i]

.XP sp3

Q6600 2.8Ghz

4Go

Edited May 24, 2013 by o u a d j i

[Naity]

Factor 500... Could do better!

 

Just kidding, you did a very great work

[hooovahh]

Literally orders of magnitude faster I'll give you that.  My only concern would be that Xnodes are the deep underbelly of LabVIEW and have no support, and NI's official opinion is that they should not be used (unless the XNode is made by NI of course).  Which is why I was looking for non-XNode code that can do the same and still be as easy to use as the XNode.  Turns out my first attempt met those criteria but is much much slower.

[Bobillier]

He nice.

Few years ago i have propose this idea on LV idea exange forum http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Growable-Multiplexor-or-multi-Cases-selection/idi-p/1044365

Is-it possible to have it in LV2011 ?

[o u a d j i]

http://forums.ni.com/t5/Discussions-au-sujet-de-NI/Mon-dernier-XNode-Select-N-inputs/m-p/2858048#M13259

[Aristos Queue]

ouadji: I never saw this post when it first went up... I have a problem with your benchmark. Can you redo it with the following modifications?

 

1) Change all the array constants and the numeric constant into controls and move them outside of the loop.

2) Put all those controls on the conpane of the VI. Put the indicators on the conpane also.

3) Create a caller VI that calls into your VI passing in controls (not constants) with the values.

4) Close the front panel (very important) of the subVI and do File >> Save All.

5) Now run your benchmark and see the performance.

 

I do expect a significant performance boost but right now, your bench mark could be skewed by a whole bunch of constant folding and other compiler optimizations that wouldn't occur in real code. The above steps are basic requirements for any benchmark in LabVIEW.

[hooovahh]

Thanks for the tips AQ, what about Automatic Error Handling, and Debugging?  Shouldn't those be turned off too?

 

In either case I just re-ran the timing test from above and it isn't a surprise that the XNode is still much much faster.  I ran with the changes you suggested 100000 loops and the XNode registered 0ms, and my version with OpenG was 8724ms.  I inlined the OpenG VIs out of curiosity and it went down to 8413ms.

 

I'm torn because I like this XNode, but won't add it to my reuse tools due to the fact that it is an XNode.  Which is why I tried implementing a solution just as easy to use but with OpenG.

 

Attached is my benchmark saved in 2012.

Selector Speed Test.zip

[Aristos Queue]

Thanks for the tips AQ, what about Automatic Error Handling, and Debugging?  Shouldn't those be turned off too?

AEH? Yes.

Debugging? Depends upon what you're benchmarking. Yes, I usually also turn it off, but some people want to see the performance in the editor and assume runtime will be even faster.

[GregSands]

You could use Build Cluster Array:

 

 

That runs faster than the XNode.

 

I'm torn because I like this XNode, but won't add it to my reuse tools due to the fact that it is an XNode.  Which is why I tried implementing a solution just as easy to use but with OpenG.

 

My experience is that for a well-written, and fairly simple, XNode (which this seems to be), there is almost never a practical issue with using them.  I've even used them on RT.  Yes there may be dragons, but they usually be tamed.

 

[hooovahh]

You could use Build Cluster Array:

That is fantastic.  I don't use that function often enough.

 

Your comment about it being faster then the XNode isn't true for my test.  Many times better then my OpenG version for sure.  I had to run 10,000,000 iterations to get anything usable.  With that many iterations your version took 1540ms and the XNode version took 1ms.  Even so given the XNode limitations (in terms of support) I would probably use your version.

 

I want to believe your statement about using XNodes.  Partly for this function, and partly for the OpenG Array tools.  What I'd really like to do is package up these tools into our internal reuse library.  But that is just something I cannot do until NI endorses using these techniques.  Maybe I could make a XNode package and not include it in our base reuse and just have it be experimental.

 

EDIT:  And no one has suggested this yet but you should submit this to the Code Repository.  There is a category for XNodes.

[GregSands]

Actually, on my machine it's the same speed as the XNode (plus/minus OS jitter), even for >10M iterations.  I had run it only once which had Build Cluster Array marginally faster, but over several runs they end up more or less the same.  Maybe check the debugging/compile options.

[hooovahh]

Maybe check the debugging/compile options.

All off, I even have the subVI inlined just as my example in the zip I posted earlier.

[gb119]

I want to believe your statement about using XNodes.  Partly for this function, and partly for the OpenG Array tools.  What I'd really like to do is package up these tools into our internal reuse library.  But that is just something I cannot do until NI endorses using these techniques.  Maybe I could make a XNode package and not include it in our base reuse and just have it be experimental.

I'd be a little surprised if the performance with the OpenG Array XNodes where very different from the original OpenG versions - the XNode code is just being generated from a template that is nealry identical to the original OpenG version (or at least if the OpenG versions had the optimal settings applied to them in terms of debugging and inlining etc.)

 

I've sometimes wondered if one could persuade an XNode to replace itself with a normal sub-vi version of the generated code. Perhaps a right click option on the XNode that took the generated code and saved it next to the parent vi with a unique name and then did the replacement. That would let one develop testing code with XNodes and then 'freeze' them to normal vis for release so that production code wasn't using unsupported features. Of course, code that eplaces itself might equally be a quick way to crash the IDE

[hooovahh]

I'd be a little surprised if the performance with the OpenG Array XNodes where very different from the original OpenG versions - the XNode code is just being generated from a template that is nealry identical to the original OpenG version (or at least if the OpenG versions had the optimal settings applied to them in terms of debugging and inlining etc.)

 

I've sometimes wondered if one could persuade an XNode to replace itself with a normal sub-vi version of the generated code. Perhaps a right click option on the XNode that took the generated code and saved it next to the parent vi with a unique name and then did the replacement. That would let one develop testing code with XNodes and then 'freeze' them to normal vis for release so that production code wasn't using unsupported features. Of course, code that eplaces itself might equally be a quick way to crash the IDE

I never said that an XNode would have better performance then the exact same code in a normal VI.  I was comparing my implementation (or Gregs) to the XNode implementation which may or may not use the same technique.

 

I thought I heard of an XNode replace before so I did a quick search.

 

http://labviewwiki.org/ReplaceSelf_(XNode_Ability)

 

Which I assume is what we are talking about, but again my experience with XNodes is quite limited, mostly just using what others have made.