[2.0.20][Hrusa] 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.

[Rseding91]

Does this still happen on the latest release? I believe there were several cases like this fixed at some point.

[Gegell]

Does this still happen on the latest release? I believe there were several cases like this fixed at some point.

Yup, I just tried it in 2.0.43 and it still happens. As far as I can tell the following input fields have this behavior:

• Decider combinator: Both the constant you compare with against in the input, and the constant when you set it in the output slot.
• Arithmetic combinator: When setting the constant on either side.
• Selector combinator: When setting the constant in select input (not as relevant, but would still be an inconsistency w.r.t. constant combinators)

Simple test: Enter 0xffffffff in the input fields, which should wrap to -1 but instead turns to 2147483647 instead.

[Rseding91]

Sorry, I'm pretty sure it was fixed in that it *doesn't* wrap, but clamps to the best acceptable value.

[quyxkh]

Problem with that resolution is, hex is used to specify bits. The "best acceptable value" you're choosing doesn't have the specified bits.

In a game where the equipment uses signed-32-bit-wrap arithmetic (and for instance with filter setting the game mechanics *rely on it*) refusing to wrap input values is just wrong.

[Gegell]

Sorry, I'm pretty sure it was fixed in that it *doesn't* wrap, but clamps to the best acceptable value.

For constant combinators the behavior is still wrapping, so the original bug that there is a discrepancy between input methods between the different combinators is definitely still standing.

And I strongly agree with @quyxkh that the consistent input behavior for hex should infact be wrapping