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


Quote:

> > Over the wire, your posts only have CRLFs at the end of each paragraph.
> > Email and news convention is to have a CRLFs at the end of each line, before
> > column 80. (Because it wouldn't fit on a punch card otherwise :)

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


Sun, 03 Jul 2005 12:46:40 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.

Of course, if a 1401 was used for off-line card-to-tape to build
jobstreams for IBSYS, all 80 columns were read and transferred
to tape.

Putting numbers in columns 73-80 was to provide insurance
against card decks being dropped by clumsy machine-room
operators.  Running the deck through a sorter could put
them back in order. The practice evolved into use of the
sequence numbers to reference lines of code in batch
"editing" of source "decks" on disk or tape.
(See the IEBUPDTE system utility in OS/360 and beyond,
as well as IBM's internally-used CLEAR/CASTOR system,
Panvalet, and the ADR Librarian program.)

For newsgroups, email, etc, another consideration is simply
related to making it easier on the eyes to read the text.
Around 65 is good.



Sun, 03 Jul 2005 21:38:44 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> Columns 73-80 were for card numbering.

cms update/source maint uses card/statement numbering in 73-80.

misc. ref:
http://www.garlic.com/~lynn/2002n.html#39 CMS update

--

Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm



Sun, 03 Jul 2005 21:51:08 GMT  
 Card Columns (was Why did they make ... ?)

Quote:



>> > Over the wire, your posts only have CRLFs at the end of each paragraph.
>> > Email and news convention is to have a CRLFs at the end of each line, before
>> > column 80. (Because it wouldn't fit on a punch card otherwise :)

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

We used columns 73-80 at NWA (fortran on Unisys 2200/Clearpath IX boxes)  
as a place to put a comment indicating the specific change number which
was associated with a code change.  That helped to identify when various
modifications had been made and which problem was associated with the new
code.

The same thing is done at my current site (COBOL 74 on a Unisys A-series
box), but it's taken a step further -- the system editor (CANDE) can be
configured to automatically insert a comment in columns 73-80 using the
MARKID command.  It's an interesting (and I think useful) idea...

--
 -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
                     Written online using slrn 0.9.5.4!
                   The Theorem Theorem: If If, Then Then.



Sun, 03 Jul 2005 22:11:08 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.

Not merely for Fortran card decks, but if you dropped a box of cards,
as you would ultimately do some time, you take your cards and locate and
IBM sorter, set each column (think about this a second, which column
order would you sort first? L-R or R-L), and get your card deck (source)
in the corresponding order.  Saved.


Sun, 03 Jul 2005 22:26:16 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> Not merely for Fortran card decks, but if you dropped a box of
cards,
> as you would ultimately do some time, you take your cards and
locate and
> IBM sorter, set each column (think about this a second, which
column
> order would you sort first? L-R or R-L), and get your card deck
(source)
> in the corresponding order.  Saved.

Right-to-left ... most significant column last. On the last pass,
the most significant digit
is used to separate the cards into piles based on that digit, the
cards having previously
been ordered according to less-significant digits.

As a linguistic aside, it should be noted that the card sorter
did not actually put
the cards in order. It would separate the cards into distinct
piles based on the
punch in the selected card column. Putting the cards in order was
actually a manual
operation in which the decks in each of the output pockets was
re-stacked into
one deck in the order desired. The sorting machine only did the
"separating into piles"
portion of the total procedure.

This conforms to the original English-language meaning of the
verb "to sort" which
normally refers to separating a big pile of things into smaller
piles, such as you do when
sorting the mail, or sorting the laundry. The use of the verb to
mean "putting in order"
is actually a corruption of the word orginating from how the card
sorter is usually used
in punched-card data processing.

So, the classic "sorting" algorithms, such as Shell Sort, Bubble
Sort, etc. don't actually
*sort* at all!

Put *that* in your pipe and smoke it!

--
Russ Holsclaw



Sun, 03 Jul 2005 23:48:14 GMT  
 Card Columns (was Why did they make ... ?)
On Wed, 15 Jan 2003 08:48:14 -0700, "Russ Holsclaw"

Quote:

>> Not merely for Fortran card decks, but if you dropped a box of
>cards,
>> as you would ultimately do some time, you take your cards and
>locate and
>> IBM sorter, set each column (think about this a second, which
>column
>> order would you sort first? L-R or R-L), and get your card deck
>(source)
>> in the corresponding order.  Saved.

>Right-to-left ... most significant column last. On the last pass,
>the most significant digit
>is used to separate the cards into piles based on that digit, the
>cards having previously
>been ordered according to less-significant digits.

>As a linguistic aside, it should be noted that the card sorter
>did not actually put
>the cards in order. It would separate the cards into distinct
>piles based on the
>punch in the selected card column. Putting the cards in order was
>actually a manual
>operation in which the decks in each of the output pockets was
>re-stacked into
>one deck in the order desired. The sorting machine only did the
>"separating into piles"
>portion of the total procedure.

>This conforms to the original English-language meaning of the
>verb "to sort" which
>normally refers to separating a big pile of things into smaller
>piles, such as you do when
>sorting the mail, or sorting the laundry. The use of the verb to
>mean "putting in order"
>is actually a corruption of the word orginating from how the card
>sorter is usually used
>in punched-card data processing.

>So, the classic "sorting" algorithms, such as Shell Sort, Bubble
>Sort, etc. don't actually
>*sort* at all!

>Put *that* in your pipe and smoke it!

The classic quick sort (partition exchange) algorithm does sort
in that traditional sense, using an increasing binary power
number of pockets, until it gets each item in a separate pocket.

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

    fake address                use address above to reply






Mon, 04 Jul 2005 00:34:21 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> > Not merely for Fortran card decks, but if you dropped a box of
> > cards, as you would ultimately do some time, you take your
> > cards and locate an IBM sorter, set each column (think about
> > this a second, which column order would you sort first? L-R
> > or R-L), and get your card deck (source) in the corresponding
> > order.  Saved.

> Right-to-left ... most significant column last. On the last
> pass, the most significant digit is used to separate the cards
> into piles based on that digit, the cards having previously
> been ordered according to less-significant digits.

Not always.  If you had several sorters and a very large file to sort it
was quite usual to do a block sort first to divide the file on the leftmost
digit, then share out the blocks among the sorters.
--
Nick Spalding


Mon, 04 Jul 2005 02:27:18 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> Not always.  If you had several sorters and a very large file
to sort it
> was quite usual to do a block sort first to divide the file on
the leftmost
> digit, then share out the blocks among the sorters.

True. Actually, that was sometimes a good method even with one
sorter, because it cut down on the size of decks you were running
through the sorter on each pass.  To facilitate this, many shops
installed big vertical card trays that stood above and behind the
sorter, to hold the decks in each "block".


Mon, 04 Jul 2005 02:35:11 GMT  
 Card Columns (was Why did they make ... ?)

Quote:
> The classic quick sort (partition exchange) algorithm does sort
> in that traditional sense, using an increasing binary power
> number of pockets, until it gets each item in a separate

pocket.

Even that stretches the definition of "sort" pretty thin, IMO.

Actually, I view most all of the academically-favored "classic"
sort algorithms as unnecessary {*filter*}es. All of them are saddled
with the absurdly pointless constraint that sorting mut be done
"in-place".  How often can you predict, at the time you're
coding, that there will room enough for one copy of a list, but
not enough for two? This constraint makes the entire suite of
in-place sort algorithms sub-optimal.

Even the best of them, the so-called Quick-Sort, can only be
considered "in-place" if your call-stack is made of magic
fairy-dust. I'm astonished at the number of programmers I've met
with degrees in CS who've never even considered any sort
algorithm other than one of these academic curiosities. When it
finally dawned on me how silly it was to stick with these
algorithms, I decided to quit using them. It's a case of
"thinking outside the box" ... literally. And an even better
illustration of the concept than the ever-popular 9-dots pencil
puzzle.

(I realize I've just stuck a fork into a sacred cow, so please
try to think open-mindedly about what I've just said for a day or
two before you respond. I don't feel like taking the time
required to lay out all of the arguments right now. Maybe some
day...)



Mon, 04 Jul 2005 06:33:25 GMT  
 Card Columns (was Why did they make ... ?)

Quote:

> Actually, I view most all of the academically-favored "classic"
> sort algorithms as unnecessary {*filter*}es. All of them are saddled
> with the absurdly pointless constraint that sorting mut be done
> "in-place".  How often can you predict, at the time you're
> coding, that there will room enough for one copy of a list, but
> not enough for two? This constraint makes the entire suite of
> in-place sort algorithms sub-optimal.

    The assumption that the freedom to make two copies of
everything opens the door to more efficient sorts seems
dubious at best.  There's usually something better to do
with all that extra memory than merely use half of it for
data and half of it for dirtied swap fodder.

    One example of the "smarter, not harder" idea can be
found in Knuth's explication of merge sorting.  He begins
with the back-and-forth approach using two memory regions
able to hold N records each, and develops the basic merge
sort and a few modifications.  But then he shows that making
a single linked list of the records uses less space (assuming
a record is larger than a pointer) *and* less time:

        "Thus we have a clear victory for linked-memory
        techniques over sequential allocation, when internal
        merging is being done: Less memory space is required,
        and the program runs about 10 to 20 percent faster."
        -- TAOCP Volume III, section 5.2.4

Quote:
> Even the best of them, the so-called Quick-Sort, can only be
> considered "in-place" if your call-stack is made of magic
> fairy-dust.

    The amount of fairy dust required for the stack (whether
a call stack or other) is, er, dirt cheap compared to the
amount required for an entire duplicate copy of the data
being sorted.  N+lg(N) < 2*N for all N>1 -- and while I
admit I'm no expert on sorting algorithms for one-record
data sets, I can't imagine they'd be improved by making
an extra copy of the one record ...

Quote:
> [...] When it
> finally dawned on me how silly it was to stick with these
> algorithms, I decided to quit using them. It's a case of
> "thinking outside the box" ... literally. And an even better
> illustration of the concept than the ever-popular 9-dots pencil
> puzzle.

    I'd be interested (and I imagine others would, too) to
learn what sorting methods you have found preferable.  Once
again, Knuth (describing the various methods one might have
come up with to solve his opening thought-experiment about
how best to sort five numbers):

        "Chances are your solution is one of the following
        types: [...]
        G. A new, super sorting technique which is a definite
        improvement over known methods. (Please communicate
        this to the author at once.)"
        -- TAOCP Volume III, section 5.2

Quote:
> (I realize I've just stuck a fork into a sacred cow, so please
> try to think open-mindedly about what I've just said for a day or
> two before you respond. I don't feel like taking the time
> required to lay out all of the arguments right now. Maybe some
> day...)

    Moo.  My mind is not udderly open, but I'm not predisposed
to dismiss your contention as a load of bull.  Let's see the
arguments to support your opinion; if they're good, I for one
will happily lap them up.

--



Mon, 04 Jul 2005 07:19:19 GMT  
 Card Columns (was Why did they make ... ?)
On Wed, 15 Jan 2003 15:33:25 -0700, "Russ Holsclaw"

Quote:



>> The classic quick sort (partition exchange) algorithm does sort
>> in that traditional sense, using an increasing binary power
>> number of pockets, until it gets each item in a separate
>pocket.

>Even that stretches the definition of "sort" pretty thin, IMO.

>Actually, I view most all of the academically-favored "classic"
>sort algorithms as unnecessary {*filter*}es. All of them are saddled
>with the absurdly pointless constraint that sorting mut be done
>"in-place".  How often can you predict, at the time you're
>coding, that there will room enough for one copy of a list, but
>not enough for two? This constraint makes the entire suite of
>in-place sort algorithms sub-optimal.

The extra memory is better used for more or bigger I/O buffers
unless it can all fit in memory. Knuth and probably others have
analyzed this to death.

Quote:
>Even the best of them, the so-called Quick-Sort, can only be
>considered "in-place" if your call-stack is made of magic

Partition stack need only be a fairly small array to remember
where the other half lives.

Quote:
>fairy-dust. I'm astonished at the number of programmers I've met
>with degrees in CS who've never even considered any sort
>algorithm other than one of these academic curiosities. When it
>finally dawned on me how silly it was to stick with these
>algorithms, I decided to quit using them. It's a case of
>"thinking outside the box" ... literally. And an even better
>illustration of the concept than the ever-popular 9-dots pencil
>puzzle.

I always liked Shell sort for sorting relatively small amounts of
random data internally, as it's only a few lines of code, and
it's probably within a few percent of optimal in that case.
Where I could, I'd try to get away with an insertion sort to
build small amounts of sequentially read data in sorted order.

For general application, I like a heap merge sort extended to
work over a slew of I/O buffers and produce "natural" length (or
some such phrase related to _e_ ~ 2.7 times longer than you can
fit in memory) runs: Knuth does some nice analysis of optimal I:O
buffer count ratios n:sqrt(n) and size ratios 1:2 IIRC.

Quote:
>(I realize I've just stuck a fork into a sacred cow, so please
>try to think open-mindedly about what I've just said for a day or
>two before you respond. I don't feel like taking the time
>required to lay out all of the arguments right now. Maybe some
>day...)

There are no sacred cows in sorting, just tradeoffs between data
and code space and time as usual: the fastest approach across a
selection of normal and gnarly data sets wins.
For example, I think PJ (Bill) Plauger's reference implementation
of C qsort() now switches from quicksort to heapsort or Shell
sort depending on various parameters and conditions detected (see
fairly recent C/C++ User's Journal article).
Any information you can give us will be absorbed avidly, in case
we ever need to write another sort routine or program.
But you'ld probably be wise to have looked at DEK's tAoCP vol.3
ch.5 Sorting before leading in cows for slaughter.

See Jim Gray's sort contest home page for some up to date
comparisons:
http://www.*-*-*.com/

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

    fake address                use address above to reply






Mon, 04 Jul 2005 14:04:06 GMT  
 Card Columns (was Why did they make ... ?)
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 ?

Interestingly, if you introduce multiple machines as described by Russ, the
algorithm isn't as optimal even though the actual speed may be better ... I
say MAY because the speed would actually be worse if a high proportion of
the cards had the same leading character in the key.

Oh what fun ;-)


Quote:


> > Not always.  If you had several sorters and a very large file
> to sort it
> > was quite usual to do a block sort first to divide the file on
> the leftmost
> > digit, then share out the blocks among the sorters.

> True. Actually, that was sometimes a good method even with one
> sorter, because it cut down on the size of decks you were running
> through the sorter on each pass.  To facilitate this, many shops
> installed big vertical card trays that stood above and behind the
> sorter, to hold the decks in each "block".



Tue, 05 Jul 2005 02:51:22 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 

1. Card columns (was Why did they make ...?)

2. What am I doing wrong!

3. What am I doing wrong?

4. Stupid newb question: What am I doing wrong?

5. What am I doing Wrong

6. what am i doing wrong

7. Help - What am I doing wrong

8. Saving a Variable to a field in a record- what am i doing wrong

9. What am I doing wrong?

10. What am I doing wrong?

11. Browse Column Counts - What am I missing?

12. #CONTROL What am I doing wrong

 

 
Powered by phpBB® Forum Software