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

Darren New wrote:
> SharkD wrote:
>> It's also the choice of words that are used for some of the commands 
>> that irks me.
> 
> That's because you're thinking procedurally instead of declaritively.

Indeed.

Although it still annoys me that the Haskell standard function for 
selecting elements of a list is called "filter", not "select". The 
number of times I've done something like

   filter invalid_item my_list

when in fact I should have done

   filter (not . invalid_item) my_list

is just infuriating...

Smalltalk did it right. They had "select" and "reject". Makes it quite 
clear...

> That said, SQL is indeed one of those languages for which I regularly 
> have to look up the syntax even for simple stuff. :-)

Heh, do you have any idea how many commands Oracle has that have syntax like

   ALTER TABLESPACE BEGIN BACKUP;
   ALTER DATABASE OPEN;
   ALTER SYSTEM RESETLOGS;
   etc.

??

The manual has these huge, multi-page railroad diagrams to explain the 
syntax. Sadly, nobody thought to write down WHAT THE SYNTAX *MEANS*!! >_<

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:4ae73483@news.povray.org...
>> 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.

Technically, in T-SQL, that would be a CROSS JOIN. JOIN all by itself 
defaults to a LEFT INNER JOIN, for which the results could vary. In fact, 
JOIN all by itself wouldn't return any rows at all in that example if there 
weren't any matchs in the 5 row table.

Personally, I don't much care what the command names are in any language; 
I've always got one or two commands slipping away from me (the other day, 
POV kept giving me an error on the "cube" primitive, which I spent a good 
ten minutes on before remembering it's "box"... *sigh*)

I do wish T-SQL had better looping and some kind of sub-routine structure 
within stored procedures. I spend a lot of time avoiding doing anything 
complicated in it, unless there's some painfully urgent need to have 
execution happen on the server instead of out at the client end.

Post a reply to this message

On 10/27/2009 1:57 PM, Darren New wrote:
> 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."

Exactly.


>> 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.

There are three types of joins. In order of popularity they are, 1) 
inner, 1) outer, and 3) cartesian. Actually four types, considering that 
outer joins can be either left or right.

Inner joins (the most common) are like an intersection -- i.e. only rows 
with a positive match in both tables are returned.

Outer joins return either the entire left table or entire right table, 
as well as any intersections in the other table.

Cartesian joins are the ones that are like a union. But they're mainly 
only used for statistical purposes.


 > That said, SQL is indeed one of those languages for which I regularly
 > have to look up the syntax even for simple stuff. :-)

Yeah. For me it's a lot easier to remember objects and their methods 
than to remember a series of exact phrases verbatim. Compare this with 
public speaking, where it is more useful to refer to a basic outline of 
a speech than to try and memorize the entire thing word-for-word.

Mike

Post a reply to this message

Captain Jack wrote:
> JOIN all by itself wouldn't return any rows at all in that example if there 
> weren't any matchs in the 5 row table.

Note the difference between a relational join and the JOIN word in SQL.

A relational join is a cartesian cross-product. A JOIN in SQL requires you 
to filter the results, because you almost never ever want an actual 
cartesian cross-product.

I.e., in relational database theory, a join gives you each row of the first 
table concatenated with each row of the second table. Then you select the 
rows where the keys are equal, then you project over the rows you actually 
want. Those are the three basic reading operations in relational theory. The 
only reason "inner join" and "outer join" exist is that people don't want to 
actually normalize their databases the way that works well with relational 
theory.

SQL kind of weirds up the syntax some, but that doesn't mean you should use 
an entirely different (and incorrect) word for the operation. :-) If you're 
going to ask for a different word, ask for one that doesn't mean something 
wrong. :-)

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

Post a reply to this message