[2.0.73] Inconsistent overflow behavior for input into different combinators

[canadavid1]

To reproduce:

In a constant combinator, add a signal and make its count 9876543210
Similarly, in a decider combinator, change the constant being compared to to 9876543210

Actual result:

The constant combinator gets a value of 1286608618 [wraparound]
The decider combinator gets a value of 2147483647 [saturating to maximum 32-bit int]

Expected result:

Both interfaces should result in the same value, either by saturation [capping to the maximum/minimum 32-bit int] or wraparound [essentially doing modulo 2^32 as when doing addition]



All other entities tested (arithmetic combinator, selector combinator, an inserter) saturate to 2147483647

Likely related to viewtopic.php?t=128129 where constant combinators were made to add with overflow arithmetic.

As a combinator nerd, I would prefer for it to overflow. This is also consistent with how addition along a signal on a wire works

[Nidan]

In the linked thread, the constant combinator has multiple specifications for the same signal, where I agree that following regular circuit behaviour / wrap-around makes sense.
Since you don't mention using multiple input fields, that reasoning doesn't apply here.

What I'd prefer: Each input field clamps to the allowed range, merging multiple signal definitions (*) uses circuit behaviour / wrap-around.

*) e.g. a decider with multiple outputs using the same signal or the constant combinator in the linked thread

[canadavid1]

I know that they are not exactly the same, but my reason of linking it was that that was an example where constant combinators were explicitly made to wraparound, potentially being the source of this inconsistency. I also seem to recall (but am not able to verity at the moment) that they all saturated in previous versions (1.1).

But yes, I think we agree on the stated problem/inconsistentcy

[boskid]

Duplicate 116956