Re: merging sorted sequences generically in Python

> Wow!  If I had 8000 punched cards, a binary merge sort would take  =

> 13 passes, or
> about a second and a half per card.  Sorting them by hand would  =

> probably be
> faster, ...

Faster, if you were good at reading punch holes.  To get human- =

readable annotation on the cards, you should have first passed them  =

through a different machine, an 'interpreter'.

> I'd think that the old inverted radix sort (first partition by last  =

> digit, then
> next-to-last-digit, etc.) would be faster.

According to http://pattonhq.com/ibm.html [0] the key was to sort on  =

yet another machine, the 'sorter' [1], at a little under 11 cards/ =

second/column (and presumably one used radix sorts for multiple- =

column or alphabetic keys)

-Dave

[0]  it seems the collator was also clumsy, special-case-filled  =

hardware:
> The collator was the most cursed EAM machine. Card jams were a  =

> mechanical nightmare requiring partial disassembly to extract  =

> mutilated cards. Read brushes were often ruined.
I note that one of the referenced parts in the collator manual is a  =

"joggle plate" on top of the machine, presumably for joggling the  =

card file against in the hopes it will subsequently feed smoothly...

[1] http://www.columbia.edu/cu/computinghistory/sorter.html
> You may have heard the story of the operator who dropped a whole  =

> box of cards. Wanting to put things right as quickly as possible,  =

> he sorted the cards, without consulting the user. As it turned out,  =

> that was the worst possible response. Up until that point, the box  =

> had contained a sample of random numbers.
> =96Ted Powell, Dec 2006

-- =

To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss