Return to Answer

What is a byte? Let's assume the modern eight bits.

What is the representation? What other values have to be possible in that representation?

Suppose we assume a pure binary representation which can handle all of the integers from 0 to 65535. In this representation, 65535 is represented by 16 bits: 1111111111111111. This requires two eight-bit bytes.

If the requirement is to have a representation that only handles the two values { 0, 65535 }, or any other choice of two numbers or symbols, we can encode that in as little as one bit: a fraction of a byte.

If we have to represent all integers from -65535 to 65535, using two's complement (or one's complement will need 17 bits, and that will require three bytes.

We can also think about handling the value 65535.0 in the smallest possible floating-point representation we can think of (which still resembles IEEE). The abstract mantissa corresponds to the binary representation and so requires 16 bits, valued 1. However, in floating-point, the leading 1 can be assumed and so it disappears: every nonzero floating-point value is 1.whatever x (base)^exponent: the 1 is always there, and so we don't have to dedicate a bit to it. Thus the mantissa requires only 15 bits. If we do not allow any exponent in our floating-point representation, only a sign bit, then we are back to 16 bits. But that's a "strawman" floating-point. Genuine floating-point should be able to float the point, so we need an exponent field. Not only that, let's make it a requirement that the exponent must actually encode the exponent value that is required, namely 65535 = 1111111111111111b = 1.111111111111111b x (10b)^1111b, as well as every lower exponent down to zero. Moreover, let's make it a requirement that negative exponents must be handled so we can represent small fractional values closer to zero than 1.0: all exponent values from -16 to +15. That requires a five bit exponent. Thus, in total, we need one bit for the sign, five bits for the exponent and fifteen for the mantissa: 21 bits. That fits into three bytes.

The number 65535 requires five bytes if it is represented as decimal t ext, where each of the digits is actually a digit character. In the USASCII code, which is a subset of Unicode, the digits 0 through 9 are represented by the character codes 48 to 57. In plain old seven bit ASCII formats, or 8 bit encodings such as the various ISO-8859-1 ("ISO Latin-1") encodings, these character codes occupy one byte each.

The character string 65535 could easily require more bytes of storage in memory if the string is made up of a character code point type that is wider than a byte. Other representational issues also arise such as meta-data: character strings have a variable length, and so an indication is required of where they end: a length field or null termination. In the C language, which uses null-terminated strings, the literal object "65535" claims at least six bytes of storage: five bytes for the content of the string, plus an additional byte whose value is zero, indicating the end of the string. A wide-string literal, L"65535", whose elements are of wide character type called wchar_t, commonly requires twelve bytes (two-byte wchar_t) or 24 bytes (four-byte, 32-bit wchar_t).

What is a byte? Let's assume the modern eight bits.

What is the representation? What other values have to be possible in that representation?

Suppose we assume a pure binary representation which can handle all of the integers from 0 to 65535. In this representation, 65535 is represented by 16 bits: 1111111111111111. This requires two eight-bit bytes.

If the requirement is to have a representation that only handles the two values { 0, 65535 }, or any other choice of two numbers or symbols, we can encode that in as little as one bit: a fraction of a byte.

If we have to represent all integers from -65535 to 65535, using two's complement (or one's complement will need 17 bits, and that will require three bytes.

We can also think about handling the value 65535.0 in the smallest possible floating-point representation we can think of (which still resembles IEEE). The abstract mantissa corresponds to the binary representation and so requires 16 bits, valued 1. However, in floating-point, the leading 1 can be assumed and so it disappears: every nonzero floating-point value is 1.whatever x (base)^exponent: the 1 is always there, and so we don't have to dedicate a bit to it. Thus the mantissa requires only 15 bits. If we do not allow any exponent in our floating-point representation, only a sign bit, then we are back to 16 bits. But that's a "strawman" floating-point. Genuine floating-point should be able to float the point, so we need an exponent field. Not only that, let's make it a requirement that the exponent must actually encode the exponent value that is required, namely 65535 = 1111111111111111b = 1.111111111111111b x (10b)^1111b, as well as every lower exponent down to zero. Moreover, let's make it a requirement that negative exponents must be handled so we can represent small fractional values closer to zero than 1.0: all exponent values from -16 to +15. That requires a five bit exponent. Thus, in total, we need one bit for the sign, five bits for the exponent and fifteen for the mantissa: 21 bits. That fits into three bytes.

The number 65535 requires five bytes if it is represented as decimal t ext, where each of the digits is actually a digit character. In the USASCII code, which is a subset of Unicode, the digits 0 through 9 are represented by the character codes 48 to 57. In plain old seven bit ASCII formats, or 8 bit encodings such as the various ISO-8859-1 ("ISO Latin-1") encodings, these character codes occupy one byte each.

The character string 65535 could easily require more bytes of storage in memory if the string is made up of a character code point type that is wider than a byte. Other representational issues also arise such as meta-data: character strings have a variable length, and so an indication is required of where they end: a length field or null termination. In the C language, which uses null-terminated strings, the literal object "65535" claims at least six bytes of storage (on mainstream platforms): five bytes for the content of the string, plus an additional byte whose value is zero, indicating the end of the string. A wide-string literal, L"65535", whose elements are of wide character type called wchar_t, commonly requires twelve bytes (two-byte wchar_t) or 24 bytes (four-byte, 32-bit wchar_t). (Some specialized systems that still exist today, such as certain DSP chips, do not have a smallest addressable unit that is 8 bits wide. C compilers for those systems have a char type that may be 16 or 32 bits or whatever is the applicable unit.)

What is a byte? Let's assume the modern eight bits.

What is the representation? What other values have to be possible in that representation?

Suppose we assume a pure binary representation which can handle all of the integers from 0 to 65535. In this representation, 65535 is represented by 16 bits: 1111111111111111. This requires two eight-bit bytes.

If the requirement is to have a representation that only handles the two values { 0, 65535 }, or any other choice of two numbers or symbols, we can encode that in as little as one bit: a fraction of a byte.

If we have to represent all integers from -65535 to 65535, using two's complement (or one's complement will need 17 bits, and that will require three bytes.

We can also think about handling the value 65535.0 in the smallest possible floating-point representation we can think of (which still resembles IEEE). The abstract mantissa corresponds to the binary representation and so requires 16 bits, valued 1. However, in floating-point, the leading 1 can be assumed and so it disappears: every nonzero floating-point value is 1.whatever x (base)^exponent: the 1 is always there, and so we don't have to dedicate a bit to it. Thus the mantissa requires only 15 bits. If we do not allow any exponent in our floating-point representation, only a sign bit, then we are back to 16 bits. But that's a "strawman" floating-point. Genuine floating-point should be able to float the point, so we need an exponent field. Not only that, let's make it a requirement that the exponent must actually encode the exponent value that is required, namely 65535 = 1111111111111111b = 1.111111111111111b x (10b)^1111b, as well as every lower exponent down to zero. Moreover, let's make it a requirement that negative exponents must be handled so we can represent small fractional values closer to zero than 1.0: all exponent values from -16 to +15. That requires a five bit exponent. Thus, in total, we need one bit for the sign, five bits for the exponent and fifteen for the mantissa: 21 bits. That fits into three bytes.

The number 65535 requires five bytes if it is represented as decimal t ext, where each of the digits is actually a digit character. In the USASCII code, which is a subset of Unicode, the digits 0 through 9 are represented by the character codes 48 to 57. In plain old seven bit ASCII formats, or 8 bit encodings such as the various ISO-8859-1 ("ISO Latin-1") encodings, these character codes occupy one byte each.

The character string 65535 could easily require more bytes of storage in memory if the string is made up of a character code point type that is wider than a byte. Other representational issues also arise such as meta-data: character strings have a variable length, and so an indication is required of where they end: a length field or null termination.

What is a byte? Let's assume the modern eight bits.

What is the representation? What other values have to be possible in that representation?

Suppose we assume a pure binary representation which can handle all of the integers from 0 to 65535. In this representation, 65535 is represented by 16 bits: 1111111111111111. This requires two eight-bit bytes.

If the requirement is to have a representation that only handles the two values { 0, 65535 }, or any other choice of two numbers or symbols, we can encode that in as little as one bit: a fraction of a byte.

If we have to represent all integers from -65535 to 65535, using two's complement (or one's complement will need 17 bits, and that will require three bytes.

We can also think about handling the value 65535.0 in the smallest possible floating-point representation we can think of (which still resembles IEEE). The abstract mantissa corresponds to the binary representation and so requires 16 bits, valued 1. However, in floating-point, the leading 1 can be assumed and so it disappears: every nonzero floating-point value is 1.whatever x (base)^exponent: the 1 is always there, and so we don't have to dedicate a bit to it. Thus the mantissa requires only 15 bits. If we do not allow any exponent in our floating-point representation, only a sign bit, then we are back to 16 bits. But that's a "strawman" floating-point. Genuine floating-point should be able to float the point, so we need an exponent field. Not only that, let's make it a requirement that the exponent must actually encode the exponent value that is required, namely 65535 = 1111111111111111b = 1.111111111111111b x (10b)^1111b, as well as every lower exponent down to zero. Moreover, let's make it a requirement that negative exponents must be handled so we can represent small fractional values closer to zero than 1.0: all exponent values from -16 to +15. That requires a five bit exponent. Thus, in total, we need one bit for the sign, five bits for the exponent and fifteen for the mantissa: 21 bits. That fits into three bytes.

The number 65535 requires five bytes if it is represented as decimal t ext, where each of the digits is actually a digit character. In the USASCII code, which is a subset of Unicode, the digits 0 through 9 are represented by the character codes 48 to 57. In plain old seven bit ASCII formats, or 8 bit encodings such as the various ISO-8859-1 ("ISO Latin-1") encodings, these character codes occupy one byte each.

The character string 65535 could easily require more bytes of storage in memory if the string is made up of a character code point type that is wider than a byte. Other representational issues also arise such as meta-data: character strings have a variable length, and so an indication is required of where they end: a length field or null termination. In the C language, which uses null-terminated strings, the literal object "65535" claims at least six bytes of storage: five bytes for the content of the string, plus an additional byte whose value is zero, indicating the end of the string. A wide-string literal, L"65535", whose elements are of wide character type called wchar_t, commonly requires twelve bytes (two-byte wchar_t) or 24 bytes (four-byte, 32-bit wchar_t).

What is a byte? Let's assume the modern eight bits.

What is the representation? What other values have to be possible in that representation?

Suppose we assume a pure binary representation which can handle all of the integers from 0 to 65535. In this representation, 65535 is represented by 16 bits: 1111111111111111. This requires two eight-bit bytes.

If the requirement is to have a representation that only handles the two values { 0, 65535 }, or any other choice of two numbers or symbols, we can encode that in as little as one bit: a fraction of a byte.

If we have to represent all integers from -65535 to 65535, using two's complement (or one's complement will need 17 bits, and that will require three bytes.

We can also think about handling the value 65535.0 in the smallest possible floating-point representation we can think of (which still resembles IEEE). The abstract mantissa corresponds to the binary representation and so requires 16 bits, valued 1. However, in floating-point, the leading 1 can be assumed and so it disappears: every nonzero floating-point value is 1.whatever x (base)^exponent: the 1 is always there, and so we don't have to dedicate a bit to it. Thus the mantissa requires only 15 bits. If we do not allow any exponent in our floating-point representation, only a sign bit, then we are back to 16 bits. But that's a "strawman" floating-point. Genuine floating-point should be able to float the point, so we need an exponent field. Not only that, let's make it a requirement that the exponent must actually encode the exponent value that is required, namely 65535 = 1111111111111111b = 1.111111111111111b x (10b)^1111b, as well as every lower exponent down to zero. Moreover, let's make it a requirement that negative exponents must be handled so we can represent small fractional values closer to zero than 1.0: all exponent values from -16 to +15. That requires a five bit exponent. Thus, in total, we need one bit for the sign, five bits for the exponent and fifteen for the mantissa: 21 bits. That fits into three bytes.

What is a byte? Let's assume the modern eight bits.

What is the representation? What other values have to be possible in that representation?

Suppose we assume a pure binary representation which can handle all of the integers from 0 to 65535. In this representation, 65535 is represented by 16 bits: 1111111111111111. This requires two eight-bit bytes.

If the requirement is to have a representation that only handles the two values { 0, 65535 }, or any other choice of two numbers or symbols, we can encode that in as little as one bit: a fraction of a byte.

If we have to represent all integers from -65535 to 65535, using two's complement (or one's complement will need 17 bits, and that will require three bytes.

We can also think about handling the value 65535.0 in the smallest possible floating-point representation we can think of (which still resembles IEEE). The abstract mantissa corresponds to the binary representation and so requires 16 bits, valued 1. However, in floating-point, the leading 1 can be assumed and so it disappears: every nonzero floating-point value is 1.whatever x (base)^exponent: the 1 is always there, and so we don't have to dedicate a bit to it. Thus the mantissa requires only 15 bits. If we do not allow any exponent in our floating-point representation, only a sign bit, then we are back to 16 bits. But that's a "strawman" floating-point. Genuine floating-point should be able to float the point, so we need an exponent field. Not only that, let's make it a requirement that the exponent must actually encode the exponent value that is required, namely 65535 = 1111111111111111b = 1.111111111111111b x (10b)^1111b, as well as every lower exponent down to zero. Moreover, let's make it a requirement that negative exponents must be handled so we can represent small fractional values closer to zero than 1.0: all exponent values from -16 to +15. That requires a five bit exponent. Thus, in total, we need one bit for the sign, five bits for the exponent and fifteen for the mantissa: 21 bits. That fits into three bytes.

The number 65535 requires five bytes if it is represented as decimal t ext, where each of the digits is actually a digit character. In the USASCII code, which is a subset of Unicode, the digits 0 through 9 are represented by the character codes 48 to 57. In plain old seven bit ASCII formats, or 8 bit encodings such as the various ISO-8859-1 ("ISO Latin-1") encodings, these character codes occupy one byte each.

The character string 65535 could easily require more bytes of storage in memory if the string is made up of a character code point type that is wider than a byte. Other representational issues also arise such as meta-data: character strings have a variable length, and so an indication is required of where they end: a length field or null termination.