I don't think I've noticed the color of the autoindexing terminal before now. So if the regular terminal changed to match the Boolean constant, I don't think it would be confusing at all - one terminal always means "True".
But I would reinforce my suggestion above to replace the "?" with another symbol to make it clear that this is a dual T/F terminal. Perhaps the stacked T and F were too crowded, but there might be another option.
Unfortunate, but safe. Would be nice to avoid, especially if people do this often (I do this sometimes, and the Not terminal is quite large compared to the tunnels)
Presumably listed only for completeness. I assume this is a non-starter.
I think this might improve readability of existing code (since wire will match "true" terminal more closely) but obviously does change from what is the established system. I'd be fine with this though...
This is OK for e.g. numerics but seems very likely to cause double-takes if I look at code outputting a boolean array, as shown in PJM_JKI's post on the 23rd Aug.
As a possible alternative, would creating a box (within the terminal box) of a different color (red, maybe, or black?) be possible for the false output? I'm not sure there's any space, but it could perhaps be clearer. Vertical lines on the edges might also work if there isn't room above and below the [ ] symbols.
Color-only differences are pretty bad for colorblind folks, and we try to avoid those at all costs these days. Also, true red is a color we try to reserve for "this needs to disappear from your diagram" -- red Xs, coercion dots. It's not a hard-and-fast rule, but pretty well respected.
Regarding the vertical bars, can you post an image of your suggestion? I'm not visualizing it.
re. color-only differences - I hoped that the lines/shape would also provide a non-color-dependent indication, but yes, perhaps my suggestion is a little overly dependent on color to help visualize the difference.
re. Red, yes - I suppose I've noticed this and should have considered that usage. I suggested red since it isn't used in any built-in datatypes (at least that I can think of).
re. vertical bars, and copying from an earlier image, I had imagined that a box might be too large to draw and would cover the [ ] symbols, but it turns out perhaps not, so here's my thought. I'm not sure if it really helps though - looking at it doesn't really scream "this is the opposite of the other output" (whereas inverted colors in the style of previous suggestions might).
Highlighting of the "false" output
I also suspect this might be susceptible to problems with scaling on different monitors...
Below is an image showing what I meant with red, although I guess it's a non-starter.
Perhaps a clearer demonstration. In this case, black boxes seem significantly less clear?
perhaps can consider using a neutral 'darker' tone of pale lime yellow to indicate the false case (check in gray-scale intensity also, to ensure sufficient tone distinction). this can probably ease the data type convention default true = solid, false = white, inherited from Boolean.
but then this got me thinking, it must be used with both case present in order to distinctively notice the NOT operator from its tone. or better still...
back to the general idea, wouldn't it also mean that this idea will only be used for one and one case only, if both cases must be indexed and passed on, with no other conditions? is it really beneficial over the existing conditional tunnel in terms of readability and probably performance (if used incorrectly).
however, if the existing conditional tunnel is to be given an integrated NOT operator (perhaps with a circle before the ?), I'm in.
Honestly, I agree with AQ on this one. The proposed syntax is too clunky for me. I really think the right option is to simply allow for another false conditional terminal. Just create another indexing terminal with the false condition if you want both arrays. It would be easy to read, allow for clean block diagrams, and it is useful in many situations.
>Snippets don't work without the sub vi(m)s, but the idea is clear...
yeah I noticed there is no place to upload snippets, so I just drag it into the "insert photos"
@wiebe: unfortunately no, only penalty... unless the boolean array is already known from the start, no further calculation nor evaluation per element of the array needed 😅 quite specific use case
