explain xkcd - User contributions [en]

Talk:1185: Ineffective Sorts

2013-03-17T22:45:06Z

24.60.69.41:

I loved the "runs in O(n log n)" part. [[Special:Contributions/76.106.251.87|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. [[Special:Contributions/203.126.136.142|203.126.136.142]] 00:56, 14 March 2013 (UTC)

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

One of xkcd's best in a quite a while, imo. [[User:Alpha|Alpha]] ([[User talk: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. [[User:BKA|BKA]] ([[User talk: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.[[Special:Contributions/206.181.86.98|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...[[Special:Contributions/193.175.223.10|193.175.223.10]] 18:00, 14 March 2013 (UTC)
[[Special:Contributions/206.181.86.98|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. [[Special:Contributions/206.181.86.98|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.[[Special:Contributions/24.60.69.41|24.60.69.41]] 22:44, 17 March 2013 (UTC)

Talk:1185: Ineffective Sorts

2013-03-17T22:44:06Z

24.60.69.41:

I loved the "runs in O(n log n)" part. [[Special:Contributions/76.106.251.87|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. [[Special:Contributions/203.126.136.142|203.126.136.142]] 00:56, 14 March 2013 (UTC)

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

One of xkcd's best in a quite a while, imo. [[User:Alpha|Alpha]] ([[User talk: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. [[User:BKA|BKA]] ([[User talk: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.[[Special:Contributions/206.181.86.98|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...[[Special:Contributions/193.175.223.10|193.175.223.10]] 18:00, 14 March 2013 (UTC)
[[Special:Contributions/206.181.86.98|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. [[Special:Contributions/206.181.86.98|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 mege (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.[[Special:Contributions/24.60.69.41|24.60.69.41]] 22:44, 17 March 2013 (UTC)

Talk:1185: Ineffective Sorts

2013-03-17T22:38:49Z

24.60.69.41:

Talk:1185: Ineffective Sorts

2013-03-17T22:37:37Z

24.60.69.41:

I loved the "runs in O(n log n)" part. [[Special:Contributions/76.106.251.87|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. [[Special:Contributions/203.126.136.142|203.126.136.142]] 00:56, 14 March 2013 (UTC)

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

One of xkcd's best in a quite a while, imo. [[User:Alpha|Alpha]] ([[User talk: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. [[User:BKA|BKA]] ([[User talk: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.[[Special:Contributions/206.181.86.98|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...[[Special:Contributions/193.175.223.10|193.175.223.10]] 18:00, 14 March 2013 (UTC)
[[Special:Contributions/206.181.86.98|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. [[Special:Contributions/206.181.86.98|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 mege (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.

1185: Ineffective Sorts

2013-03-13T18:26:12Z

24.60.69.41:

{{comic
| number = 1185
| date = March 13, 2013
| title = Ineffective Sorts
| image = ineffective_sorts.png
| titletext = 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, dividing itself in half and doing 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 with a minimum number of comparisons. The sort will divide the list until it contains elements of size one, then would begin merging. However, the author of the merge sort in the comic appears to have given up on writing the merge part of the sort. In its current state, the sort would divide the list into elements of size one, do nothing to them, and return the two halves of the original list.

The second sort is a bogosort, a sort that works by randomly shuffling the elements in the list. It claims to run in O(nlog(n)) time although bogosorts typically run in O(n*n!) time and may never finish. It achieves this by returning an error if the list isn't ordered after shuffling log(n) times.

The third sort parodies a programmer explaining a quicksort during a job interview. The quicksort works by choosing a 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 they know 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 cuts the list 10,000 times (like a deck of cards) and exits if the list is sorted. Next, in desperation, it checks if the list is sorted three times. It then empties the list, tries to shutdown the computer and attempts to delete first the current directory, second the user's home directory, and finally the entire file system. rm is a gnu 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. The program next runs rd, the windows equivalent of rm, in an attempt to delete the "C:" drive. The /s flag does the same thing as -r and the /q flag does the same thing as -f. Finally, the program returns a list containing the numbers one through five in order.

==Transcript==


{{comic discussion}}