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

Quote:

>       [snip...]          [snip...]           [snip...]

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

In Steven Levy's book _Hackers_, he writes about the early
hackers at MIT using the TX-0 and PDP-1 computers with paper
tapes. If you wanted to assemble your code, you loaded the
assembler binary program from paper tape. Then you input your
assembly source code via another paper tape. The "T" at the
end of the FLIT de{*filter*} name, and the "T" in TECO both
originally meant tape, as in paper tape. And "DDT" was the
"dynamic debugging tape". IIRC.

--
+-------------------------------------------------------------+

+-------------------------------------------------------------+



Wed, 06 Jul 2005 06:22:31 GMT  
 Card Columns (was Why did they make ... ?)

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.

PL/I on the S/360 of 1965 could use card columns 1 thru 80
for source program input, and could use all 80 columns for data.

Regardless of what columns were specified for source, all 80 columns
were processed by the compiler.

- Show quoted text -

Quote:
> John W. Kennedy



Wed, 06 Jul 2005 06:24:57 GMT  
 Card Columns (was Why did they make ... ?)

Quote:


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

Punch cards came into wide use for and after the American 1896(?) census.
When did TTYs come into being?
Quote:
> 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



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

Quote:

> Well I got a lot of replies very fast from that but to take some of you to
> task...

> The card sort IS O(n) because of the simple fact that doubling the number of
> cards EXACTLY doubles the time taken to sort those cards.

We agree on the facts and it's pointless for us to quibble over terminology, but
I point out to you the the most authoritative authors, such as Knuth and Aho,
Hopcroft, and Ullman characterize radix sort as O(n*p), where n is the number of
records and p is the number of passes. Certainly in a situation where p can be
regarded as a predetermined constant, then O(n*p)=O(n), so we do not disagree,
but if that is not the case ...

Asymptotic formulas characterizing the performance of algorithms are usually
derived over all possible inputs, not just a special subset. Also these formulas
must be applied with great caution.  Several algorithms may have the same
asymptotic behavior but drastically different constants of proportionality.
Moreover there are other considerations that these formulas fail to address.
Deciding which of several algorithms to use in a specific case can be a
complicated business.

Quote:
>  The sort key length is NOT related to the number of records (as someone
> claimed... ) for example if you are sorting on the last 8 columns of a card
> it is always 8 regardless of the number of cards you have.

> I agree that the number of passes depends on the key length and alpha zones
> etc but that is constant for a given sort and independent of the number of
> cards.  All other sorts depend in some way on the sort key length, they all
> have to do some kind of key comparison and some keys are just physically
> faster to compare than others but since this is generally a constant for a
> given sort and not related in any way to the record count which is why the
> key length does not appear in the O( ) calculation for any sort algorithm.

The formulas for the time complexity of sort algorithms based on key comparison
are usually given in terms of the number of comparisons required.  The
proportionality constant includes the cost of doing a comparison as well as any
associated subscript or pointer computations and data movement.  (in contexts
where the cost of a comparison depends on n, the constant isn't really a
constant.  As Marvin Minsky put it, some constants are more constant than
others.) In the case of radix sort what is being counted is not comparisons but
digit examinations.

Quote:
> (remember O( ) is not about how LONG a particular sort will take, but how
> sorting x records compares with sorting y records by the same key.)

That's one use that such a formula can be put to.  It can also be used to
compare different algorithms, in which case the value of the proportionality
constant and the assumptions made to derive the formula must be considered
carefully to come to a correct conclusion.

Quote:

> Another characteristic of the card sort machine is that it makes no
> difference whatsoever whether the cards were originally in some good, bad or
> totally random order...it still takes O(n).
> It also makes no difference if some or all the cards have the same sort key,
> it still takes exactly the same time.

> (Someone mentioned Radix sort... if that's what I think it is then it
> doesn't handle duplicate keys... or am I thinking of something else?)

Card sorting in the manner we are talking about is radix sorting.  Consult any
good textbook.

Quote:

> Lets think, just for fun...
>     The time taken for a card sorter to sort n records with key length k
> will be  C * n * k  where C= some constant dependent on the speed of the
> machine. Note on a graph, this is a straight line as n is increased.

It really is A+(B+C*n)*k, where B is the between pass overhead, and A, which can
be positive or negative, adjusts for the fact the the overhead may be different
on the first and/or last passes.

Quote:

>  Quicksort can sort in Q * n * log2(n)  where Q is some constant dependent
> on the speed of the machine....(assume that the effect of k is too small to
> matter here)    Note on a graph, this line curves up as n is increased .....

There is a big difference between these two formulas.  The one for radix sorting
gives the time to sort n records on k digits independent of the original
ordering.  The formula for Quicksort approximates the average time to sort n
records averaged over all n! possible permutations asymptotically as n
approaches infinity.  In the worst case Quicksort can do on the order of n*2
comparisons.

Quote:

> Whatever the values of Q and C and k, these two lines will cross and when
> they do, both sorts will sort in the same wall-clock time.....

>  this means that for a sufficiently humungous value of "n"  an old
> mechanical card sort machine will be able to complete the sort FASTER than
> QuickSort on a supercomputer....

a) In theory, yes.  In practice, work out how big n has to be for this to be
"so" and see if there is enough paper in the world to make the necessary cards
or any super computers with enough memory to store the records to be sorted.  In
many cases something else breaks before the formula even becomes applicable.

b) That's why the sort packages that are generally used in large scale data
processing installations read in control staements that specify such things as
the record length and number of records in the dataset to be sorted as well as
an exact specification of the sort key and the type of comparison to be done.
The package then tailors the method to the situation.

Quote:

> I'm glad i'm not the poor old operator on that shift ;-)

I certainly agree with that.


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

Quote:

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

    It's called a "radix sort," and it's been around for
years and years.  In some situations it's the best thing
going; in others it's useless.  See "The Art of Computer
Programming, Volume III: Sorting and Searching," section
5.2.5 "Sorting by Distribution" for analyses of right-to-
left and left-to-right approaches in various settings.
See also section 5.4.7 "External Radix Sorting" in the
same volume for a discussion of using radix-sort methods
on more data than will fit in computer memory (and for the
interesting conclusion that radix methods are usually not
competitive in this situation, even though they can excel
at internal sorting).

    In short, folks, this is well-trodden ground.  Allow
me to recommend spending a few moments studying the tracks
already made before {*filter*}ling out new mud-holes.

--



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


Quote:
>  See "The Art of Computer
> Programming, Volume III: Sorting and Searching,"

I'll dig mine out on Monday...


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



Quote:
>  lots and lots of stuff...

Naturally I agree with it all James... I was just having a bit of fun
extrapolating some of the maths and I certainly knew that the numbers were
impossilbly large...


Wed, 06 Jul 2005 08:06:25 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.

Even on PL/I F, source lines of length up to 100 characters were allowed.  The
default was SM=(2,72) but the maximum allowed was 100.  I always used
SM=(2,100,1) for source files on disk and SM=(2,80,1) for source files on cards.


Wed, 06 Jul 2005 08:00:29 GMT  
 Card Columns (was Why did they make ... ?)
On Fri, 17 Jan 2003 19:23:25 GMT, "John W. Kennedy"

Quote:

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

Yes.

The 1401 'operating system', such as it was, was not even as smart as
MS-DOS.  You COULD catalog a program, and execute it with a RUN card,
but it was hardly worth the bother.

Quote:

>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

The FORTRAN compiler was no speed deamon, either.  And if you used
IOCS macros with Autocoder, that got slow, also.

Quote:
>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).

--
Arargh (at arargh dot com)    http://www.arargh.com
To reply by email, change the domain name, and remove the garbage.
(Enteract can keep the spam, they are gone anyway)


Wed, 06 Jul 2005 08:33:06 GMT  
 Card Columns (was Why did they make ... ?)
The default for IBM System/360 PL/I was to use columns 2 - 72 for
the source code but IIRC that could be overridden with a compiler
option.

System/360 used the string "/*" in columns 1 & 2 of an input card
deck to indicate end of file; thus it would not be possible to
start a comment in column 1.  IIRC, it was possible to substitute
a different EOF indicator through some option on the "//SYSIN DD *"
JCL statement, but I never learned it well enough to remember.
Also, I knew (and still know) how to set up a drum card for an 029
keypunch (a skill that doesn't seem to be much in demand these
days :-)).

Also, column 1 was frequently used for printer carriage control
(remember that? :-)) to insert blank lines or page skips into the
listing output.

Quote:

> [...]

> PL/I on the S/360 of 1965 could use card columns 1 thru 80
> for source program input, and could use all 80 columns for data.

> Regardless of what columns were specified for source, all 80 columns
> were processed by the compiler.



Wed, 06 Jul 2005 08:46:26 GMT  
 Card Columns (was Why did they make ... ?)
The 1890 census.  The US census is taken every 10 years
in years that are a multiple of 10.
Quote:

> Punch cards came into wide use for and after the American 1896(?) census.



Wed, 06 Jul 2005 08:48:55 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.

There is no known general method to eliminate the occasional very slow (i.e.,
n*2) performance in Quicksort; however there is a sure fire way to guarantee
that the stack depth never exceeds log2 n, and that is always to stack the large
piece and go on to process the small piece.  This has no effect on the time
performance since both pieces must be processed eventually and it makes no
difference in which order you process them.


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

Quote:

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

Are you sure?  I started with IBM in June of 1960 in Cincinnati and I don't
recall seing a 1401 until sometime in 1961.  While I didn't use it myself, I
recall hearing about RPG from people who I thought were working on 650's and
704's and/or 705's at the time.


Wed, 06 Jul 2005 10:20:27 GMT  
 Card Columns (was Why did they make ... ?)
On Fri, 17 Jan 2003 18:55:11 GMT, "John W. Kennedy"

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.

Not disputing that, but I don't think IBM was a {*filter*} computer
company globally until after the 360 line came out, and prior to
that there were a lot of other mainframe companies doing things
differently, with different rules for their versions of languages
e.g. fixed column input was one possible input format on systems
that might not have card readers.

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

    fake address                use address above to reply






Wed, 06 Jul 2005 10:39:09 GMT  
 Card Columns (was Why did they make ... ?)
On Fri, 17 Jan 2003 22:55:50 GMT, robin

Quote:



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

>Punch cards came into wide use for and after the American 1896(?) census.

Punch cards were invented by Hollerith in 1880, but I don't
believe they were in wide use after the 1890 census: mainly used
for statistics, so probably large governments only.

Quote:
>When did TTYs come into being?

Paper tapes were first used with telegraphs in 1857; printing
telegraphs were developed from then until Baudot code was
invented, also in 1880, punched with five keys and printed using
a rotating wheel; teleprinters were first used in 1904, and
connected to a computer in 1940.

see http://www.maxmon.com/history.htm from
http://www.maxmon.com/1857ad.htm and other links there,
http://home.iprimus.com.au/oseagram/creed2.html (which notes that
in 1961 Creed's model 1000 was the first 5x5 dot matrix printer)

Quote:
>> 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






Wed, 06 Jul 2005 11:28:37 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