Slashdot Mirror
Ask Slashdot: How Do You Sort?
camperdave writes "I was recently going through a pile of receipts and other papers to put them into order by date. Lacking one of those fancy sorting sticks they have at the office, I wound up with all sorts of piles and I was getting confused as to which pile was for what. Finally, it struck me: Why don't I use one of the many sorting algorithms I learned back in my computer science classes? So I swept all the papers back into the box and did a radix sort on them. It worked like a charm. Since then, I've had occasion to try quicksorts and merge sorts. So, when you have to physically sort things, what algorithm (if any) do you use?"
The obligatory xkcd
http://www.geoffreylandis.com
Bogosort, of course. I'm only human.
Some days I use one; other days I use the other.
Given that your pile was probably pretty well sorted to begin with, a bubble sort could actually have been the best solution. After all, the pile probably grew in chronological order.
if you are piling your receipts up chronologically, it should be merge sort
I just drop a pile of papers on the staircase, and then repeat if they did not land in the right order.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
I find Shredsort to be the fastest.
I too use radix sort, when I have a large number of unsorted items. I usually use a bidirectional bubble sort for smaller piles (ie, if I need to hold them all in my hand at once). And I've occasionally used a merge sort, which works great when you have to combine a handful of already-sorted piles.
Any of the more complex algorithms just don't work well in the real world - You either need too much (brain) stack space, or too much extra storage (desktop), to make it worth doing.
Can the shader units of a GPU be harnessed to accelerate sorting? I'm not sure if sorting is a problem which be adapted that way or not.
given that what I have would be characterized as a "piling" system... but in fact it ends up being a merge sort generally, with individual stores sorted by bubble sort before the merge.
Elementary operations don't have the same time cost in the real world than in computers. Take game cards for example. A deck doesn't have the same cost for inserting as the table container. Inserting a card in the middle of a deck is very easy and can be considered as being O(1): you don't need to move cards one by one to make space for the card you want to insert. That means insertion sort is O(n log(n)) for a deck of cards instead of O(n^2) for tables! Well, only if you use binary search to find the location where you must insert the new card.
By throwing all the files in the trash, you will create more filing space and avoid potential fire hazards.
It's a truly revolutionary filing system which eases my pyloric valve.
Hmm, chicken grease works good too and it smells like "home"
Seriously, "news for nerds eh?"
I usually attempt to express the items I am sorting in terms of ordinal keys.
Out performs everything else when N is large.
I always did radix sort for that. Works nicely. Or was it an N-way merge sort? Sort of an ad hoc mixture of both, depending of the task at hand, I guess.
Ezekiel 23:20
the real world is chaos and entropy. live with it.
Sometimes I have to separate by material, but not often.
Dude, you need to let people who are paid less than you to do menial tasks like this. Seriously.
With real physical sorts I pipe everything to DEV NULL
MMM, ya it does, like grand-ma's chicken soup..great on a cold day, warms u up inside,
thoughts of hollidays gone by,
etc...
They don't let us call them secretaries anymore, but I agree with stevegee58. Let an administrative assistant sort, or better yet run them through a Fujitsu SnapScan and then let the computer do the sorting.
I find myself using a combination of bubble sort and selection sort if I need to sort physical items. Basically if two items near to each other are similar in value I bubble sort them. If I find an item that is unusually high/low in value I move it to the end of the row.
Bucket sort to keep each individual stack small enough for the following insertion sort.
0 Give every item a number.
1 enter the date in excel.
2 Enter the number in excel.
3 Add one other search criteria in excel
4 Sort in excell/
Leave the papers alone. If you need to find a certain date, you know what numbers to look for.
5 swear at person that threw them in the wrong order.
Human sorting tends to be rather ad-hoc, and this isn't necessarily a bad thing. Yes, if someone is sorting a large number of objects/papers according to a simple criterion, then they are likely to be implementing a version of some sort of formal searching algorithm... But one of the interesting things about a human sorting things is that they can, and do, leverage some of their intellect to improve the sorting. Examples: ...).
1. Change sorting algorithm partway through, or use different algorithms on different subsets of the task. E.g. if you are sorting documents in a random order and suddenly notice a run that are all roughly in order, you'll intuitively switch to a different algorithm for that bunch. In fact, humans very often sub-divide the problem at large into stacks, and sub-sort each stack using a different algorithm, before finally combining the result. This is also relevant since sometimes you actually need to change your sorting target halfway through a sort (when you discover a new category of document/item; or when you realize that a different sorting order will ultimately be more useful for the high-level purpose you're trying to achieve;
2. Pattern matching. Humans are good at discerning patterns. So we may notice that the documents are not really random, but have some inherent order (e.g. the stack is somewhat temporally ordered, but items for each given day are reversed or semi-random). We can exploit this to minimizing the sorting effort.
3. Memory. Even though humans can't juggle too many different items in their head at once, we're smart enough that we encounter an item, we can recall having seen similar items. Our visual memory also allows us to home-in on the right part of a semi-sorted stack in order to group like items.
The end result is a sort that is rather non-deterministic, but ultimately successful. It isn't necessarily optimal for the given problem space, but conversely their human intellect is allowing them to generate lots of shortcuts during the sorting problem. (By which I mean, a machine limited to paper-pushing at human speed, but implementing a single formal algorithm, would take longer to finish the sort... Of course in reality mechanized/computerized sorting is faster because each machine operation is faster than the human equivalent.)
Probability I will need this (0-100)* How screwed I would be If I need and no longer have this (0-100) all /100.
0-50 =0 = chuck it out
51-100 = 1 = put it in the big pile.
I punch 3 holes in every receipt: one each for parent, left, and right. Then I attach them all by string, in a balanced tree. If I need multiple search keys, I just use different colors of string, and different sets of holes. Rebalancing can be a bit of a bitch, after insertion. (I never delete.)
HSJ$$*&#^!#+++ATH0
NO CARRIER
wouldn't it be a shame if this thread is the most responded to within the whole topic discussion?
Way to go DICE over-lords.
commander Taco, where are you???
but to stay on topic, Zogs would not be good, Chicken fat is :)
If I'm sorting stuff lexicographically, I generally use bin sort (often grouping things into four or so large bins first like say A-G, H-M, N-S, and T-Z for sorts on people's surnames). For numerical records, I use merge sort. Sometimes I use both, like for sorting cards (bin sort on suit and then merge sort each suit). It can be quite a time saver when you have to sort a large number of paper records to learn these sorting algorithms.
I suppose what could make this story more interesting is what sort of nontrivial algorithms do people use on a regular basis in a non-programming situation?
why is this modded as off topic?
seriously, its totally relevant, just look at the proceeding subject matter and you tell me whats "really off topic"??
I think this paralells the jerkoff coment below
define oldSpiceSort(list): // the list is now sorted
system("man look")
nowBackAtMe()
return list
First by rank (13 buckets) then by suit (4 buckets). I can typically sort a well-shuffled deck of bridge cards in about 85 seconds. That's far from the world record, but significantly faster than most people can do.
Assuming the bottom of the pile is the oldest....
1) decide how tall you would like the pile.
2) move that much of the pile to a temp location.
3) remove the remaining pile to the garbage/recycle/shred bin, as appropriate
4) move the temp pile back to the production pile area.
You never said you were looking for anything... sorting piles of kipple seems to be a rather dull hobby.
This issue is a bit more complicated than you think.
decay, dissolution, hallucination, masturbation, constipation, decomposition
ashes to ashes dust to dust,
we all know major Tom's a junkie,
did any body answer the jack off comment above??
perhaps a bit more relevant considering the subject material discussed here.
"We don't. We declare chaos as the standard."
Just outsource it...
Yoda's cave philosophy.
Keep it secret.
Keep it safe.
The way is shut.
paper? you are kidding, right?
Sorting receipts, is like sorting anything else out there. So...how do I sort my VAST amounts of Electronic components?
I name them, and I have individual shelves for them, not necessarily in alphabetical order, but more like groups...like those I'd need for certain purposes. Like...Coils in one section (a matrix/row of various values) and resistors in a increasing value row...like 1 ohm to 20 Mega Ohm. etc. And Capacitors...etc...you get the point. How do I file those? I don't... I just make sure that I've got enough stickers on them explaining what they are, where they are, and what they do...every single component...within eyes reach, so I can easily spot whatever I need for the next project.
Well...you DID ask, and it didn't have to be OFFICE specific.
What this world is coming to - is for you and me to decide.
Sorting things alphabetically, as in the original example, I tend to start with a bucket sort, with the number of buckets depending on how many things I'm alphabetizing. This works well because I don't have to keep any state in memory other than what buckets there are (and if things are bad enough, I can do two stages of buckets - often mimicking a binary search in reverse, if there's a massive number). Once I've gotten everything at least first-letter alphabetized, I go through with a mergesort on each bucket, or if I'm able to hold all the documents or books at once, I just do an insertion sort.
However, whenever I need to sort a deck of cards (to make sure it's a full deck, for instance), I just play a game of Klondike solitaire, cheating as needed. It's slower, sure, but more fun that way.
A rough sort to throw out irrelevant debris reduces the whole task by 90%. It's a lot like code review: once you've thrown out all the useless legacy crap, mercilessly, what's left is a lot more useful and easier to understand.
Books on a shelf. A loose binary search then a linear search for a tiny subset of 3-4 books and finally insertion of the book.
I suppose you could call it a hash table- where the whole book is hashed down into a short string... called the TITLE...
Democracy Now! - uncensored, anti-establishment news
When I'm sorting things in meatspace, I use a heap sort.
I throw all the shit into a heap, then pick out the good bits.
If it isn't for anything important, I usually just do a bubblesort as it is such an easy algorithm and call it a day.
The one true sorting algorithm.
and nothing else, for this kind of thing.
With the jazz band I play in, we have a book full of a few hundred charts. When resorting them after a gig, I typically grab a small stack, sort it insertion style, set it aside, then do the same to another pile. Once a few piles have been done, they get merge sorted into a big pile. Big piles themselves are merge sorted, until all of my music is in order.
(((dB)))
I use Balloon Sort.
That's when I pick up each document, and attach it to a balloon filled with a specified amount of helium based on either date or alphanumeric index. Then I let it go.
Voila! By the time I reach the last paper, they have all naturally sorted themselves vertically!
One at a time.
Be seeing you...
This might work...
“He’s not deformed, he’s just drunk!”
Bubble sort. 'cause it's the best!
These are the steps I use to sort stuff...
1. Extract hard drive from computer that needs sorting.
2. Insert it into working Linux system and copy all user files that need to be kept to a directory
3. Reinstall the hard drive back into the non booting computer
4. Reinstall windows on the broken computer (or use the factory reset if it has one)
5. Transfer the needed files via a samba share to the now sorted computer.
6. Snoop through my co-workers files and post the funny ones on the internet. (optional)
7. Collect reward, and bask in the glory of being called a miracle worker and saving all those (interchangeable) photos of co-worker children etc while giving (pointless) lecture on making backups.
There are variants of this that involve using live CDs and USB drives or only doing step 4 but these can cause unwanted complications that I prefer to avoid and often result in skipping some or all of step 7.
[The Universe] has gone offline.
If I were sorting something alphabetically, I would do radix sort to sort everything by letter, then I do insertion sort on each pile.
I studied computer science too, but I think the overhead of doing a sort with better time complexity actually is a significant hindrance for me to actually use it in practice. I'm never going to sort more than like a hundred things (because I'm lazy), and a computer is never going to take longer than a second to sort a million things. So it makes sense for me to use the sort with lowest overhead and for a computer to use a sort with the best time complexity.
That said, I might do a merge sort the next time I have to sort something just to make it more entertaining.
Find the lowest paid person in the office and have them sort it for me. If they want to use some fancy sorting algorithm they learned in college, they can knock themselves out.
Mainly because I'm out of sorts...
Lawrence Person (lawrencepersonh@gmailh.com (remove all "h"s to mail)
http://www.lawrenceperson.com/
"We don't. We declare chaos as the standard."
I agree, as long as you wash on cold sorting should not be an issue.
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
Fond memories of bucket-sorting (I always called it bin sorting) on temp jobs in the early 90s. The early 90s had a lot of paper-to-digital temp jobs like that. It was an OK way to pick up cash when "real jobs" were hard to find. Entering insurance claims from paper forms was probably the most interesting. The last time I did anything like this was business reply cards in 2004. That one came off Craigslist. Gigs like that have to be getting few and far between since everybody has a device now. BTW, if you put a joke address on a business-reply card it actually brightens the otherwise boring day of the data entry clerk.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I've got some experience sorting huge stacks of pages. You basically want to maximize the work done per trivial-human-step. If you stick with some algorithm based on binary-comparisons you're missing out on some of the work a brain can do essentially for free.
If you're sorting based on a number, it's a pretty quick easy step to drop the current paper in one of ten piles. If you're sorting by alphabetical then you can do one pass 26 piles (bulky but workable) or two pass (first pass A-F, G-M, N-S, T-Z, second pass sort into individual letters). This provides you with more than one bit-comparison of sorting per action. If you're sorting by date then year, month, first-digit-day, second-digit-day make excellent radix values.
Merge sort isn't bad, but it's probably less efficient. If you work with two-stack merge you're only getting one bit of work per step. If you work with more than two stacks you have to scan the tops of the stacks to figure out which page to pick up. Contrast this with radix sort - it's quicker/easier to look at one page and drop it in one of N piles than it is to scan N piles to find which one to pick up.
I see a lot of people mentioning bubble sort and related sorts, but I doubt those people ever had to deal with a few hundred pages. Those sorts are O(N^2), inherently worse. And shuffling the order of pages in a stack is a much messier and slower physical operation than simply dropping pages on the top of stack.
All the other sorting algorithms I can think of seem to suffer from smaller work per step and/or messy physical manipulation. I'm open to other suggestions, but Radix sort seems to be best suited to human work. I had great success with it.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Keep it putting elements in a random order until the correct order appears.
For MTG Cards I use a few sorting methods.
The goal is to have them split up so that the colors are in their individual bins; each of those bins are sub-binned as either creatures, enchantments, or sorceries/instants/interrupts; and then all cards are alphabetized within each of the sub-bins. Multi-colored cards I don't bother with the sub-binning but instead alphabetize them after the color binning because there are a lot less of them.
For the initial color binning I use a few runs of quick sort.
A single run of quick sort to divide them into the sub-bins of creatures, enchantments or sorceries/instants/interrupts. (Damn Theros trying to throw a wrench into my plan, I finally decided to simply treat the Enchantment Creatures as enchantments because that was the first word)
For alphabetizing the cards I start with a binary tree on the first letter of the card to bin them and then I use insertion sort on each bin. I intentionally start with the tree with a card whose first letter is around the middle of the alphabet. Next a recursive tree tracing algorithm to put the bins back together in order. Finally an "insertion sort" of these now sorted new cards into my already sorted old cards.
That first insertion sort could probably be replaced by a more efficient algorithm but after all the binning the largest bin is usually no more than 30 cards. The next "insertion sort" is really something else I forgot the name of but the thing is I'm running it on two already presorted arrays so the indexes into both arrays only need to keep growing and make single pass of each array to put the cards away.
When I get a couple of booster boxes per release and want them split up and alphabetized as described above definitely need a sorting algorithm.
I use a heuristic to pick the pivot for quicksort. Quicksort is great because you only have to work on two piles at a time. Once I'm down to a pile of 6-8 or so, I'll just insertion sort them.
You can actually split into more than 2 buckets for the first round, but I find this slows me down a lot. Having to remember "A-L over here versus M-Z over there" is a lot easier than trying to keep straight "A-F there, G-L there, M-R there, S-Z there".
However, for enormous piles (many hundreds to thousands of pages) that can be radix-sorted, that's usually a much better method.
I had a professor in college (Rensselaer Polytechnic InstItute) who would lay all of his papers and work on a desk. At a point in the year (I can't remember if it was end of calendar or school year) he would just place a sheet over his desk, covering it. The sheet was labelled in the corner with the year. If he needed anything from previous years, he would just lift up the corners of the sheet to the right year and start looking.
His desk was a solid foot thick with papers and sheets.
Jdj
Like a boss!
The garbage truck sorts my paperwork for me.
An SQL query goes to a bar, walks up to a table and asks, "Mind if I join you?"
I always use insertion sort. Oh, except when I'm being dealt cards. Then I use quicksort.
although radix is a close second. Depends on the mess I'm dealing with at the time.
"Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana
For things like receipts, I use a half-bucket sort, which runs in N time.
There are 12 piles, one for each month. Items from the first half of the year go on the bottom of the pile, items from the second half go on the top of the pile. That of course means that physically there are 12 stacks, but logically there are 24 buckets - early January, late January, early February, late February, etc.
The next step is - nothing. For receipts, sorting into 24 buckets is close enough that I'll be able to find what I'm looking for later.
Yea, having a sort-All is pretty handy. However, playing solitaire with the dates of your documents will provide a mistake-proof and certain way to get your documents in order. I saw a good demonstration by Persi Diaconis on Yo9u Tube.
This is slashdot, ok, so I'm not surprised no one came up with sunsort
list sonsort( list ) {
static father me;
return me->son("sort!",list);
}
There are fewer illiterates than people who can't read.
I sort by time
I actually sorted a large stack of numbered papers using quicksort. I chose it because it seemed to work well in the case of slow to move/compare paper.
You pick the pivot, initially at random but with re-selections based on the knowledge of the total set. After that, you can step through the whole stack in a fairly automatic way, paper by paper, easily putting papers into the left/right stacks by just shifting them left and right. No slow paper by paper insertions or other checks. Just a paper by paper step through to divide the pile (hopefully) into two; lower-lower-greater-lower-greater-etc-etc
I repeated the operation on the sub-stacks until they were at about ~5-10 papers. At this point I'd like to say I insertion sorted, but really I just shuffled them into position. And at the end, once all substacks are sorted, you just place them on top of one another and you're done.
The biggest problem I had was moving the substacks around and finding space for them once their numbers started getting larger. I would consider this the biggest bottleneck in the method.
Overall the operation seemed to work well considering the additional difficulty of actually physically moving the paper around by hand. But if someone reckons there was a better method I for one would be interested in hearing it.
May the Maths Be with you!
always a bucket sort. but they don't teach those in CS courses.
A slightly different question: how do you optimize 'bins' to sort things into? There's a pile of paper on your desk, some of it clearly belongs to one of the multiple projects you're working on, but some belongs to multiple projects. Some are in the pile because they seemed "interesting" or "revelant" in some way to things you're thinking about, but not in ways that are clear or straightforward.
How do you take a random pile of paper and *quickly* come up with the smallest set of categories with at least one member which will encompass everything in the pile?
Just like this
However you sort, make sure you staple them to keep your receipts in order.
This is particularly important if you subsequently enter them into an accounting program or even a spreadsheet.
And if you use an IRS approved system you don't even need to keep the originals. Just be damned sure you've got backups in case something happens.
People get confused when sorting receipts by date?
Please, for the love of just pull a darwin.
I'll send the chlorine to help the gene pool.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
I don't actually sort them. I just tag them all 0 through n.
Then I create indexes.
It depends on the size of the available desk space.
How were you originally sorting? Were you partitioning the receipts into separate piles, based on some date? And then taking each pile and sorting them? How is this NOT one of those fancy sorting algorithms you learned in comp sci? And how was a radix search faster?
First, I construct medium-size piles via insertion sort. That works great as long as there are few enough things that I can spread them all out and see where to insert new ones. Once that gets crowded, I stack that into a pile and put it aside. Repeat until every document is in a sorted stack.
Then I merge-sort the stacks.
All in all, I find it a reasonably efficient method.
I just pass the list to the intern helper-object, and let the environment deal with the implementation.
It's easy to apply formal sort algorithms to things that are easy to compare.
Lacking an appropriate comparator, I always fail to sort socks in a reasonable time. Any tips?
Every now and then, I need to sort a stack of a few dozen numbered envelopes in numerical order. The first two digits are the same (year) and the last two digits go up to 70-something.
I once used quicksort, but found it too cumbersome for the task at hand.
What I do now is just deal them into piles by the second digit. Each stack is small enough that it's easy to just eyeball-sort them, starting with the 0 stack and ending at the 7 stack.
The method I commonly use is human-aided computer sort. This is how it works. You hand over the sixty or something papers to 60 people while entering the sortable field of each paper in a spreadsheet as you do it. Sort the field on the spreadsheet and collect the sheets back from the fellas in the sorted order. As a bonus you get the soft copy of the entire index. And it only takes O(n).
If I got a lot of place, I separate in category , the bubble sort. Otehrwise I bubble sort from the start. No , really. I reserve radix sort or qsort to my programs.
i perfer the 'unordered heap' data structure. Just create pointers to the elements in the heap and sort the pointer any way you want.
...does sorting give any benefit in the long run?
I keep all my receipts (and bank statements etc...) in a binder without sorting them. One binder per year (sort of).
If/when I need one of the receipts, I simply look through the binder for the relevant year (s). Time spent per search is a fracion of the time I would need to sort them.
As I usually do not know the date of the receipt when I start looking, sorting by date would not provide a benefit anyway.
. So, when you have to physically sort things, what algorithm (if any) do you use?"
The pitchsort algorithm AKA a bonfire. Works even better in winter!
Of I just toss it if it's a bill. They'll send another...
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
Paul Drake: "Do you know his name?"
Perry Mason: "No"
Paul Drake: "Do you really want me to take all these receipts and compare each against everything else? Do you know how long will it take, Perry?
Perry Mason: "Paul, Just sort these receipts by name and look for duplicates"
Donald Knuth, quoting Erle Stanley Gardener, in the chapter on sorting in the TeX book.
[Quoting from memory, please forgive inaccuracies].
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I use the 52-pick-up sort
http://alternatives.rzero.com/
If you remember, the O(N^2) shuffe sort is fastest on piles n =6 So I. make sorted piles of 6. These sorted piles of 6 are done using the brains only internal intutitve sort. Then you linear sort the piles of 6 together. I try to go for as many piles at the same time, not just 2. If fact this is more limited by distance than anything else. Since you are sorting things with a physical representation you need to take the time cost of moving yourself into account. With a deck of cards, there is no move costs but with dozens of 8x11 or A4 papers, reach becomes a factor.
I've been doing this since 2001 and I have yet to find a better way.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I sort things into what's known as a stack, or a pile, and then I put them in the freezer.
Teacher here. I often have to sort stacks of 20-40 exams, and I use a two step-method. First, I radix-sort the exams in five stacks, e.g. A-C, D-G, H-M, N-R, S-Z, and then I spread out each stack and sort it using selection sort (this goes very quickly since each stack has around 6 exams in it).
I tried fancy algorithms such as merge sort and quicksort, but for physical sorting of a small number of exams, the method above is quicker.
Grab a paper, go through the already sorted papers and put it at the right place. Its n*(n/2) (approximately), because i do no binary search, but search from top/bottom whats more likely to be the shorter way (with some intuition about the already inserted papers). So its O(n)
Year has 12 months.
(Standard) wall clock has 12 hours.
I sit in the center with the pile in front of me and sort the months onto stacks based on the hour. (12 in front of me, 3 to my right, etc.) After a few minutes, you don't need to look at the stacks. I don't bother secondary sorting within each month, so it's O(n).
If I'm looking at receipts against statements, when I go through a month a few receipts will inevitably need to progress forward to the next pile. (Receipts from the past show up on statements in the future, but not the other way around.)
Scan and sort using http://www.neat.com/products/n... I've seen it on TV, it must be good right?
This is something that duplicate bridge players do about 25 times a session . We use insertion sort.
When a player picks up a hand, it is typically shuffled, but players prefer to have cards separated by suits and descending order within each suit. Most people pick up their 13 cards and then move individual cards around using insertion sort. It is quite intuitive and relatively quick. However, insertion sort has a few other bridge-specific advantages: often players can evaluate their hand even as they are sorting it by first moving the high cards in place. Also, it is not necessary to completely sort the hand -- spot cards can be in any order and you will often find players sorting the spot cards before they put down as dummy.
I suppose the complete answer would be that humans use insertion sort to result in a partially sorted hand.
As an aside, all-time great bridge player Bob Hamman does not sort his hand. Just as moderately skilled bridge players do not sort the "spot cards" because they can figure those out on the fly, Bob Hamman can visualize and remember the entire hand without needing to sort it.
This is something that duplicate bridge players do about 25 times a session . We use insertion sort. When a player picks up a hand, it is typically shuffled, but players prefer to have cards separated by suits and descending order within each suit. Most people pick up their 13 cards and then move individual cards around using insertion sort. It is quite intuitive and relatively quick. However, insertion sort has a few other bridge-specific advantages: often players can evaluate their hand even as they are sorting it by first moving the high cards in place. Also, it is not necessary to completely sort the hand -- spot cards can be in any order and you will often find players sorting the spot cards before they put down as dummy. I suppose the complete answer would be that humans use insertion sort to result in a partially sorted hand. As an aside, all-time great bridge player Bob Hamman does not sort his hand. Just as moderately skilled bridge players do not sort the "spot cards" because they can figure those out on the fly, Bob Hamman can visualize and remember the entire hand without needing to sort it.
From smaller to larger data volumes, humans tend to employ:
20 items: selection (direct) sort
20-50 items: something like bubblesort or multiple splits, e.g. quicksort-like
50-500 items: definately heapsort, mergesort (without knowing it)
500+ items: just give up, or do it as a hobby over the holidays...
"Abashed the Devil stood, and felt how awful goodness is..."
I find DumpsterSort to be the quickest and most efficient for my boxes of old papers.
One type sort their stuff..
The other type leave the piles as is and index mentally. Most people have had the experience of being in somebody's incredibly cluttered workshop/office/kitchen and the person is able to just conjure up mentally where the thing he/she needs is and go directly there.
Star Trek transporters are just 3d printers.
While sorting through my MtG cards I usually start by sorting by color (easiest to notice), then I sort each pile by expansion. These two can go straight to their own piles. After that I sort within expansion by forming two piles, one with cards from A-N and second from O-Z (this point being the natural split for alphabets in my mind). Finally depending on the size of the remaining pile I either do an optimized bubble sort in my hand or continue splitting until I reach a point where bubble sort is easy enough to handle (no pun intended). This method I've found the easies to visualize and it provied many easy breakpoints when I get sick of sorting more cards.
I let the program import the sortable items in MS excel and sort them there.
Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
Most teachers I knew naturally used a variant of merge sort when sorting a pile of test papers. Most didn't know anything about formal sorting algorithms.