Little-endian makes more sense for computers where calculation is most important. Big-endian makes more sense for humans where, I would argue, comparison is most important. If I want to know e.g. if I can afford something, I'd prefer hearing the price as "four hundred and ..." to instantly get a ballpark rather than "five and ninety and four hundred".
No - I think that big-endian only makes sense because you grew up with it.
Think about who used numbers back when this decision was made - small business people who mostly did math by hand - addition in particular - which we do from small digits to large - if we'd done the sane thing when we borrowed arabic numbers we'd write them in the order that numbers come out of an addition operation, rather than having to guess at how much space to leave for the result and write them backwards from the order we normally write them
You can make a program to convert it to some human-readable number then. You have to do this because it's binary anyways, so you're either representing it as octal, hexadecimal or binary.
I don't know about you, but if I am trying to reason about hexadecimal numbers then I just separate it into 0xDEADBEEF = D*16^7 + E*16^6 + A*16^5 + D*16^4 + B*16^3 + E*16^2 + E*16^1 + F*16^0. The endianness only changes the order of the bytes I start reading at. What we ought to do is make a new prefix for reading the hexadecimal numbers in little-endian order like 0xDEADBEEF = 0yEFBEEDDE. Of course, this doesn't really fix the problem (wanting to read the number with smaller symbols first) as bytes are still considered to be in big endian if you consider the semantics about left/right shifts, which play on our preconceived notions of big endianness in everyday decimal math. You would want a system where everything is treated little-endian (bits within bytes, bytes within arrays)
Your point about bit shifts is good, too. If the rightmost bit is the least-significant bit, then for consistency perhaps memory should be written with the lowest memory address on the right. Then 0xDEADBEEF makes sense both in terms of bytes within the value and bits within the byte; the first 4 bits within the lowest byte in memory are F, then next 4 bits within the lowest byte are E, the first four bytes within the second-to-lowest byte are E, the next 4 bits within the second-to-lowest byte are B, etc. So if 0xDEADBEEF were stored in little-endian, a hex editor could display DE AD BE EF
I've always thought "little-endian is logical, big endian is backwards".
In LE, bit n has value 2^n and byte n has value 256^n. In BE, bit n has value 2^(k-n) and byte n has value 256^(k-n) where k is the maximum length; it causes increase of ordinal position to not correspond with increase in value, and makes it length-dependent.
Bit numbering does not necessarily follow byte numbering. Personally I favor BE byte-order—if only because it means a standard hex dump shows the bytes in normal reading order regardless of grouping, which is especially helpful when larger integers are not naturally aligned, and it also matches the order of digits in (English) text strings—but I would agree that bit 0 should always be the least-significant bit.
- list memory right-to-left so the lowest memory address is on the right and the highest is on the left (i guess i prefer this solution because it's compatible with the convention of the least-significant-bit being the rightmost bit, which is enshrined in the name of "right shift", and with the convention of the least-significant-bit being bit 0, which makes sense in formulas like "value = sum_digitindex digit[digitindex]*radix^digitindex")
or you could
- write hexadecimal values with the most-significant-digit on the right, so the byte 2 followed by the byte 10 (in decimal notation) would be written 20 A0 instead of 02 0A.
I don't know if popular hex dump programs have switches for either of those, though?
Applying the first solution consistently causes text strings to appear like "dlrow olleH", which IMHO is not very practical. In general we expect array elements, including byte and character arrays, to be listed in the locale's normal writing direction, which would generally be in ascending order by index from left to right. The second solution is more internally consistent, but breaks with the expected big-endian writing direction for Hindu-Arabic numerals in English text.
I can't say I've encountered any hex editors which support either option.
Comments
Little-endian makes more sense for computers where calculation is most important. Big-endian makes more sense for humans where, I would argue, comparison is most important. If I want to know e.g. if I can afford something, I'd prefer hearing the price as "four hundred and ..." to instantly get a ballpark rather than "five and ninety and four hundred".
No - I think that big-endian only makes sense because you grew up with it.
Think about who used numbers back when this decision was made - small business people who mostly did math by hand - addition in particular - which we do from small digits to large - if we'd done the sane thing when we borrowed arabic numbers we'd write them in the order that numbers come out of an addition operation, rather than having to guess at how much space to leave for the result and write them backwards from the order we normally write them
You can make a program to convert it to some human-readable number then. You have to do this because it's binary anyways, so you're either representing it as octal, hexadecimal or binary.
I don't know about you, but if I am trying to reason about hexadecimal numbers then I just separate it into 0xDEADBEEF = D*16^7 + E*16^6 + A*16^5 + D*16^4 + B*16^3 + E*16^2 + E*16^1 + F*16^0. The endianness only changes the order of the bytes I start reading at. What we ought to do is make a new prefix for reading the hexadecimal numbers in little-endian order like 0xDEADBEEF = 0yEFBEEDDE. Of course, this doesn't really fix the problem (wanting to read the number with smaller symbols first) as bytes are still considered to be in big endian if you consider the semantics about left/right shifts, which play on our preconceived notions of big endianness in everyday decimal math. You would want a system where everything is treated little-endian (bits within bytes, bytes within arrays)
I like the 0y format idea.
Your point about bit shifts is good, too. If the rightmost bit is the least-significant bit, then for consistency perhaps memory should be written with the lowest memory address on the right. Then 0xDEADBEEF makes sense both in terms of bytes within the value and bits within the byte; the first 4 bits within the lowest byte in memory are F, then next 4 bits within the lowest byte are E, the first four bytes within the second-to-lowest byte are E, the next 4 bits within the second-to-lowest byte are B, etc. So if 0xDEADBEEF were stored in little-endian, a hex editor could display DE AD BE EF
I've always thought "little-endian is logical, big endian is backwards".
In LE, bit n has value 2^n and byte n has value 256^n. In BE, bit n has value 2^(k-n) and byte n has value 256^(k-n) where k is the maximum length; it causes increase of ordinal position to not correspond with increase in value, and makes it length-dependent.
Bit numbering does not necessarily follow byte numbering. Personally I favor BE byte-order—if only because it means a standard hex dump shows the bytes in normal reading order regardless of grouping, which is especially helpful when larger integers are not naturally aligned, and it also matches the order of digits in (English) text strings—but I would agree that bit 0 should always be the least-significant bit.
With LE, you could either:
- list memory right-to-left so the lowest memory address is on the right and the highest is on the left (i guess i prefer this solution because it's compatible with the convention of the least-significant-bit being the rightmost bit, which is enshrined in the name of "right shift", and with the convention of the least-significant-bit being bit 0, which makes sense in formulas like "value = sum_digitindex digit[digitindex]*radix^digitindex")
or you could
- write hexadecimal values with the most-significant-digit on the right, so the byte 2 followed by the byte 10 (in decimal notation) would be written 20 A0 instead of 02 0A.
I don't know if popular hex dump programs have switches for either of those, though?
Applying the first solution consistently causes text strings to appear like "dlrow olleH", which IMHO is not very practical. In general we expect array elements, including byte and character arrays, to be listed in the locale's normal writing direction, which would generally be in ascending order by index from left to right. The second solution is more internally consistent, but breaks with the expected big-endian writing direction for Hindu-Arabic numerals in English text.
I can't say I've encountered any hex editors which support either option.
Hmm good point about text strings, thanks