Talk:Endianness/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Remove Example: Interpretation of a Hexdump

I'm for removing this whole section. Reasons:

1. Confusing. I work in this field, and can't easily follow the table or text. Readers that don't already know this subject will be utterly confused. It uses terms and notation (like hexadecimal notation) without introducing them.
2. Inaccurate. It mixes byte-endianness with bit-endianess, when they are separate subjects.
3. Not relevant. I don't think a how-to for interpreting hexdumps belongs in WP.

--A D Monroe III (talk) 16:03, 8 June 2015 (UTC)

I agreed. Kbrose (talk) 16:36, 8 June 2015 (UTC)

Telephone number

The article contains the following sentence: "The telephone network has always sent the most significant part first, the area code; doing so allows routing to begin while a telephone number is still being keyed or dialed." However a telephone number is not an integer, and in particular, not a 32-bit or 64-bit integer, just a sequence of digits, which can be seen as a character string. So, this is not related to endianness and IMHO, this example should be removed. – Vincent Lefèvre (talk) 20:48, 8 June 2015 (UTC)

Done. Kbrose (talk) 00:34, 9 June 2015 (UTC)

Indeed, in Danny Cohen's "Endianness" defining paper the fixed length integers are in his main focus. But even in his first part MEMORY ORDER he considers character strings and the English language (which btw is always big-endian). Nevertheless or therefore, the endianness of a computing machine is defined according to the endianness of the fixed length integers. In the second part TRANSMISSION ORDER he fears the great misunderstanding (and the war) and also uses the terms big- and little-endian. In this part a restriction to fixed length integers is even less appropriate and he observes big discrepancies even in one and only one communication standard. So, the observation "The telephone network has always sent the most significant part first, the area code; doing so allows routing to begin while a telephone number is still being keyed or dialed." is very well related to endianness and should receive some room in the article. --Nomen4Omen (talk) 17:09, 9 June 2015 (UTC)

The English language is not big-endian. It is just a sequence of characters. Ditto for telephone numbers. The concept of endianness occurs on integers because they usually don't fit in a single byte, so that they need to be represented as a sequence of bytes, and there is no canonical way to do that. – Vincent Lefèvre (talk) 21:38, 9 June 2015 (UTC)

The argument for telephone numbers isn't entirely without merit. The area code would seem to be the most significant part of the number. However, Wikipedia is not the place to publish original research. Unless someone can find a reliable source describing telephone numbers as being big endian, it doesn't belong in the article. Pburka (talk) 23:33, 9 June 2015 (UTC)

A telephone number is not really a number (despite the term "number" used here). When one writes a number, if a leading 0 is added, the value is not changed. In a telephone number, if a leading 0 is added, everything is changed. I wouldn't say "most significant part", but "leading part". But there's nothing wrong in putting the leading part in the least significant byte of a register, for instance (the "little-endian" way of doing...); with this convention, one could say that the telephone number is represented in little-endian. So, the source needs to be objective, not just say that a phone number is big-endian without justification (or because people tend to think big-endian, thus do wrong assumptions, such as left = most significant). – Vincent Lefèvre (talk) 12:39, 10 June 2015 (UTC)

We don't require sources to justify their logic. If reliable sources said that telephone numbers have endianness, we could include that, even if they provide no explanation. But it's moot, since, as far as I know, there are no such sources. It's fun to debate these things, but my point stands that Wikipedia articles are based on reliable sources, no more, no less. Pburka (talk) 23:13, 10 June 2015 (UTC)

Telephone numbers are simply character strings representing signaling events and for the first few decades after their invention they were never stored or even transmitted until digit registers were invented, some years after machine switching systems simply discarded the signals after a relay was set. I think it is a stretch to call something big-endian simply because it is a defined sequence of signals, like language. For practical purposes time cannot be reversed by some system of engineering, and it is a waste of time to contemplate endianness for these systems. Kbrose (talk) 14:08, 10 June 2015 (UTC)

IBM 1400 series

I am not able to agree with the statement "The IBM 1400 series has characteristics of ... little- ...-endian." The relevant differences between the 14xx (type "A") and later big-endian machines (type "B"), e.g. system /360, are:

1. decimal (A) vs. (B) binary
2. add-instruction addresses rightmost (A) vs. (B) leftmost byte
3. machine has wordmarks (A) vs. (B) add-instruction "knows" the length of the operand

Besides these differences the algorithm for addition is the same, namely of type big-endian as we learnt it in school: starting with the one's position (the least significant digit) and working addresswise downward to the left to the most significant digit (while propagating the carries). If we program such an addition in COBOL or FORTRAN, we have one name, say "AUGEND", for the field to be added to (the so-called augend). On both types of machines, A and B, the symbol AUGEND stands for the whole field and can be identified with its byte address in memory. Let us assume that the length of the field AUGEND is 4 bytes, so that its least significant byte has the address AUGEND+3. On both systems, A and B, we write AUGEND = AUGEND + 157 for adding 157 to AUGEND.

On an A machine, the compiler generates an add-instruction referring to AUGEND+3. It can do this because the wordmark at address AUGEND+0 will stop the add-operation.

On a B machine, the compiler generates an add-instruction referring to AUGEND+0. At execution time the hardware will have to back up to AUGEND+3, start the addition there and work down to AUGEND+0.

This backing up from the address designating the field to the byte where the addition starts by the COBOL- or FORTRAN-compilers on machine A can hardly be classified as "little-endian". --Nomen4Omen (talk) 14:19, 14 June 2015 (UTC)

The section on the 1400 is unreferenced, and no reliable sources have been provided which directly support the claims in that paragraph. The only source which was found in the earlier discussion was the 1400 manual, which didn't explicitly describe endianness. If we're left to interpret the manual ourselves to determine whether it has characteristics of big- or little-endianness, then we're engaged in original research. The entire paragraph should be deleted. Pburka (talk) 05:22, 15 June 2015 (UTC)

Etymology far too much information

Suggest that there is way too much ancillary information about the derivation of Endianness and propose to reduce it to the essentials. — Preceding unsigned comment added by CPES (talk • contribs) 20:18, 6 October 2015 (UTC)