Allow "In Range and Coerce" to accept unwired limits

[fabric]

Currently, the "In Range and Coerce" function requires that the upper and lower limits be wired. Often I am only interested in coercing at one end of the range. It seems crazy to wire "-2147483648" to the lower limit of an I32 just to ignore that input and coerce the maximum...

I'd like to propose that this function allow unwired limits, and that unwired limits assume the maximum or minimum allowable values for the given datatype:

[JB]

Nice idea but why not using the Max & Min function ?

[Mads]

Max & Min does the trick, but it is more intuitive to grab the In range and Coerce node, so kudos from me.

[vitoi]

Problem is it's not fail-safe. What happens if you just didn;t get around to putting in the required value. Maybe right clicking on the terminal and having the option of selecting max or min, whihc would then connect the appropriate contant woudl satisfy the need and still be fail-safe.

[fabric]

@JB: Because I never thought of it!! Just did some quick benchmarks and Max & Min seems to be faster too. Nice tip! 

So why do we need this idea?

1. As Mads pointed out, most people will probably go for coerce because its behaviour is more obvious and intuitive.
2. This is the better solution if you need the "In Range?" output.

@vitoi: "not failsafe"?? Sorry - I don't buy that! There are *many* functions that allow unwired inputs and we don't complain about those! Should we make ALL inputs required on all functions?! 

[_Y_]

I agree with vitoi, this opens more room for mistakes (and even more than usual because the default limits will depend on the data type). IMHO less defaults = better code.

However, the idea can be slightly modified. Pop-up menu of "In Range and Coerce" has "Include ... limit". Add third option: "Include ... limit" - "Exclude ... limit" - "Ignore ... limit". It will do the same but avoiding hidden values.

[altenbach]

We don't need the third option. When an input is left unwired, the current diamond glyph should turn into an X or similar. When wired again it should restore to the previous setting.

[JÞB]

Kudos But "X"s mean broken How about just a half diamond (filled) we wouldnt want to exclude the bounds.  Lets make one more small change on the glyphs while we are improving this function.  Automatically fill the diamonds and disable RCM Exclude bounds when an Int datatype is wired.  Purely cosmetic, since there is no functional difference between the include and exclue options on integers, but much more intuitive for new users.

[JÞB]

The current lack of fill for integers is probably a bug we forgot to report anyway

[altenbach]

> ...  But "X"s mean broken ...

A black, thin x would probably not mean "broken", but I did not spend a lot of time reflecting. That why I said "or similar" 😄

Here's a better idea. If one of the two inputs is unwired, the respective glyph should turn into an ellipsis. (...) (or possibly three vertical dots)

(This is similar to numeric case structure ranges where e.g. "5.." means five or higher or "..-5" means -5 or lower. Well, cases only have two dots, but who's counting :D)

[TCPlomp]

It shold default to +Inf and -Inf for floating point numbers or the equivalent value for integers.

Ton