> The UI is a little different: integers don’t have many different parts the way floating point numbers do
Depends, they could if the site gave access to common varint formats for instance.
Also can't help but think it's the wrong way around? I feel like when you play with byte order you want to see how the bits change for a given number, rather than the number for the same bits. Though I guess both are valuable, depends on your use case (whether you have a bit pattern and try to understand what it is, or have a number and try to see how it would encode).
Exploring signed representations could also be useful.
You just didn't happen to hit that particular thing in that time, there'll be a long list like that for all coders. The subset of coding and computer science anyone interacts with will always be small compared to the entirety of the field.
Having 1000...0001 represent -1 would be sign-magnitude representation. Having 1111...1111 be -1 is two's complement. Computers usually use two's complement for integers, because it makes addition and multiplication really easy to implement. Floating point actually is closer to sign-magnitude, though.
And sign-magnitude representation would lead to +0 and -0 being two different bit patterns, which would mean == on integers couldn't be a direct byte comparison anymore. Undesirable.
Depends, they could if the site gave access to common varint formats for instance.
Also can't help but think it's the wrong way around? I feel like when you play with byte order you want to see how the bits change for a given number, rather than the number for the same bits. Though I guess both are valuable, depends on your use case (whether you have a bit pattern and try to understand what it is, or have a number and try to see how it would encode).
Exploring signed representations could also be useful.