Malleable VI: How to assert a set

[CL_eisenwr]

I am trying to make malleable via that should only work on a set. I am stumped what in Assert Type Palette to use to verify that what being feed is set. The datatype of the set is not important.

[altenbach]

Well, you could try to insert the first element into its set (would break for all non-sets).

Maybe there are better solutions, but this seems to work.

[mcduff]

Don't have LabVIEW here to check, but I thought the "Set Intersection" function was a malleable VI; maybe there is a clue in there.

mcduff

[wiebe@CARYA]

The trick is to assert, while actually not adding any workload.

I don't have sets yet... But this works for arrays:

Put any set function that has a set in and set out in the disabled case of the disabled structure. This does not do anything! But it defines the output type. Don't wire the enabled case. If the input is no set, the output terminal will be undefined, and the TSS will fail.

If it succeeds, his code won't do anything.

[CL_eisenwr]

Mcduff: I looked at the set VIMs, but they do not have assertions. They just seems to be relying on the set functions used to break when something other than a Set is input.

wiebe@CARYA: I tried your idea with set function; however, it did not work as I hopped. When an Array given instead of a Set, the VI/wire were not broken unless I enable the case.

Basically for now, it looks like I have to do what altenbach suggested. Hopefully there will be an assert set added in a future version of LabVIEW. (Idea filed)

[CL_eisenwr]

My real issue is with arrays being input, so I could do an Assert Mismatch with an array of every type. However that feels a very long way to do this.

[AristosQueue (NI)]

As I posted in the idea exchange, there shouldn't be a need to do an assert for set or map. Just do the operation. There are plenty of VIMs for sets and maps in their respective palettes. No assert nodes needed. Here is "Set Union.vim" for example:

Any non-set type will break this VI. And any set type will succeed. Exactly the desired behavior.

The assert nodes are really only needed when you want specific behavior for things that would otherwise coerce into a general case, like having different math ops for integers vs floats vs complex.

[AristosQueue (NI)]

PS: If you're doing something that only involves iterating over elements, why are you wanting to rule out arrays? Or any other type that we add iteration support for in the future? VIMs are meant to allow themselves to work on any type that works on the VIM's syntax. Ruling out types arbitrarily just limits the code reuse. Thus far, we have seen no VIMs that provide a good argument for that kind of limitation. If you have one, I'd be interested.

[CL_eisenwr]

AristosQueue: I see your point. Only reason I might want to break for arrays would be as to point users to the more efficient methods already built in for arrays.

[AristosQueue (NI)]

If you're worried about users not using the more efficient built-in methods, the easy trick is to put a TS structure in that handles only arrays and calls the built-in functions. That's similar to what I've done in the "Sort 1D Array.vim" that is in "vi.lib\Array\" directory of LV 2019 -- if you don't use any of the advanced sort terminals on the VIM, the VIM degenerates down to just the Sort 1D Array primitive. You can do similar for your operations.