Negate option on Comparison functions

[gamberetto]

I would like to have the possibility to "negate" some comparison functions such as "Empty String/Path?". This can avoid to add the "Not" operator.

The picture below is a possible implementation. The dot on the input (on the output ok also) is showing the negation.

This might be good to be implemented for the following functions:

[crossrulz]

Similar: Array/String not empty function

[AristosQueue (NI)]

Wearing my LV R&D hat: We could do this if enough customers thought it was a good idea.

Wearing my LV user hat: I loathe those way-too-easy-to-overlook circles. If we're going to add a "Negate" option to a node, I want the node to be drawn like this:

I would also be ok with something like this:

[ibberger]

unluckily i can not change my login name to "enough customers" ... 😉

you're right, those small circles can be easily overlooked. Please make them a bit bigger, and maybe fill it black? Thx!

[gamberetto]

At first glance I agree about the circle size, nevertheless I used the same size of existing boolean operators (see picture). I would just put the circle on the output of the operator as in "Not And"...

[Dmitry]

1. I think 'negate' circles should be consistent with the Compound Arithmetic primitives (as suggested above)

2. Circle size - I am OK with the current size. Never had an issue with 'missing' negation other than being distracted by something else or when working longer hours than one should ... Actually, 'large' circles (as suggested by AQ) would make reading diagrams harder as they tent do shift attention off the primitive itself.

3. 'Negate' at the base of 'Not' primitive should go away - I did get used to it and do not pay attention any more, but it may be confusing to new users - implying there is an extra negation applied before executing 'Not' ...

[Michael_78]

I like it, but could get confusing.

'Empty String/Path' would become 'Not Empty String/Path'

But 'Not a Number' becomes 'Not Not a Number' That is not ok, (not not ok, ok?)

 still works for me as it is what we currently have to do, it just makes sense to combine the logic this way.

[DavidBoyd]

Adding nothing, really, to the discussion here, except to show one of the (IMO) more difficult-to-spot inversion bubbles - the one that is coupled to an error cluster wire.  Or is it just my old eyes? (First and third inputs on the compound node are inverted, in case you need the hint.)  If you try this, notice you can effect a minor change to visibility by nudging the node left/right relative to the error wire pattern.

Inverted boolean on error wire

[ibberger]

David,

just because such an option exists it does not mean you have to use it every time. It's the programmers decission to create good readable code or bad, unreadable code.

[DavidBoyd]

Well, I'd argue that there's nothing wrong with the intent; NI has chosen to make most nodes that accept Boolean inputs polymorphic so as to accept the error cluster, which seems conceptually clear to me. And they've chosen to show the inversion "bubble" wherever the intention is to show negation on input or output - again, conceptually clear.

i was just highlighting the (IMO) unfortunate visual juxtaposition caused by the bubble's size together with the error wire pattern.

[AristosQueue (NI)]

ibberger: But we need to also take into account the *reader* of code, not just the writer. The writer may think that X is perfectly readable, but if a significant number of readers think that Y is not readable, adding it as an option for writers to use is often a bad idea because some of them will then choose to use it. That's a rule of thumb... there are exceptions... but that is why just because someone does like it doesn't mean it can be an optional thing.