I would like to have the ability to set the compare aggregates mode for comparisons involving containers (arrays certainly, clusters would be a nice bonus) and a scalar value. This includes the comparisons to 0 functions as well.
But wouldn't the result always be false? What would the logic behind the node be?
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
I thought of that scenario right after I posted my question. I was hoping that would be your response. You got my kudos.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
As well as reducing memory usage by not creating a boolean array (or cluster), it would also be quicker by stopping the comparison as soon as it found a FALSE value. This is an equivalent (and I guess would be an easy XNode, though perhaps not for clusters or all the comparison corner cases) but would be nice to have built-in.
> Logic is the same as putting 'And Array Elements' after the node.
I remember a discussion long ago where I was told that putting an "And array elements" is not exactly the same in all cases and that compare aggregates is somehow special.
Of course it would be nice if we could configure the node to either "or array elements" or "and array elements". Would that be useful?
Or could be interesting, there are situations where it would short circuit faster than negating the opposite comparison. For example any element =0 would be not(all elements !=0).
What I like about the idea as it stands is that it really does nothing new. It adds an option for situations that previosly broke your VI, and adds an existing, familar option to a different set of functions (whose main purpose in life is to save you wiring a 0 to the corresponding comparison node). Adding OR to the mix creates an entirely new option so I would call it a nice-to-have instead of a must-have. At least with the AND option there would still be a way to avoid the unneccessary boolean array if not the optimal short-circuiting.
I think if we did this, we would have to add both the And and Or modes because I don't find one to be a more intuitive default than the other myself. But that's such a minor thing, I don't think it would get in the way of implementation of this feature if this gets acted upon.
Are there standard glyphs we could add to the node to differentiate And mode from Or mode?
Adding the Or mode does seem to open a bit of a can of worms for an effect than can be as efficiently achieved using negation (which could also be incorporated...). The And mode maps perfectly to the operation of broadcasting (building a virtual structure of the same shape as the other input) and then comparing aggregates. The Or mode is new and I support it fully so long as the usual fear of newness does not interfere.
If it were up to me I would give the node the shape of the boolean operation (And/Or) and then use the internal glyph (>,=0?, etc.) of the comparison operator.
