Talk:Endianness/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 9

Examples

The article has 10 pages printed and it doesn't contain even one simple example on how to actually encode a float / integer value as big-endian / little-endian. What value does the information have without any examples? — Preceding unsigned comment added by 156.17.240.177 (talk) 14:00, 14 June 2011 (UTC)

See "Examples of storing the value 0A0B0C0Dh in memory" 83.255.34.193 (talk) 16:49, 14 June 2011 (UTC)

Thank you for the reply. In deed I've found the examples, my apologise. Frustration is gone also. — Preceding unsigned comment added by 156.17.240.177 (talk) 18:14, 14 June 2011 (UTC)

Most and least significant

There should be simple examples much eralier though in the text explaining also what "most signigicant" / "least significant" means. Somebody not knowing what little endian or big endian means, is likely to also stumble on these terms. Currently it covers all possible variations of what little endian and big endian could mean but fails to give a quick notion of the general idea. — Preceding unsigned comment added by 91.50.232.143 (talk) 19:46, 11 July 2011 (UTC)

Agree that these terms should be explained in the article. I added a sentence to the first paragraph (description, not example), and linked most significant byte and least significant byte. What do you think? Vadmium (talk) 08:05, 14 July 2011 (UTC).

Further, the existing endianness diagrams are confusing in that some point to the right for increasing addresses while others point to the left. Those pointing to the left should be re-drawn to be consistent. [User: bugbee|bugbee] — Preceding unsigned comment added by Bugbee (talk • contribs) 06:45, 11 November 2012 (UTC)

It's probably better (I didn't see the original). I think the example of 123 should mention explicitly which digit is considered the most significant. That registers aren't affected by endian-ness should probably be mentioned somewhere too. — Preceding unsigned comment added by 72.38.117.46 (talk) 15:04, 20 January 2014 (UTC)

Hindu–Arabic numeral system

I found the sentence

In the Hindu–Arabic numeral system the number one hundred twenty three is written 1 2 3 biggest part (hundreds) first. This is an example of big-endian notation.

rather confusing! If the biggest come FIRST, how it can be big ENDinan? (Ajsmirnov (talk) 10:48, 24 October 2013 (UTC))

Re-read the part about Gulliver's Travels. Just as an egg can be regarded as having two "ends", so can a place-value number. The "big end" is the most significant digit, and the "little end" is the least significant. A "big-endian" architecture is one on which, if you read the number byte-by-byte, starting from the lowest memory address and working toward higher addresses, you will encounter the "big end" of the number first. On a little-endian system, you will encounter the little end first. 129.42.208.179 (talk) 15:33, 6 February 2014 (UTC)

It's the numbers that are backwards, not the computers!

The preceding comment gives the illusion that the little endian convention used in most computers is backwards. But in fact it's the numbers that are backwards. The digits 12345678 should be interpreted with increasing place values going left-to-right. Let's use the notation Lx12345678 to mean left-to-right hex number. Now that everything is left-to-right, there is only one diagram to make:

system:              Little-endian      Big-endian
coordinates:         0 1 2 3            0 1 2 3   
32-bit number (Lx):  12345678           78563412  
UTF-8 Character:     X R A Y            X R A Y

When everything is printed left-to-right (even the numbers), the Little Endian system has everything going in the same order, while Big Endian has the numbers in reverse order.

So now you see: Big Endian is just an attempt to get the numbers to print from right-to-left when everything else goes left-to-right.

No you are not right. Whole your comment is very biased and mixed up (probably from the "should be interpreted.." point, as you suggest how numbers should be without explaining why). The very simple topic can cause very serious misunderstanding and you fell for it. The UTF-8 character is stored by a word-size access and from that point it's in big-endian way, even on little-endian machines, as it is the human-programmer that decides that order. In my opinion the topic of LE vs BE is about knowing the data size. You have to know the whole data size before you store it in LE way, as you start from the end. If you don't know what to say or when will you stop, you better use big-endian. That's why big-endian is more natural :) --37.209.141.229 (talk) 03:57, 23 November 2014 (UTC)

So yes, the article has Big Endian bias, and that bias is simply the way we learned to write our numbers from right-to-left. —Preceding unsigned comment added by 72.196.244.178 (talk) 15:09, 14 July 2009 (UTC)

Mathematically there is a good reason to write the numbers right-to-left. Numbers like 3.3333.... can go on infinitely but they always have a big end.

But for integers the little end makes more sense as a starting point. Integers are a special case of polynomials, and polynomials are a special case of infinite series, which have only a little end. —Preceding unsigned comment added by 72.196.244.178 (talk) 15:15, 14 July 2009 (UTC)

The endianness of a 8bit processor can be hard to define, the article does not mention this. If a processor has no registers wider than 8bit IMHO endianness is undefined. The basic 8051 is an example for this, or where is it's endianness visible? 212.66.146.4 (talk) 17:38, 10 February 2015 (UTC)

"If a processor has no registers wider than 8bit IMHO endianness is undefined." There are counter-examples to that claim, such as the IBM 1400 series. You assume that the processor can only do arithmetic on numbers the size of its registers. But if that is not the case - if for example the processor can do memory-to-memory arithmetic - then its endianness is very much defined. Jeh (talk) 14:20, 12 February 2015 (UTC)