 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New schrieb:
> Invisible wrote:
>> As far as I know, even in languages that are usually written from
>> right to left, the most significant digit is still written "first" and
>> the least written "last".
>
> I'm pretty sure that in arabic, where numbers come from, the LSB is
> written first (i.e., arabic, right-to-left, writes digits in the same
> order as we do).
Yup, apparently so. Quote from the 'Pedia:
"The numerals are arranged with their lowest value digit to the right,
with higher value positions added to the left. This arrangement was
adopted identically into the numerals as used in Europe. The Latin
alphabet runs from left to right, unlike the Arabic alphabet. Hence,
from the point of view of the reader, numerals in western texts are
written with the highest power of the base first whereas numerals in
Arabic texts are written with the lowest power of the base first"
(http://en.wikipedia.org/wiki/Arabic_numerals#Adoption_in_Europe)
So Arabs (who can claim to be closer to the invention of the whole
positional smash) would probably consider the Intel format to be more
intuitive.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> 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...
You didn't read the second sentence, right?
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible schrieb:
>
>> 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?
Now you're trying to flee into ridicule.
Are /your/ fellow people using YYYY-MM-DD (the only really consistent
format, unless one changes the digit order within each element), except
on formulae layed out that way?
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Invisible" <voi### [at] dev null> wrote in message
news:4ae5cee1$1@news.povray.org...
> 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.
I would never store my numbers like that, bec-- wait a minute... then I'm
not sane?
Funny, the voices in my head seem to think I'm okay.
*giggle*
Sorry, returning you to your regularly scheduled discussion now...
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible schrieb:
> 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.
And still you can only mess up the order if you interpret it as a
sequence of non-octet blocks (which obviously it isn't in this case).
In the end, any introduction of inconsistencies in ordering has its root
cause in wrong interpretation of the data at some processing step.
Big-Endian may be more robust against this, but that still doesn't make
it "right" and Little-Endian "wrong".
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>> It just seems way more natural if you are writing any sort of processing
>> with bits/bytes etc that array index zero should be the LSB.
>
> ...and this *is* a good argument??
Yes, because people write algorithms to deal with this way more often than
writing out byte streams by hand.
> Think about it. If you store the textural representation of a number in
> ASCII,
Which nobody does, and as pointed out, when people do write out numbers they
are *right justified* exactly so that all the LSBs come *first* when you run
some algorithm on them (eg adding).
> 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,
I don't know about you, but if I want to get a huge (>8bit) number from the
bytes, I would do this:
HugeInt myHugeInteger = 0;
for(b=0;b<ArrayOfBytes.Length;b++)
myHugeInteger += ArrayOfBytes[b] * (256^b);
How is that "backwards"?
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>> 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?
Obviously you can't tell either, but at least in your example I *know* that
your 3 and 5 actually mean 3 and 5, and not 3*10^x and 5*10^y, where x and y
are unknown. For example that allows me to do the first step of an addition
routine or something.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
> I don't know about you, but if I want to get a huge (>8bit) number from
> the bytes, I would do this:
HugeInt mhi = 0;
for (b = length - 1; 0 <= b; b--)
mhi = (mhi * 256) + arrayofbytes[b];
I was amused once when I posted something in the Ada forum where I wrote
something like
x = c0 * 256 + c1;
and they complimented me on having the "Ada mindset" because I didn't use a
shift operator to build the integer. I said "I do that in C also. Every
compiler can handle that these days."
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 10/25/2009 3:55 AM, Orchid XP v8 wrote:
> SharkD wrote:
>
>> Just started learning TSQL, and I have to say that I _HATE_ it. I
>> would much rather use a typical object oriented language.
>>
>> I understand that TSQL is just a wrapper that hides the highly
>> optimized operations the server _actually_ performs. But the "spoken
>> sentence grammar" type of syntax TSQL uses is highly variable and
>> inconsistent, and to me very confusing and frustrating. Bleh.
>
> I've never seen TSQL, but if it's anything like SQL...
>
> ...well, look up some COBOL example code sometime. You'll see what I
> mean. ;-)
It's also the choice of words that are used for some of the commands
that irks me. Instead of SELECT I would have used GET. Instead of
TRIGGER I would have used EVENT. Instead of JOIN I would have used
INTERSECT. It's hard to remember commands when you don't feel their
names are the most intuitive.
Mike
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
SharkD wrote:
> It's also the choice of words that are used for some of the commands
> that irks me. Instead of SELECT I would have used GET. Instead of
> TRIGGER I would have used EVENT.
That's because you're thinking procedurally instead of declaritively.
You're thinking "The server gets a bunch of rows", instead of "the result is
the selection of the rows that meet this criteria." You're thinking "The
server runs this code when it gets an insertion event", rather than "this is
the code that's triggered by an insertion."
> Instead of JOIN I would have used INTERSECT.
Join is closer to a union than an intersection. It's actually a cartesian
product. If you join a 3-row table to a 5-row table, you get a 15-row table.
That said, SQL is indeed one of those languages for which I regularly have
to look up the syntax even for simple stuff. :-)
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |