Card Columns (was Why did they make ... ?) 
Author Message
 Card Columns (was Why did they make ... ?)


Quote:


> >Yep.   When sorting my name for passenger manifests in the
USAF (about
> >30 years ago) we only sorted on the first 3 columns.  But we
ALWAYS
> >followed that with a sequence check with the collator.
Depending
> >how many out-of-sequence cards were kicked out we'd either
insert
> >by hand, sort then insert by hand, or sort, sequence check,
and
> >then use the collator to merge.

> >Sounds like the operators at your school DP center (remember
when it
> >was called DP :-) were lazy!

> Or they only rented an hour on the sorter.

They also had to own a collator.  Remember, we're talking about
*public schools* here,
not the Air Force.

Ever seen that bumper-sticker about Bombers and Bake Sales?



Tue, 05 Jul 2005 21:39:17 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
>Russ - I did program fortran, BASIC and a bunch of other languages
>with a Baudot model 15.
>.gt.  .eq.  etc were how the special characters were specified, and a
>translate program was used to create the source for submission. (this
>was on a Project Genie machine in the early 60's.)

...and the same technique was used to support ALGOL compilers running
on 6-bit machines.  My PPOE used both the Grenoble and ALCOR compilers
under IBSYS, with program input via 026 keypunches (48-glyph character
sets).

Joe Morris



Tue, 05 Jul 2005 23:02:07 GMT  
 Card Columns (was Why did they make ... ?)
On Fri, 17 Jan 2003 06:27:58 -0700, "Russ Holsclaw"

Quote:



>> Nevertheless they did it:

>>  ... etc. etc.
>> Actually, I don't think the first version of FORTRAN even

>> only way to introduce characters was in Holerith literals if I
>recall correctly.

>> You can encode anything if you're determined enough.

>OK, I didn't argue that people didn't find a way to use TTY's to
>adapt.
>And, yes, I've been aware of the Figs and Ltrs mode on the model
>15 since the very first day I saw one, about
>45 years ago.

>Nevertheless, I remain certain that the idea of compilers
>scanning 1-72, and ignoring the last 8 columns of the
>card originated with the row-binary card readers on those first
>36-bit machines.

>The alternate character set that PL/I suppported was to
>accomodate the limited character sets of earlier keypunches and
>printers, which could accomodate no more than 48 printer glyphs
>(that's only 12 special characters beyond the letters and numeric
>digits.)

>Again... although it's an interesting coincidence that TTY's ALSO
>had a 72-character line-length, I'm still holding to the
>assertion that the practice of leaving out the last 8 columns in
>the card was originally motivated by the limitations imposed by
>the hardware in which FORTRAN was developed. Everything else
>mentioned in your posts came later. Everything.

Not all machines used punch cards -- many used paper tapes
instead of cards! The tapes were prepped on teleprinters. See
BAH's posts -- she started in DEC in TAPE PREP -- not keypunch.
Teleprinters were developed for telecommunications and paper
tapes used for message switching globally before card accounting
became popular. There's only a small step required from feeding
paper tape into machines to having teleprinters directly
connected to machines.

Thanks. Take care, Brian Inglis         Calgary, Alberta, Canada
--

    fake address                use address above to reply






Tue, 05 Jul 2005 23:44:34 GMT  
 Card Columns (was Why did they make ... ?)
On Fri, 17 Jan 2003 04:40:00 GMT, "John W. Kennedy"

Quote:





>>>>>Default seems to be at col 72, in my experience.  Can't

>>>imagine why....

>>>>>:->  I mean, who's going to add a comment in the final 8

>>>cols??

>>>>Columns 73-80 were for card numbering.

>>>I've mentioned this before, but for those who missed it:

>>>The tradition of using only 1-72 in mainframe compilers dates
>>>back to the 704 through 7094 computers, whose online card
>>>readers only read in row-binary, and would read two 36-bit
>>>words from each row of punches, 24 words per card.
>>>Conversion to characters was done by software.

>>>Columns 73-80 were ignored because the reader literally
>>>couldn't pick them up, unless you dropped in
>>>another control panel that was jumpered differently.
>>>[...]

>> Moreover some ttys could print only 72 columns.

>Yes, but TTY's were not used on the IBM 704.  The fact that FORTRAN,
>JCL, COBOL, PL/I -- virtually everything used on IBM mainframe computers
>except RPG -- ignores columns 73-80 depends on that bit of 50's hardware.

There were lots of other hardware available in the 50s that used
paper tapes and TTYs.

Thanks. Take care, Brian Inglis         Calgary, Alberta, Canada
--

    fake address                use address above to reply






Tue, 05 Jul 2005 23:46:12 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
>     A programmer I once knew had a ready comeback for the
> "Memory is cheap" pundits he'd encounter in design sessions:
> He'd hold out his hand, palm up, and invite them them to fill
> it with memory ...

Have you noticed how much RAM you can hold in the palm of your
hand
these days? More than any computer had when the in-place sort
algorithms were invented!

Quote:
>     Memory's even cheaper now than it was back then, but
> it still seems to me that using twice as much as you need
> isn't a great idea.  Or, turning it around, a method that
> can handle twice as much data in the same amount of memory
> sounds like a good idea: it lets me sort twice as much
> data before the system starts to suffer.

My point, however, which I guess I didn't state well enough, is
this:

If the quantity of data you are expecting to sort is in danger of
coming within a factor of 2 of being too much to contain in RAM,
even in a very short-term allocation, then you should not
have designed your application to be holding even one copy
of it all in RAM. It belongs in a database (where it's kept in
order, or indexed, and shouldn't ever have to be sorted in its
entirety).

Quote:

>     I'm afraid I don't follow: A list merge *is* an in-place
> sort; the back-and-forth-in-twice-the-memory method it
> beats is -- well, an "out-of-place" sort.  I mentioned it
> because it seemed a perfect example of in-place winning
> both ends of the time/space tradeoff.

The merge *I* use is not Knuth's in-place version. It's the
back-and-forth,
which is still faster.

Quote:
>     True, taking "worst-case scenario" to mean "coded by an
> incompetent."  The simple precaution of stacking the larger
> subfile and working on the smaller one first means the stack
> depth cannot possibly exceed lg(N/2) = lg(N)-1.

Well... I did a little research on this one.  It seems that you
have a
trade-off between explosive stack use or occasional very-slow
sorts with
Quick-sort. Or both. Not worth it.

I've found that, in today's environments, the quantity of data
that is typically
sorted has actually *shrunk*, while available memory grows.  The
reason for the
shrinkage is the pervasiveness of databases, and of interactive
(rather than
batch), applications that sort data primarily to present it in
humanly-
digestable quantities via a graphical user interface. You can now
easily keep
more data in RAM than you can reasonably inflict on a user all at
once through
a user interface.

Back when I started in this business, banks were running massive
sorts to
produce the monthly account statements for their customers.
Today, these
are generated from a perpetually-in-order, indexed, database or,
if desired,
a customer can display his own transactions on line, and the sort
only includes
transactions from one single account.

The big sort jobs we used to run in the '60s and '70s have pretty
much
disappeared, along with tape drives that are used as a primary
storage medium.

I notice that the Syncsort Corporation, however, is still in
business, producing
tools for use in data warehouse applications. They mail out
alphabetized
calendars every year "for your amu{*filter*}t" as a promotional item
(months and days of the week listed alphabetically, just for
laughs; the flip-side is chronological, however.). I've received
them for the past couple of years, even though I haven't found a
need of their products in my particular work.

They're probably the oldest continuously-operating ISV still in
business. And they didn't stay in business using in-place
memory-resident sorts, either.



Wed, 06 Jul 2005 00:09:13 GMT  
 Card Columns (was Why did they make ... ?)


Quote:
> Where the merge sort really takes off is if you are only
interested in
> counts and/or totals.  Every time two records compare equal,
add the
> second record to the first record and then throw the second

record away.

Ahh, yes. The "E25" Exit.

That was the name of the hook that allowed you to perform
aggregations and/or duplicate deletions in the IBM OS/360
Sort/Merge utility program.



Wed, 06 Jul 2005 00:34:35 GMT  
 Card Columns (was Why did they make ... ?)
Quote:
> Yes, but TTY's were not used on the IBM 704.  The fact that
FORTRAN,
> JCL, COBOL, PL/I -- virtually everything used on IBM mainframe
computers
> except RPG -- ignores columns 73-80 depends on that bit of 50's

hardware.

Moreover, most early programming languages had a lot of
column-sensitivities ...
FORTRAN had it's rules about numbers in 1-5, a continuation punch
in column 6, and the code beginning in column 7. COBOL had its
"margins", too.
In fact, RPG was about the worst that way. Incomprehensibe
outside the context
of a coding-pad with the fields labeled.

Not exactly TTY-friendly. More suited to a keypunch machine with
a program-drum.

A lot of folks on this newsgroup worked with minis, though, not
mainframes, so they perceive the world a bit differently ... more
"paper tape" than "card deck".



Wed, 06 Jul 2005 00:51:19 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> Well... I did a little research on this one.  It seems that you
> have a
> trade-off between explosive stack use or occasional very-slow
> sorts with
> Quick-sort. Or both. Not worth it.

    Your research is faulty, I fear.  Quicksort has the
danger of slow execution (addressed in various ways by
various implementations), but that has nothing to do
with the stack size.  There is no "explosive stack use."
There is no design trade-off between stack size and
sort speed.  (There is a sort of degenerate trade-off,
in a twisted fashion: Quicksort's worst case is when
each partitioning step produces one empty sub-file,
in which case no stack is required at all.  But that's
hardly a trade-off in the usual sense.)

--



Wed, 06 Jul 2005 01:30:15 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> On Fri, 17 Jan 2003 04:40:00 GMT, "John W. Kennedy"





>>>>>>Default seems to be at col 72, in my experience.  Can't

>>>>imagine why....

>>>>>>:->  I mean, who's going to add a comment in the final 8

>>>>cols??

>>>>>Columns 73-80 were for card numbering.

>>>>I've mentioned this before, but for those who missed it:

>>>>The tradition of using only 1-72 in mainframe compilers dates
>>>>back to the 704 through 7094 computers, whose online card
>>>>readers only read in row-binary, and would read two 36-bit
>>>>words from each row of punches, 24 words per card.
>>>>Conversion to characters was done by software.

>>>>Columns 73-80 were ignored because the reader literally
>>>>couldn't pick them up, unless you dropped in
>>>>another control panel that was jumpered differently.
>>>>[...]

>>>Moreover some ttys could print only 72 columns.

>>Yes, but TTY's were not used on the IBM 704.  The fact that FORTRAN,
>>JCL, COBOL, PL/I -- virtually everything used on IBM mainframe computers
>>except RPG -- ignores columns 73-80 depends on that bit of 50's hardware.
> There were lots of other hardware available in the 50s that used
> paper tapes and TTYs.

Yes, but there was very little use of paper tape and/or TTY's on IBM
mainframes -- and IBM's own TTY-like devices, in the 60's, were
wide-carriage Selectrics.

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Wed, 06 Jul 2005 02:55:11 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> In fact, RPG was about the worst that way. Incomprehensibe
> outside the context
> of a coding-pad with the fields labeled.

You could get a card with the fields labeled at the edge that you could
hold under the printed lines, thus:

00101FINPUT   IPE                      READER
|  | ||       |||||                    |       |
PG L F file-  I-input                  device
#  #   name   O-output
                P-primary
                S-secondary
                 E-EOF

and so on....

Quote:
> Not exactly TTY-friendly. More suited to a keypunch machine with
> a program-drum.
> A lot of folks on this newsgroup worked with minis, though, not
> mainframes, so they perceive the world a bit differently ... more
> "paper tape" than "card deck".

True, but we're talking about the age before mini's, when most software
breakthroughs were made on "big iron" -- mostly IBM's -- because only
the biggest computers justified the "waste" of having software in the
first place.  Yes, guys, there was a time when having an operating
system -- at all -- was regarded as a senseless luxury.  Most 1401 shops
only ran the operating system when they ran the assembler it hosted --
their actual programs were all self-booting, and, when they finished,
they put the machine into a hard stop, waiting for the next program to
be booted.

Note that RPG was born on the 1401, a machine on which the COBOL
compiler could take _hours_ to run.  RPG was the Turbo Pascal of its
era.  It is also a very easy language to code, within its particular
problem domain (which constituted a very sizable fraction of
dollars-and-cents programming in those days).

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Wed, 06 Jul 2005 03:23:25 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> Have you noticed how much RAM you can hold in the palm of your
> hand
> these days? More than any computer had when the in-place sort
> algorithms were invented!

More than all the computers in the world then, put together!

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Wed, 06 Jul 2005 03:25:14 GMT  
 Card Columns (was Why did they make ... ?)

Quote:




>>>Interesting to think that a single card sorter is effectively  Order(n)

> ....

>>>i.e. double the records = double the time exactly.
>>>How many so called fast algorithms can match that ?
>>Cute, but there's a bit of a fallacy hiding there.  The width of the
>>sorting field will normally be proportional to the logarithm of the
>>number of records, which brings things back to the standard n*log n
>>time.
> Eh? I don't know what you're on but can I have some ;-)
> If i sort everyone in my street (all 8 of them)  by 'phone number , the sort
> key length will be 11.
> IF I then sort everyone in the UK (say 50 million or so if you include the
> mobiles) by 'phone number, the sort key length will be 11..
> There's no relationship whatever between the sort key length and the number
> of records.

Only because, in this case, the sort key length is much greater than it
needs to be, causing the job of sorting your neighbors by a radix sort
to take much longer than it needs to.  So instead of taking n log n
time, you're taking n log (a much larger number than n) time.

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Wed, 06 Jul 2005 03:32:54 GMT  
 Card Columns (was Why did they make ... ?)



<snip>

Quote:
> Only because, in this case, the sort key length is much greater than it
> needs to be, causing the job of sorting your neighbors by a radix sort
> to take much longer than it needs to.  So instead of taking n log n
> time, you're taking n log (a much larger number than n) time.

I'm sorting real world sort keys (e.g peoples names or birthdays) where the
sort key length is not governed by academically convenient algorithms....
In any case it's STILL O(n) because the sort key length is constant for a
given type of sort....

Yes the time taken is  n*k   but this is LESS than n*log2(n)   if k<log2(n)



Wed, 06 Jul 2005 04:38:49 GMT  
 Card Columns (was Why did they make ... ?)

Quote:



> If you want to have a discussion, DO NOT TOP POST, please.

> Nope.  Go do some card sort work.  You also have to consider
> how fast the operator is.  I preferred doing large decks because
> I could stack and remove as the sorting happened.  I wouldn't say
> double based on the card count.  It's the start and stop that
> took the most time.

> Nope.  Go do some card sort work.  You also have to consider
> how fast the operator is.  I preferred doing large decks because
> I could stack and remove as the sorting happened.  I wouldn't say
> double based on the card count.  It's the start and stop that
> took the most time.

   Of course the operator is an issue and will be rushed off their poor
little feet
 but I was talking theoretically  and probably more cards than were ever
made in the history of the
universe.... Similarly,  software sort time is  seriously compromised if
the OS has to start paging....
I guess the poor operator is just the steam-age equivalent of the virtual
storage system...;-)

Now what would be interesting is to code a software simulation of the card
sorter algorithm ... my theory suggests that it would sort cards by 8 cols
faster than Qsort for anything over 1000 cards or so.



Wed, 06 Jul 2005 05:46:42 GMT  
 Card Columns (was Why did they make ... ?)

Quote:



> If you want to have a discussion, DO NOT TOP POST, please.

ok

Quote:
> Nope.  Go do some card sort work.  You also have to consider
> how fast the operator is.  I preferred doing large decks because
> I could stack and remove as the sorting happened.  I wouldn't say
> double based on the card count.  It's the start and stop that
> took the most time.

As you say... the start and stop take pretty much the same time as long as
your hoppers are big enough and assuming the operator can carry the cards...
ie it takes about as long to start and stop a 100 card job as it does a 1000
card job. The operator still has to make as many trips between the hoppers
but just has a heavier load to carry. This would tend to make the algorithm
slightly faster (per card) as the number of cards increases so its even
better than O(n) !  If you stack and remove while it's happening its even
better than that....Weirder and weirder :-)


Wed, 06 Jul 2005 06:15:34 GMT  
 
 [ 373 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software