![](/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) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> 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
|
![](/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:
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 10/25/2009 7:51 AM, Warp wrote:
> Orchid XP v8<voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |