Move (or at least copy) the Select function to the Boolean palette

[Darin.K]

I find myself asking two questions fairly frequently.  (1) Why is the Select function on the Comparisons palette?  (2) Why isn't the Select function on the Boolean palette?

Not only is the Boolean palette the proper location (IMO) for the conditional operation (not a comparison), but that palette appears in the right-click menu for items in both the Comparison palette as well as the Boolean palette.

[Darren]

Back when I used to use the palettes, I remember looking for Select in the Boolean palette on more than one occasion. Kudos.

[SimonH]

@Darren, when you used the palettes it was on the Boolean palette (or at least the same palette as the other Boolean functions):

@Darin.K

I suspect it is on the Comparison palette because it isn't a Boolean arithmetic or conversion function and it is an optimized shorthand for a comparison.

The select node is a more compact alternative to a case structure where the selector terminal value is compared against each of the cases and the correct case is executed (i.e. it's the same as a switch() { } statement in C).

So obviously this code is ridiculous but it is one way of thinking about what select is really doing:

switch(s)

{

  case TRUE:

      return t;

  case FALSE

      return f;

}

That's my best reasoning but I wasn't around at the time we decided to put it where it is. If this idea gets some backing I'll make sure the palette folks consider it.

[Darin.K]

> it isn't a Boolean arithmetic or conversion function
 

I'd argue that at its core it is a Boolean conversion function.  What is a Boolean conversion function?  You input a Boolean and get out one of two values based on the boolean input.  What does the Select function do?  You input a Boolean and you get out one of two values based on the boolean value.  It is therefore a universal boolean conversion function.

> it is an optimized shorthand for a comparison

I'd argue that it is far from optimized.  There is no short-circuiting (like with the Case Structure) so both inputs are always evaluated.  It is simply syntatic sugar.  I tend to only use it for choosing between two constant values, and the choice is driven as often by boolean operations as it is a comparison.  If it fits in neither, then I'd argue it should be in neither or both.

> it's the same as a switch() { } statement in C

It is actually seens much closer to the ternary if statement in C:  (expr ? true : false).  Only without many of the mystical powers  (some good, some bad).

[Jokelnice]

This is a good question.

[PaulG.]

Put the comparison in both palettes.

[SteenSchmidt]

I have no problem finding it where it is I must say, but that's of course mostly habit. I sometimes must think a moment to find the color box, but that's probably because it's in the numeric controls palette, yet in the Dialog & User Interface function palette...

/Steen

[JÞB]

I would support a copy but re-iterate my previous statement to please not move it - I know where that baby is now.  Don't make me hate you for fixing its location.  Sometimes I still get upset about View>>VI Hierarchy ursurping Window>>Vi Hierarchy's dominion

[Ray.R]

I agree with Paul

"Put the comparison in both palettes."

If it is removed from its current location, people will think it was removed 😄

It should have been in the boolean palette.  I use this function often and often look in the boolean palette by error.

[Ray.R]

"Put the comparison in both palettes."

If it is removed from its current location, people will think it was removed 😄

It should have been in the boolean palette.  I use this function often and often look in the boolean palette by error.

[altenbach]

Who really cares where it is parked if you use quickdrop! Right? 😄

I also don't think  "select" belongs in the boolean palette. Since it is a shorthand for a simplified case structure, maybe it belongs in the structures palette instead?

There are quite a few other cases of crossover primitives that have similar location flaws, for example why are "add array elements", "multiply array elements", "or array elements" and "and array elements" not in the array palette???

[Darin.K]

I also don't think  "select" belongs in the boolean palette. Since it is a shorthand for a simplified case structure, maybe it belongs in the structures palette instead?

I still think the stronger analogy is to Boolean to (0,1) where you can choose something else for (0,1).  That is why it is my instinct is to head to the Boolean palette.  Or would you suggest moving Boolean to (0,1) to the structures palette since by extension it is also shorthand for a Case structure. I think we are both engaging in a fallacy here: applying rules to a process which involves a committee.  (That is why many of those other inconsistencies you listed exist, IMO). 

So of the three suggested palettes (structures, comparison, boolean) I would apply the following questions?

Where is the structure? (implicit in the implementation)

Where is the comparison? (implicit in the implementation, classic boolean = TRUE or boolean = FALSE comparison we'd laugh at on the BD)

Where is the boolean? (right there smacking you in the face)

Clearly, I'd argue only one of those has an answer with no qualifiers attached.  User habit is a not-unreasonable excuse to copy the function.

So far I have managed to resist the urge to rant once again how much fun customizing the palettes is, and how it is even more fun trying to sync those changes across different machines and versions.

QuickDrop is a slippery slope here.  With modern context-aware autocompletion (like IntelliSense) and smart snippets I can get a ternary if in my C++ code in not-too-many more keypresses then the Ctrl-space+sel+enter.  A graphical, context aware tool is long overdue.