Properly handle negative values

[Manderby]

A recurring request from users because it is confusing. Try to find a solution for this.

This was the best answer I could give to the users so far why it is implemented this way right now:

---

Bit Fiddle will always assume the input to be unsigned. This may seem as a limitation at first but distinguishing between unsigned and signed input proved both to be confusing for the users as well as unpredictable when working with custom byte sizes. In order to properly convert 0xff to -1, you therefore need to write ff in the hex field, set the conversion to the two's complement and manually add a minus sign to the decimal number. This turned out to be easier to understand for most people.

---

Here's another text which was an answer to an email of a customer once which explains all in detail:

---

Of course, you are right that the upper 32 bits of an unsigned integer should be zeros in 64 bits. Bit Fiddle does not do that. There are other people who have asked the very same question. But this strange behaviour is actually by design.

Here's why:
Bit Fiddle is designed to do basic conversions. But converting numbers can be way more complicated than what you see in the (already rather complex) UI. In a really sophisticated application, you would need to define for each and every input and output number:

1. How to interprete the entered number (what numeral system, decimal dots, special characters, ...)
2. How to store the binary representation (encoding, endianness, number of digits)
3. How to convert the input representation to the output representation (while knowing the same thing like in 2 but for the output value)
4. How to get from the store back to the destination numeral system (while knowing the same thing like in 1 but for the output value)

Right now, Bit Fiddle does the following (See help menu of Bit Fiddle for more info): Numbers can be entered as decimals, binaries, hex and asc. All input values are interpreted as positive numbers. Then, they are converted into an internal binary format which always contains a multiple of 8 in binary digits. Then, before converting them back into dec, hex and asc, these digits are extended to the different output sizes. Bit Fiddle does this extension arithmetically, not logically, meaning if the first binary digit is 1, all higher order bits become 1 as well. This is done because this otherwise poses problems when for example entering a the binary number 11111111. What is the 16 bit representation of that? It could be 1111111111111111 (256) or 0000000011111111 (-1), Bit Fiddle does not know as there is no way a user can define how the result shall be interpreted.

It is important to understand that the tabs "unsigned", "1's complement" and "2's complement" only denote the conversion which happends on the binary layer between steps 2 and 3. They do not define any kind of how the numbers should be interpreted, both input and output. It is though common nowadays, that users use signed integers and therefore, any interpretation which is shown in the output fields is generally emitted as a signed integer. Therefore, the arithmetic extension makes completely sense and a logical extension with zeros whoud in many cases be wrong.

Therefore, your bug happends exactly when the 8-bit padded binary representation of the input value has a 1 at the most significant bit. Then, the arithemic extension fills the upper bits with 1 instead with 0.

There is another reason for this: Adding padding zeros to any kind of numeral system is trivial and I believe, most users do not have a problem to extend a 8 bit value to a 32 bit value by simply adding zeros. Adding ones though may not be so straight forward, as there is no indication which of the ones originally did contain the highest order information. And when using non 8-aligned numeral systems like for example the octal system, the high order digit might even change its value. (for example 1111111111111111 in octal is 177777 while 0000000011111111 is 377).

The whole situation is frustrating, also for me, as people write me mails and bad reviews claiming the result to be wrong. But if I would do it otherwise, other people would claim the other result to be wrong again. And extending the implementation to a state where the user can define everything... Well, have a look. Find attached a hidden UI inside Bit Fiddle. It is not usable but I tried to add an "expert" Mode in several past versions already. I always scraped the idea as it quickly became way too confusing for users. And that example seen below was just a "reduced" expert mode without intermediate conversion for only one single value.