The In Range and Coerce "Include upper limit" option should be selected by default

[Petru_Tarabuta]

Idea: The In Range and Coerce Include upper limit option should be selected by default.

Maybe it's just me, but when using the In Range and Coerce node I virtually always need to have both the Include lower limit and Include upper limit options selected. In approximately ten years of using the node I think I used a different configuration less than five times. It has entered my muscle memory that the first thing I do after dropping the In Range and Coerce node is to right-click it and select Include upper limit.

In my experience this point of view is supported by anecdotal evidence. For example, I have recently seen a large codebase that was rightfully using lots of In Range and Coerce instances. All of the nodes had been left in their default configuration (Include lower limit selected, Include upper limit unselected). However, after inspecting the code carefully I came to the conclusion that the intention was for all of the nodes to perform an inclusive comparison on both sides. This was confirmed by a conversation with the original code author. The author had simply been unaware of the true behaviour of the node (he had assumed it performs inclusive comparison on both ends) and was unaware of the right-click options!

[raphschru]

It is hard to give strong arguments for such a minor design choice, so here are some of my use cases where I find the current default setting more relevant: 

1. Checking against integer rectangles.

Everywhere in LV where I have seen integer bounding boxes / bounds / rectangles representing a graphical element, it comes in the form of a "top-left" coordinate pair and either a "bottom-right" coordinate pair or a "width-height" value pair. The "top-left" is always included and the "bottom-right" is always excluded. This allows convenient relations such as "top-left" + "width-height" = "bottom-right" without the need to subtract or add 1.

Some examples that use this logic are:

 - GObject properties "Master Bounds Rect", "Total Bounds Rect".

 - NI Vision VIs taking a rectangle to apply the processing to a specific part of the image (IMAQ Resample, IMAQ Expand, IMAQ Extract...).

So for example, in order to check whether a point lies inside a rectangle:

2. Checking against uniformly distributed floating-point random numbers.

As you may know, primitive "Random Number (0-1)" generates a random number between 0 included and 1 excluded (and for a good reason). So for example, to check correctly whether the generated number is in the first half of the range or in the second half, you would do:

I guess this is the testing / engineering point of view versus the mathematical / computer science point of view. The first leans toward more practical use cases for which LabVIEW is initially designed for, the second leans toward more general-purpose cases. In my opinion, the G language is general-purpose, so its primitives should stay as general-purpose as possible.

Regards,

Raphaël.