Assert structural type match with growable y inputs behaving as an or logic gate

[jacemdom]

Would allow to reduce the complexity and number of frames needed in a type specialization structure when the action is basically the same.

For example in the attached vim, the number [2] frame could be used for all number types and thus eliminate all the following frames.

[wiebe@CARYA]

In this example, why is the type match even there? The !0 already excepts all numerics, so it seems to do exactly what the type match is for.

[wiebe@CARYA]

[ignore previous post, got a authentification failure, but it was posted anyway]

In this example, why are the numeric type match's even there?  The !0 already excepts all numerics, so it seems to do exactly what your type match is for.

The type match in the Boolean case is also redundant. If the input is a Boolean, the wire will fit the Boolean. If not, next case...

The type match in the error case could be removed, but the case will accept all clusters with a Boolean as 1st element and two other elements. That could be a bug or a feature...

[jacemdom]

[jacemdom]

A growable assert type would simplify cases where i would like to have more control over what types would be accepted let's say by the != zero function or any other situation where more control is required and multiple types could be managed by one frame.

Also, another argument is that I don't believe it would be a big developement effort but then, I didn't build the thing 😉

[AristosQueue (NI)]

Look at the existing VIMs in the Assert palette and how they are written -- you can code an Or today already by using a VIM subVI in your frame. Just follow the pattern shown.

I've created for LV 2019 a new growable node for "not equals". I intend it to be in the next release, assuming it passes beta testing.

wiebe@CARYA wrote:

> The type match in the Boolean case is also redundant.

You are incorrect. In the Boolean case, the output tunnel would adapt to be whatever type was wired, so all types would be accepted through that case. The effect further downstream would not be considered by the structure node. Besides... the downstream node is the FPTerminal, which will adapt to type in a VIM (as intended).

> That could be a bug or a feature...

Indeed. And that's why the assert node exists: so the programmer can decide what the intended scope of flex should be. Polymorphism is a two-edged sword: It can provide too much flexibility, too little, or, oh no, it just morphed to have a third edge!

[AristosQueue (NI)]

> Also, another argument is that I don't believe it would be a

> big developement effort but then, I didn't build the thing 😉

So... since you (implicitly) asked... 😉

I built a growable node for the first time in my career for the 2019 release. Built three of them, in fact. They are... intricate. There is old, stable C code in LabVIEW... there is new, well-designed C++ code in LabVIEW... and then there's that period in the early 2000's that you might call our "art deco baroque whoa new C++ toys wow" period. The growable nodes were last refactored then. 🙂

My time to get a new growable node up and working to the point that it *does nothing* when you hit the run button (i.e., everything but the functionality behind it, which can vary wildly depending upon the node) is roughly 2 actual (i.e. not "ideal") weeks, based on the three I did this release. I did some code cleanup along the way, but it is still annoying.

[AristosQueue (NI)]

Jacedom: Specifically, if you wanted to restrict to only floating-point types, the Assert palette already has an Or to do exactly that. The numeric types is where we expected most people would need to slice-and-dice, so we put those in, pre-made.

[AristosQueue (NI)]

Even though there's a workaround (i.e. a way to build Or and existing VIMs for the common Or needs), I'm going to leave this idea open in case it accumulates lots of kudos or some use case that cannot be achieved without the Or node. But I don't expect it to be acted upon because this level of VIM authoring is something I expect to be and remain pretty niche.

[wiebe@CARYA]

wiebe@CARYA wrote:

>> The type match in the Boolean case is also redundant.

>You are incorrect.

Yes, clearly. My bad.

[jacemdom]

"and then there's that period in the early 2000's that you might call our "art deco baroque whoa new C++ toys wow" period"

Yep looks like It was time someone made me aware of the assert type palette lol thanks 😉

Thanks also for the pointer in using a vim as a type checker. I am still slowly learning to think in a "vim" way!

I checked some of the vims in the palette for numerical checks and I believe they would be much slicker and much faster to build using a growable node...only one frame needed...but won' t wait for it and in the end although less "pretty", using subVIMs as type checkers will most probably cover all my needs.

I think we never can say enough how much we appreciate things and to all implicated in making VIMs a reality...super thumbs up  It's for me the single most awesome feature in LabVIEW for a very long time 

P.S. You can close this idea if you want to, my main goal was to find a way to do something i didn't see possible but that was mostly because I am still learning to use VIMs. Even while building my VIM and posting this, i had a strange feeling I was missing something and indeed I was!