Invisible wrote:
> Think about it. If you store the textural representation of a number in 
> ASCII, the most significant digit comes first. 

But that's *wrong*.  Line up a column of numbers to be added up. How do you 
do it?  You right-justify the numbers, yes?

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Invisible wrote:
> Because the most significant digit is the most important piece of 
> information. It's "most significant".

Only if you know how many digits it is.

I'm thinking of two numbers. The first starts with a 7. The second starts 
with a 2. Which is bigger?

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:

> And since it's all imaginary anyway, and there is *NO ORDER* to bytes in 
> a computer, it's all just mathematical relationships between powers of a 
> polynomial and addresses, any argument you make against LSB vs MSB you 
> can also make against writing polynomials one way or the other.

Are you by any chance a native of that country that decided that neither 
day/month/year nor year/month/day was a good idea and so adopted 
month/day/year?

Post a reply to this message

Invisible schrieb:

> Think about it. If you store the textural representation of a number in 
> ASCII, the most significant digit comes first. But if Intel has their 
> way, the most significant byte comes... last? And if you have to split a 
> large number into several machine words, unless you number those words 
> backwards, you get monstrosities such as
> 
>   04 03 02 01 08 07 06 05 0C 0B 0A 09

That only happens if, for some obscure reason, you try to interpret a 
/character sequence/ as an integer value. Which it isn't.

Directly interpreting ASCII representations of numbers is made 
problematic in multiple ways anyway:

- The ASCII representation has no fixed width; The sequence "42" may 
represent the value 4*10+2, but it may just as well be just part of a 
much bigger value, such as 4*1e55 + 2*1e54 + something.

- You may encounter digit grouping characters such as "," (or, depending 
on language, even "." or what-have-you).

- The numerical base does not match anything remotely suitable for 
digital representation.

- Half of each byte (actually even a few fractions of a bit more) just 
contains redundant overhead.


> instead of
> 
>   01 02 03 04 05 06 07 08 09 0A 0B 0C
> 
> as it should be.
> 
> There's no two ways about it. Little endian = backwards.

No - you've got the whole thing wrong. Technically, little- and 
big-endian are "up-" and "downwards", as in the physical memory address 
lines and data lines are orthogonal to one another:

    01
    02
    03
    04
    05
    06
    07
    08
    09
    ...

If you need to group these, you'll get:

    01020304
    05060708
    090A0B0C
    ...

or

    04030201
    08070605
    0C0B0A09
    ...

neither of which has any inherent inconsistency.

Post a reply to this message

Darren New wrote:

> I'm thinking of two numbers. The first starts with a 7. The second 
> starts with a 2. Which is bigger?

Conversely, I'm thinking of two numbers. One ends with 3. The other ends 
with 5. Which is bigger?

Post a reply to this message

clipka wrote:
> Invisible schrieb:
> 
>> Think about it. If you store the textural representation of a number 
>> in ASCII, the most significant digit comes first. But if Intel has 
>> their way, the most significant byte comes... last? And if you have to 
>> split a large number into several machine words, unless you number 
>> those words backwards, you get monstrosities such as
>>
>>   04 03 02 01 08 07 06 05 0C 0B 0A 09
> 
> That only happens if, for some obscure reason, you try to interpret a 
> /character sequence/ as an integer value. Which it isn't.
> 
> Directly interpreting ASCII representations of numbers is made 
> problematic in multiple ways anyway:

I'm not talking about storing numbers as ASCII. I'm talking about 
storing a number such as 0x0102030405060708090A0C0B. Any sane person 
would store 0x01, followed by 0x02, followed by 0x03, and so on. But 
Intel and a few like them have decided to instead muddle up the ordering.

Post a reply to this message

Invisible schrieb:
>>> When you read data from a first, you read the first byte first, and 
>>> the last byte last. Therefore, the first byte should be the MSB.
>>
>> Seriously: Why? Just because us Westerners writing numbers this way 
>> round?
> 
> Because the most significant digit is the most important piece of 
> information. It's "most significant".

Right. And in rhethorics they teach to leave the most important argument 
for the end ("last but not least"). So?

It's not that I don't see those arguments. But they're not compelling 
enough to declare big-endian "right" and little-endian "wrong". You may 
call one of them "more intuitive [for us Westerners]", but that's as far 
as it gets.


> Erm, NO.
> 
> This happens because most cryptosystems are (IMHO incorrectly) specified 
> to *not* use big-endian encoding.

Whatever: My point is that the fault is not in the little-endians, nor 
in the big-endians, but just an inevitable consequence of the existence 
of both, and the fault can be assigned to either side for not having 
"given in".

> This means that if I want to implement such a system, I have to waste 
> time and effort turning all the numbers backwards before I can process 
> them, and turning them back the right way around again afterwards. It 
> also means that when a paper says 0x3847275F, I can't tell whether they 
> actually mean 3847275F hex, or whether they really mean 5F274738 hex, 
> which is a completely different number.

0x3847275F is, in any case, 3847275F hex - although you'll indeed need 
to know the endianness to tell whether it is 38;47;27;5F or 5F;27;47;38. 
If some paper doesn't answer this question while it is of any relevance, 
it is a bad paper.

>> Wouldn't it be more convenient to start with the least significant 
>> digit, and stop the transmission once you have transmitted the most 
>> significant nonzero digit? If you did that the other way round, you'd 
>> have no way to know how long the number will be, and won't be able to 
>> determine the actual value of each individual digit until after the 
>> transmission.
> 
> If you start from the least digit, you *still* can't determine the final 
> size of the number until all digits are received.

But you can already store the digits at their final position if you know 
the /maximum/ size. If you do it the other way round, you'll need to 
shift the whole thing after the transmission if the maximum size is not 
used.

Post a reply to this message

Invisible wrote:
> Are you by any chance a native of that country that decided that neither 
> day/month/year nor year/month/day was a good idea and so adopted 
> month/day/year?

I'm pretty sure we inherited that one from you guys. We just never went back 
and fixed it. ;-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Are you by any chance a native of that country that decided that 
>> neither day/month/year nor year/month/day was a good idea and so 
>> adopted month/day/year?
> 
> I'm pretty sure we inherited that one from you guys. We just never went 
> back and fixed it. ;-)

Ah, right. That would explain why you lot use month/day/year and we use 
day/month/year. Oh, wait a sec...

Post a reply to this message

Invisible wrote:
> Darren New wrote:
> 
>> I'm thinking of two numbers. The first starts with a 7. The second 
>> starts with a 2. Which is bigger?
> 
> Conversely, I'm thinking of two numbers. One ends with 3. The other ends 
> with 5. Which is bigger?

Yes. But I'm not the one claiming one is right and the other is wrong. :-) 
You're making my point for me.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message