[2.0.20] Base 16 number with highest bit set saturates if used as constant in arithmetic and decider combinator

[Gegell]

When setting the values for signals in constant combinators using the new 0x prefix it works as I'd expect (as in all 32 bits are set to the entered value). The same does not occur when setting the constant value in arithmetic / decider combinators.
If I try to set the constant to a value which includes the sign bit, e.g. 0x80000000 (= -2147483648) or 0xffffffff (= -1) it seems to clamp the value to the largest possible 32 bit integer 2147483647 (= 0x7fffffff) instead.

This is inconsistent behavior, compared to setting the signal values in the constant combinator.
Thus I assume this to be a bug.

BP with a small setup, which showcases the issue:

0eNqdlM2O4jAMx18lyml3VRCU8ilx2HmAPe0NUJW2hkZqk27isiDUd18npcAgBma2vbRO/Lfzs+MTT4oaKiMV8sWJy1QryxerE7dyp0ThbEqUwBdcGIl5CSjTXqrLRCqB2vAm4FJlcOCLYRM88MoglRmYxy5hswk4KJQooY3qf46xqssEDGkGnY7LC4XCW6GAV9qSr1YuIOn1hpP+OOBH99UfU5xMGkjbDVHgNNDoIk4gF3tJAuRl23X7/psy6U4V8K0sEMy9FY+Vy2svDdZ04kuiLYHeT7L8oQU6DRmVNqXfRNlXwvjsF3zpDbUj3/P0Oiwv1d++qB4Oo2k0G02iWbOhl8hUhTiCiTOwqZFVi4ivzvF6bZhld5YNk5ZZQLaXgmEOrKsGGxy252etPvB+e+Y9G7TPWq3VL41A6wJZojFne0GNaZljAhn7a0TFhKHzZExYBoeKiuXsOSgnjlLtvHgikVUCqWKKfJlgo9DbXDa0n/ocdmD63PG+67YweNK1D5otaltt8MlWO4vGtJbJS9Pd/q1Olz6nbLqaTd0t0TVWNfo9Twr42xw9B+15v2NNtitu9m3Jbpriuy9NDgcmCku+AmvqIoLvnabnChM7iyCyh+xGwfM58TG+z97Uq+4dwa00FuPr5Hlxd0CkuZtBdNtJJn4EnHBXQARaqD/4f/PuLofnPbxifk2YSi4RSopxnc8B39Mc8pHHk3AezefjaDoKB6Nx0/wD8pv4qg==

Copy blueprint

[robot256]

This is an interesting case because having a positive number entry roll over to a negative integer can be either very useful or very unexpected depending on the circumstance. I agree it should be made consistent between combinators.

[doktorstick]

That there's a difference between base10 and base16 behavior is the real problem. In other words, if they clamped it to positives on all three combinators--while now consistent--would be incorrect as it forces a user to use base10 for negative numbers.

[Gegell]

That there's a difference between base10 and base16 behavior is the real problem.

I do not believe that there being a difference in behavior for the different bases is an issue. As robot256 said, either behavior can be useful depending on the context you use it in. Think of the following 2 examples:

If I want to use only the natural number aspect of the signals (e.g. addition, multiplication, division, mod, etc...) I will most likely enter the numbers in base 10. In this case it makes more sense in my mind that numbers do not wrap around but instead clamp to the largest / smallest possible (depending on the sign), as seeing a base 10 number mod 2^32 always looks quite weird. Clamping would at least preserve the sign of the originally entered value. This usecase is also what I assume the most common one when users work with combinators.

On the other hand, whenever I want to do exact bit manipulation (e.g. using bitwise and, or, xor in the arithmetic combinators) I'm astutely aware of the the underlying int32 format which is used by the signals. In this instance I'd rather be surprised if the hex number -- which should specify all bits of the format exactly -- is changed to a completely different value instead. Thus in this case the "wrap around" is the more sensible option in my opinion, as this does not change the underlying bits (hence the quotes on "wrap around" -- the entered information is not changed)

[robot256]

It would be fine to infer "unsigned truncated" interpretation if hex or bitwise syntax is used anywhere, as long as we had operators to force it back (e.g. "bit()" and "num()"). And of course make it consistent across formula fields.

If we're stuck with the expression parser, might as well make the most of it.

[posila]

That there's a difference between base10 and base16 behavior is the real problem. In other words, if they clamped it to positives on all three combinators--while now consistent--would be incorrect as it forces a user to use base10 for negative numbers.

FYI, you can just use sign in base16 as you would in base10: -0xffff

[Gegell]

That there's a difference between base10 and base16 behavior is the real problem. In other words, if they clamped it to positives on all three combinators--while now consistent--would be incorrect as it forces a user to use base10 for negative numbers.

FYI, you can just use sign in base16 as you would in base10: -0xffff

You can use the unary negation, but I argue that this is not too helpful in this case, as changing the sign changes more than a single bit, e.g. -0x8000_0000 = 0x7fff_ffff which personally I again find to be a hassle to work with (in the context of bitwise operations, I just want to be able to directly set the bits).
What I currently do as a workaround instead, if I want to set bits individually, is just writing out the full 0x... and if the highest (31st) bit is set, then I subtract 2^32 i.e.:

• For values 0x0000_0000 - 0x7fff_ffff just input them just like that (omitting underscore)
• For values 0x8000_0000 - 0xffff_ffff enter 0x8000_0000-2^32 to 0xffff_ffff-2^32

This works, but is more annoying than it should be for a QoL feature imo. Especially seeing as it does work as expected (with wrapping) in constant combinators -- it only clamps when setting constants in arithmetic/decider combinators.