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