[2.1.11] Entering hexadecimal numbers to number fields does not correctly handle sign

[theaigcaman]

What did you do?
Tried to use a bitwise AND operation to isolate the most significant bit of a signal and entered 0x80000000 for the constant. Discovered on 2.0.77 with mods and tested again on 2.1.11 (Linux) without mods.

What happened?
The hexadecimal input of the constant was interpreted as maximum signed integer (2147483647).

What did you expect to happen instead?
I expected the hexadecimal input to be interpreted as raw binary which then gets represented in the game as a signed integer. I expected to get a -2147483648 by entering 0x80000000.

Does it happen always, once, or sometimes?
Happens always.

More detail:
When entering a hexadecimal constant into a number field, entering 0x80000000 returns 2147483647 instead of -2147483648. Same for any hexadecimal number >0x7FFFFFFF
Hexadecimal value entered into field:

Enterd_hex.png (12.66 KiB) Viewed 327 times

Resulting decimal constant

Returned_constant.png (42.84 KiB) Viewed 327 times

The main use case I see for using the hexadecimal input is for handling bitwise operations (which is where I discovered this), and this makes it extremely annoying to interact with the most significant bit of the signal, requiring manually entering the appropriate negative decimal if your constant includes a 1 in the MSB. For example, you need to manually enter -2147483648 if you wish to do the following bitwise and operation for isolating the most significant bit:
signal-0 AND 0x80000000

[eugenekay]

What did you do?
Tried to use a bitwise AND operation to isolate the most significant bit of a signal and entered 0x80000000 for the constant. Discovered on 2.0.77 with mods and tested again on 2.1.11 (Linux) without mods.

What happened?
The hexadecimal input of the constant was interpreted as maximum signed integer (2147483647).

0x8000 0000 (2147483648) is greater than 0x7FFF FFFF (2147483647) - the published Maximum, and you are reporting that it is being clamped to the Maximum? What is supposed to be wrong here?

Numbers are in the signed 32 bit integer range, i.e. from -2147483648 to 2147483647 inclusive

While it is true that combinators will wrap values calculated above this value to negative, I do not think this has ever applied to values entered. You can do bit-shift calculations by using the Division / Remainder functions instead.

[robot256]

Long ago, some number entry fields saturated and some rolled over. This thread documents the reason they changed it so that every number entry textbox saturates. 116956

Basically, the hexadecimal syntax parser is part of the equation parser, so you can do math with both hex and decimal numbers. It's important for usability that equations saturate instead of roll over. The devs didn't want to make a special case where entering a singular hex number treats it as unsigned/rollover but everything else is signed/saturates.

[eugenekay]

Long ago, some number entry fields saturated and some rolled over. This thread documents the reason they changed it so that every number entry textbox saturates. 116956

A-ha! This change was not in the 2.1.7 Release Notes. And it was only some input boxes, which is why I had not noticed it previously. Inteeeeresting.

I am glad it is (supposed to be) consistent now.

[justarandomgeek]

fwiw, you can still (and always could) enter the sign bit/minint as its actual value, -0x80000000