Darren New schrieb:

> I also believe (but I am too lazy to look it up right now) that it's 
> impossible to portably know whether
> 
> struct PackBits alpha = {0, 1, 0, 0};
> struct PackBits beta = {0, 0, 0, 1};
> 
> alpha or beta will yield a larger number when cast to an int. I.e., I 
> don't think the standard even says whether the fields are allocated MSB 
> or LSB first.

That's absolutely right: While standard C by now /does/ address the 
problem of detecting the range of values a certain integer type can 
hold, how many bits a "char" has, and even what base, mantissa size and 
exponent size a floating point format uses - still nobody has introduced 
anything that would make it possible to detect endianness at compile time.

Multi-character constants may be a way to detect this with some 
reliability, by testing e.g.

   #if '\xAB\xCD\xEF\xGH' == 0xABCDEFGH
     #define BIG_ENDIAN
   #elif '\xAB\xCD\xEF\xGH' == 0xGHEFCDAB
     #define LITTLE_ENDIAN
   #else
     #define UNKNOWN_ENDIAN
   #end

but the C99 standard does not explicitly specify any byte ordering rules 
of multi-character constants either.

The best you can do is include a runtime self-test routine in the code 
to actively check whether compile-time endianness assumptions were right.

Post a reply to this message

Orchid XP v8 wrote:

> 
> The concept of performing a multi-table join where the tables are all 
> stored on magnetic tape scares me. o_O
> 
> My God, it could take months...
> 

Not at all.  Simply sort the two (or more) files in sequence by the join 
key (one or more fields).  Then it is a matched scan or 'merge join' 
through both.  Variants for Inner, Left, Right and Full Outer joins.

As to sorting large tape files - You already have my reminiscence of 
'Real Sort I' on your blog.  Actually that whole thing was equivalent to 
a join of the account table to the transaction table when both were 
stored as sequential files on multiple volumes of tape.  Multiple months 
of Tran had to be merged and sorted into account sequence.

This was before disk databases and SQL were practical considerations for 
this application.

Back then (circa 1984) the bank that I worked for might have had about 
40 disk drives.  Each the size of a washing machine.  They were IBM 3350 
DASD providing about 300Mb capacity each - so long as you chose an 
efficient block size for the record length.

So that was about 12Gb of disk in total - for a largish bank.  In my 
pocket I now carry a 16Gb memory stick to backup files and sync across 
machines.

Tapes back then held something like 100Mb per reel (IBM 3420 1200 foot 
?) reel.  But there could be thousands of tapes in the library so that 
was hundreds of Gb.

Post a reply to this message

>> The concept of performing a multi-table join where the tables are all 
>> stored on magnetic tape scares me. o_O
>>
>> My God, it could take months...
> 
> Not at all.  Simply sort the two (or more) files in sequence by the join 
> key (one or more fields).  Then it is a matched scan or 'merge join' 
> through both.  Variants for Inner, Left, Right and Full Outer joins.
> 
> As to sorting large tape files - You already have my reminiscence of 
> 'Real Sort I' on your blog.  Actually that whole thing was equivalent to 
> a join of the account table to the transaction table when both were 
> stored as sequential files on multiple volumes of tape.  Multiple months 
> of Tran had to be merged and sorted into account sequence.
> 
> This was before disk databases and SQL were practical considerations for 
> this application.

Indeed - it sounds like back then, doing this kind of stuff was pushing 
hard against the limits of technical feasibility. Like every individual 
operation had to be planned and hand-tuned and assisted by an army of 
technitions. Seems like having an SQL language would be a bit redundant.

...and yet, SQL is apparently that old. Go figure!

> So that was about 12Gb of disk in total - for a largish bank.  In my 
> pocket I now carry a 16Gb memory stick to backup files and sync across 
> machines.

Damn, they make memory sticks that large now??

> Tapes back then held something like 100Mb per reel (IBM 3420 1200 foot 
> ?) reel.  But there could be thousands of tapes in the library so that 
> was hundreds of Gb.

Amusingly, today I work with LTO3 tapes, which hold 400GB each. So... 
only about a thousand times more. (Not, say, several million.) Then 
again, I think those tapes might be slightly bigger physically too!

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

Post a reply to this message

On 10/21/2009 8:30 AM, Invisible wrote:
> - SQL existed 15 years before high-capacity storage devices appeared.
> (This is worse than it appears. You wouldn't even realise that a
> language like SQL was *necessary* unless databases themselves had
> already existed for some considerable length of time. And after that
> there would obviously be a rash of incompatible proprietry languages
> until people decided to design a standardised one.)

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.

Mike

Post a reply to this message

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

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

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> I've never seen TSQL, but if it's anything like SQL...

  How about making some googling? TSQL is SQL + some extensions.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> The best you can do is include a runtime self-test routine in the code 
> to actively check whether compile-time endianness assumptions were right.

At which point the best approach is probably just to pack and unpack the 
bits yourself. :-)

-- 
   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 7:51 AM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> I've never seen TSQL, but if it's anything like SQL...
>
>    How about making some googling? TSQL is SQL + some extensions.

"Doing" not "making". Please read:

http://grammar.ccc.commnet.edu/grammar/index2.htm

starting with "A, An, The (articles)", and ending with "Zero Articles". 
Make sure not to skip the middle bits, as you'll miss some important 
lessons!

Mike

Post a reply to this message

There's one thing I've always been confused about. Are all compiled 
languages equal in terms of performance? I've frequently read things 
like C++ being a superior performer to Java, but Java of course is a 
runtime language so it's not a fair comparison.

Mike

Post a reply to this message

SharkD wrote:
> There's one thing I've always been confused about. Are all compiled 
> languages equal in terms of performance?

Erm, no.

It depends how you write the program, it depends how good the compiler 
is (there may even be more than one of them), it depends on what the 
program is supposed to be doing in the first place, etc.

(E.g., if you're writing a program that's dominated by network latency, 
it makes little difference to performance which language you use. It 
might affect reliability, security or development cost, but not 
performance.)

In other words, "it depends". Certainly different languages and 
different language tools seem to have their strengths and weaknesses. 
Actually teasing out objective "facts" about such things is less easy.

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

Post a reply to this message