![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |