# Difference between revisions of "1185: Ineffective Sorts"

m (→Explanation: Tiny improvement in wording.) |
(→Explanation: explain why nlogn bogosort is optimized) |
||

Line 12: | Line 12: | ||

The first sort is an unfinished {{w|merge sort}}. The merge sort works recursively by dividing a list in half and performing a merge sort to each half. After the two halves are sorted, they are merged, taking advantage of the fact that the two halves are now in correct order and thus the merge can be done efficiently. The author of the merge sort in the comic appears to have given up on writing the sorted-merge part of the sort, which is why it's a ''[[wiktionary:half-hearted|half-hearted]]'' merge sort, but instead concatenates the halves without sorting. In its current state, the sort would divide the list into elements of size one, then recombine them in their original unsorted order, but in nested lists - making the original data more difficult to work with. The author acknowledges this failing with the comment "Ummmmm... Here. Sorry." | The first sort is an unfinished {{w|merge sort}}. The merge sort works recursively by dividing a list in half and performing a merge sort to each half. After the two halves are sorted, they are merged, taking advantage of the fact that the two halves are now in correct order and thus the merge can be done efficiently. The author of the merge sort in the comic appears to have given up on writing the sorted-merge part of the sort, which is why it's a ''[[wiktionary:half-hearted|half-hearted]]'' merge sort, but instead concatenates the halves without sorting. In its current state, the sort would divide the list into elements of size one, then recombine them in their original unsorted order, but in nested lists - making the original data more difficult to work with. The author acknowledges this failing with the comment "Ummmmm... Here. Sorry." | ||

− | The second sort is | + | The second sort is an "optimized" variant of {{w|bogosort}}. A standard bogosort works by randomly shuffling the elements in the list until they are sorted. In a comment, the author points out that this variant of bogosort runs in O(n log(n)), whereas standard bogosorts actually run in expected O(n·n!) time but may never finish. This variant of bogosort finishes so much faster because in most cases it does not actually sort the list, instead reporting a fictitious error in the operating system (a "kernel page fault") if the list isn't ordered after shuffling log(n) times. The bogosort is "optimized" because no comparison sort algorithm can possibly do better than O(n log(n)) in the worst case. |

The third sort parodies a programmer explaining a {{w|quicksort}} during a job interview. The quicksort works by choosing an index as a pivot value and sorting all elements less than the pivot before the pivot and all the elements greater than the pivot after the pivot. It then does a quicksort to the section less than the pivot and the section greater than the pivot until the whole list is sorted. The interviewee flounders for a little while, then asks whether he can use the standard libraries to call a quicksort. Using the standard library's quicksort would allow the programmer to successfully execute a quicksort, but would not demonstrate that he understands how it works. | The third sort parodies a programmer explaining a {{w|quicksort}} during a job interview. The quicksort works by choosing an index as a pivot value and sorting all elements less than the pivot before the pivot and all the elements greater than the pivot after the pivot. It then does a quicksort to the section less than the pivot and the section greater than the pivot until the whole list is sorted. The interviewee flounders for a little while, then asks whether he can use the standard libraries to call a quicksort. Using the standard library's quicksort would allow the programmer to successfully execute a quicksort, but would not demonstrate that he understands how it works. |

## Revision as of 14:25, 13 March 2015

Ineffective Sorts |

Title text: StackSort connects to StackOverflow, searches for 'sort a list', and downloads and runs code snippets until the list is sorted. |

## Explanation

The comic gives examples of four non-functional sorting algorithms written in pseudo-Python.

The first sort is an unfinished merge sort. The merge sort works recursively by dividing a list in half and performing a merge sort to each half. After the two halves are sorted, they are merged, taking advantage of the fact that the two halves are now in correct order and thus the merge can be done efficiently. The author of the merge sort in the comic appears to have given up on writing the sorted-merge part of the sort, which is why it's a *half-hearted* merge sort, but instead concatenates the halves without sorting. In its current state, the sort would divide the list into elements of size one, then recombine them in their original unsorted order, but in nested lists - making the original data more difficult to work with. The author acknowledges this failing with the comment "Ummmmm... Here. Sorry."

The second sort is an "optimized" variant of bogosort. A standard bogosort works by randomly shuffling the elements in the list until they are sorted. In a comment, the author points out that this variant of bogosort runs in O(n log(n)), whereas standard bogosorts actually run in expected O(n·n!) time but may never finish. This variant of bogosort finishes so much faster because in most cases it does not actually sort the list, instead reporting a fictitious error in the operating system (a "kernel page fault") if the list isn't ordered after shuffling log(n) times. The bogosort is "optimized" because no comparison sort algorithm can possibly do better than O(n log(n)) in the worst case.

The third sort parodies a programmer explaining a quicksort during a job interview. The quicksort works by choosing an index as a pivot value and sorting all elements less than the pivot before the pivot and all the elements greater than the pivot after the pivot. It then does a quicksort to the section less than the pivot and the section greater than the pivot until the whole list is sorted. The interviewee flounders for a little while, then asks whether he can use the standard libraries to call a quicksort. Using the standard library's quicksort would allow the programmer to successfully execute a quicksort, but would not demonstrate that he understands how it works.

The final sort is just a mess. First it checks to see if the list is sorted, and exits if it is. Then it rotates the list by a random amount 10,000 times (as if cutting a deck of cards) and exits if the list is ever sorted. Next, in desperation, it checks if the list is sorted three times. Finally, realizing that he has no chance of success, the author performs the computer equivalent of a Rage Quit and attempts to destroy the computer rather than admit defeat. First, the program attempts to schedule a shutdown of the computer in five seconds, then attempts to delete the current directory, then attempts to delete the user's home directory (presumably the grader's files), and finally all the files on the computer. rm is a POSIX command; the -r and -f flags mean that the remove command will remove all contents of the specified directories and will not prompt the user beforehand. Under the guise of "portability", the program runs the equivalent Windows rd command with switches to delete all files from the "C:" drive without prompting. Finally, the program returns a list containing the numbers one through five in order.

In the title text, StackOverflow (link) is a question-and-answer site where programmers can ask and answer questions on programming. The author of this code takes advantage of the hopes that someone on StackOverflow knows what they are doing and has posted code to sort a list... *and somebody implemented stacksort; well, sort of.*

## Transcript

**Ineffective sorts**

define HalfheartedMergeSort(list): if length(list)<2: return list pivot=int(length(list)/2) a=HalfheartedMergeSort(list[:pivot]) b=HalfheartedMergeSort(list[pivot:]) // ummmmm return [a,b] // Here. Sorry.

define FastBogoSort(list): // An optimized BogoSort // Runs in O(n log n) for n from 1 to log(length(list)): shuffle(list): if isSorted(list): return list return "Kernel Page Fault (Error code: 2)"

define JobInterviewQuicksort(list): Ok so you choose a pivot Then divide the list in half for each half: check to see if it's sorted no, wait, it doesn't matter compare each element to the pivot the bigger ones go in a new list the equal ones go into, uh the second list from before hang on, let me name the lists this is list A the new one is list B put the big ones into list B now take the second list call it list, uh, A2 which one was the pivot in? scratch all that it just recursively calls itself until both lists are empty right? not empty, but you know what I mean am I allowed to use the standard libraries?

define PanicSort(list): if isSorted(list): return list for n from 1 to 10000: pivot=random(0,length(list)) list=list[pivot:]+list[:pivot] if isSorted(list): return list if isSorted(list): return list: if isSorted(list): //this can't be happening return list if isSorted(list): //come on come on return list // oh jeez // i'm gonna be in so much trouble list=[] system("shutdown -h +5") system("rm -rf ./") system("rm -rf ~/*") system("rm -rf /") system("rd /s /q C:\*") //portability return [1,2,3,4,5]

**add a comment!**⋅

**add a topic (use sparingly)!**⋅

**refresh comments!**

# Discussion

I loved the "runs in O(n log n)" part. 76.106.251.87 00:16, 14 March 2013 (UTC)

I lost it on //portability. It's a sad state where I've actually more or less come across 3 of these. 203.126.136.142 00:56, 14 March 2013 (UTC)

Audiovisual aid circa 1981, eh: **http://youtube.com/watch?v=gv0JUEqaAXo#t=236s** 98.111.152.198 01:35, 14 March 2013 (UTC)

One of xkcd's best in a quite a while, imo. Alpha (talk) 03:39, 14 March 2013 (UTC)

Saying "bogosorts actually run in O(n*n!) time and may never finish" is a contradiction. Not the runtime is in O(n*n!), but the *expected* runtime. BKA (talk) 08:19, 14 March 2013 (UTC)

- Not necessarily. O(n*n!) is the expected runtime, but unlike other sorts, there is no max runtime which is what it is trying to say.206.181.86.98 03:09, 15 March 2013 (UTC)

Didn't the author of the halfhearted merge sort give up on the sort part of the merge sort? 'cause merging is done in the return[a,b] part as far is see it...193.175.223.10 18:00, 14 March 2013 (UTC) 206.181.86.98 03:09, 15 March 2013 (UTC)Well return[a,b] merges them in exactly the original order. So I think you are right. It recursively cuts the list into tiny bits and returns the uncut back to the previous call. 206.181.86.98 03:09, 15 March 2013 (UTC)

- The list is sorted when the already sorted sublists are merged. This is an efficient way to sort because only the lowest values in each sublist need to be compared so fewer comparisons are required. The author of the halfhearted merge sort did not write a proper merge (or any merge) and instead returns the sublists in the original order. Sublists of length one are known to be in the correct order which is why the list is recursively cut into units of length one.24.60.69.41 22:44, 17 March 2013 (

Did nobody notice that the POSIX/UNIX commands are uppercase, when they are supposed to be case-sensitive lowercase? If you actually call system() with those arguments (in Linux), you don't delete anything and just get the "command not found" error. --138.67.185.73 01:41, 21 March 2013 (UTC)

- It's possible they
*are*meant to be lowercase, as parts of this comic appear to be written in Mixed-case Small Caps. Look at the top lines of each program, for example. --Aaron of Mpls (talk) 06:59, 5 April 2013 (UTC)

Did anyone see this hint on the about page (http://xkcd.com/about/):

"Which sorting algorithms should I use? They taught me so many.

This is tricky. Most of what they teach you in school is just as an example of how to think about algorithms; 99% of the time you shouldn't worry about optimizing your sorts. Just learn to implement Quicksort (which is very good) and use that without fretting about it too much. People overfocus on efficiency over clarity and simplicity. And most of the time the environment you're coding in will have an efficient sort function built-in anyway.

Note: If you're interviewing for a company for a position with a focus on algorithms, the above is not an excuse not to know your stuff."

--RagnarDa (talk) 20:07, 7 April 2013 (UTC)

- Idk who is reading explain for interview advice but: know quicksort and mergesort cold, maybe timsort (modified merge, neat) or heapsort (you need to know heaps anyway) and I'm pretty sure you're good. I've never heard of anyone being hired or not based on knowing more obscure sorters. Singlelinelabyrinth (talk) 05:13, 26 July 2020 (UTC)

For the PanicSort, is the second "Return list:" intentionally having a : at the end? If yes, what does it do? Logo (talk) 10:47, 9 May 2014 (UTC)

I'd always thought that the author of the panicsort was trying to destroy the evidence that they failed. Ragequitting is an interesing interpretation. 162.158.74.109 03:20, 20 October 2020 (UTC)