See Learn Fractions with Cuisenaire Rods or search google…

I liked the explanation - simple and clear.

Say you have a large bit field where each bit represents a boolean value. Say you want to find the largest stretch of cleared bits in the field. With a big endian machine you can optimize this process by reading the bitmap with the native size integers - 32 bit for a 32 bit processor, 64 bit for a 64 bit processor - at a time. When the 128 bit processor comes, the function doesn’t change, just start using 128 bit.

With a little endian machine you cannot do this, for the simple reason that the two 32 bit values will be different than the 64 bit value will be different than the 128 bit value.

Sure the way out is to reverse the loop - start at the end - but that is not always possible or desirable. For example, reading a file from disk backwards isn’t a very performant option. Extending an allocated piece of memory at the front is not a function I’ve heard of either.

IMHO little endian byte order for numbers is a bad idea because everything else is big endian: the sectors on disk, memory allocation functions, everything.

Another technical explanation of the porblem:
http://en.wikipedia.org/wiki/Endianness

Long story short: Even the many genius google engineers fail on a simple matter of notation.

Of course you’d think they’d at least implement the same logic across all their reports and not get it right with one report but fail with some others. You can’t realy blame them as it is absolutely not so easy to know upfront what kind of numbers in what format the whole word would start submitting. Clear documentation would have helped (their documentation only shows examples with amount in the houndreds).

And because most of us also know it is January, most of us europeans start dates with the day ;-)
26 January 2005

We also start with a Street’s name and then the number and this seems like designed for usability. Imagine you are trying to find an address by foot or car. What do you need to look for first? You find the street, then you look for numbers. Now let’s not even start with the funny numbering schemes they use all over the globe, some havind the odd numbers on the left side of the street and the even numbers on the opposite side…

Back on the topic of endian, I *would* agree that a street address can also have mixed endian, but the justification in your disagreement is clearly wrong. The hierarchy you describe clearly favors not mixed endian, but little endian. Yes, with dates, we all can assume the current year, but by that logic we can also assume the current month as well, and often do when we say things like “I have a meeting on the 30th”. Likewise for an address, once you’re at the street location, all that *does* matter is the apartment number, and the representation commonly used does *not* allow you to discard everything after it and reduce it to what is immediately meaningful.

I’m not trying to get you to change your blog date format or “requirements” for commenting; I’m just riffing on endian, too. As we look at endian with computers I think it’s interesting to look at endian elsewhere and think about what things make sense and what things are just force of habit. Yes, there are many common example of mixed endian, but they don’t really make a lot of sense when you actually think about them. It has been said that little endian is favored when writing things out (because you can simply stop if the remainder is “understood”), and that big endian is preferred when representing continual precision (as is often the case for numbers). I don’t know how true that is, but it somehow makes sense that an older architecture like x86, designed when we were moving from paper to electronics, would be little endian whereas newer architectures are usually big endian. I can’t point to a single mixed endian architecture! :-)

Pete: You totally caught me on being thoughtless and ignorant with regard to “number” vs. “numeral”. I think if I thought about it I would figure it out on my own, but I confess that I’ve never really given a second thought to using “number” for both the quantity and the representation. Must be my colloquial habit. I do think that using the two side-by-side would only lead to headache and confusion by both writer and reader alike. Probably better would have been to clearly define “character” in the context of a “number representation” and thereafter use character or number with more thoughtfulness. (And I’m glad my English imperfections haven’t sent you away for good :) )

(Looking back over this entry, I see that I used the terms “number” and “numeral” in close proximity in a perfectly understandable form. I never knew I knew the difference but I guess I did. No excuses, then!)