BreakPoint
Rube Goldberg Code
Biggest problem I have is that getting the class name (or even a class ID) from a (Generic) reference is (relatively) slow.
Pretty sure I exhausted all options. For instance, getting the type data and a LUT isn't faster (and could be much slower if the type data is large).
The only up side is that the simplest solution (the property node) isn't slower then all other solutions. But I still would like it to be faster.
I might try to store the class ID with the reference (it's in a class) to avoid getting the class ID more then once, but it's a lot of work, adds complexity. And it might do nothing. I guess a PoP is the way to go.
Search LabVIEW like a graph! 
No because in this mechanism, an error means "this case failed, try the next one". A shift register would propagate the error to the next iteration and cause an infinite loop. The last (Default) case does nothing and ensures the loop is exited after unsuccessfully trying every case.
Additionally, I voluntarily took the blue property node out of the error cluster because the object might not have a label, which should not cause an error.
Ways to create a unit circle in complex datatype (seen here )
(also, xy graphs understand complex, so converting RE/IM to a X/Y bundle is not even necessary)
@altenbach wrote:
Ways to create a unit circle in complex datatype (seen here )
(also, xy graphs understand complex, so converting RE/IM to a X/Y bundle is not even necessary)
Oh but what a pretty implementation of [e^i*pi+1=0]
So, if you have a race conditions due to blatant overuse of local variables, one "solution" would be to wrap a two iteration FOR loop around the entire code so the local variable no longer has a stale value the second time around. 😄 (seen here and also see my comments)
Occasionally, even NI produces Rube-Goldberg code!
Granted, this code is probably 30+ years old and lot of things have changed since then.
Maybe this was perfectly good code back then, 😄
So, for entertainment, let's have a look inside Draw rectangle. Note that there is some suspicious orange parts and the division by two is done twice in parallel (I am sure the compiler will simplify it!). So what does this inflating excursion from 2 bytes (I16) to 8 bytes(DBL) and back to 2 bytes(I16) actually do?? Scratches head while staring at it!!!!
The nice thing is that I16 is small enough so we can easily test the entire domain (-32768 .. 32767) of the function and It turns out that the result is either 0 or 1, and it is 1 for all even inputs and 0 for all odd inputs. (Red code below)
I am sure there is a simpler way, right?
Here's one possibility (green). I am sure there are other, equally simple solutions:
Increment by one and then AND 1 would do the same. It's probably only nanoseconds difference if you do an increment or an integer complement if any at all.
This would be faster than both the not and the add on the variable input.
The not on the constant will be constant folded...
