Representation is context
A hexadecimal or binary string does not automatically tell you whether a value is signed, how wide it is, whether bytes are little endian, or whether the bits represent an integer or floating-point value.
Bitwise results depend on fixed width and signed interpretation. Keep those choices visible when comparing outputs.
| Row | Bits |
|---|
Verify AND, OR, XOR, NOT and shifts with fixed-width masks, signed and unsigned interpretations, popcount and Hamming-distance evidence.
A hexadecimal or binary string does not automatically tell you whether a value is signed, how wide it is, whether bytes are little endian, or whether the bits represent an integer or floating-point value.
The same binary pattern can represent different numbers depending on word size and signed interpretation. Fix the intended width first, then apply masking or two’s-complement rules consistently instead of interpreting an unbounded JavaScript integer after the operation.
Logical and arithmetic right shifts differ for negative values, and some languages mask the shift count. Match the calculator operation to the target language or protocol when reproducing code behavior rather than assuming every environment shifts identically.
When extracting flags or packed fields, write the mask in binary or hexadecimal beside the operation. This makes it easier to verify which bit positions are included and catches off-by-one positions that decimal output can hide.
Fixed-width hardware and file formats discard bits outside the selected width. If a result exceeds that width, show the masked value and, when useful, the unbounded intermediate separately so truncation is visible rather than silently changing the number.
A decimal result can hide a single-bit mistake. Re-express the operands and result in hexadecimal or padded binary and inspect the affected positions. That representation check is especially useful for XOR flags, bit clearing and signed high-bit behavior.