Bogo-bogosort

http://www.dangermouse.net/esoteric/bogobogosort.html

by luu • 13 years ago

64 32 13 years ago

cardamomo• 13 years ago

My favorite line: "as anyone who knows anything at all about computer science knows, recursion is always good and cool."

deletes7• 13 years ago

My addition to the algorithm: Every time your check if arrays is sorted and it isn't, start from the very beginning throwing away all progress made so far.

I doubt this way n == 6 would finish in some normal time period.

zardeh• 13 years ago

bogosort does that already.

I ran it on an the array [0,1,2,3,4,5,6] and it took between 3 hundred million and 1 billion operations (by my marginally accurate counter) and between 6 and 20 minutes, but mine was in python, not C.

deletes7• 13 years ago

Welcome to HN.

I was referring to OPs algorithm which was bogo-bogosort.

At first I though my change would not increase the complexity, but I think it is dependent on size of input since for every recursion there is a chance to fail and start completely over, where the number of recursion is dependent on input size. Therefore it adds to complexity.

duncanwest2• 13 years ago

You say it will take on average n! attempts to find a sorted list randomly. This is false. It will take on average n!/2 attempts.

deletes7• 13 years ago

O(n!/2) == O(n!), the whole paragraph is obviously referring to big o notation.

edit:( I have edited the post to respond to your comment, trying to clarify what OP meant; I in no way tried to make your comment "look silly" )

duncanwest2• 13 years ago

Yes, but that's not what he says. He says "The loop will repeat on average n! times". That's not true. He's not referring to O notation there, he brings that in later. Here he's talking about the imperative number of times a loop will run on average.

Edit: you've edited your paragraph to make my reply look silly. The whole paragraph is not in O notation. In fact - the exact opposite. In the last sentence of that paragraph he shows what the expression with constant factors looks like before converting it into O notation, and it's wrong! "The product (n-1)n! is O(n × n!)." Bzzzzzzt! Wrong! He should say "The product (n-1)(n!/2) is O(n × n!)."

aquamongoose• 13 years ago

True, but that's still O(n!), so the overall complexity doesn't change.

thetwiceler• 13 years ago

The mean would certainly be n! (note that it is possible, and even likely, that you may create the same sorting multiple times by random chance).

The median, which I don't think you're referring to, is something else (I imagine it would be substantially less than the mean).

(See http://en.wikipedia.org/wiki/Geometric_distribution)

eridius2• 13 years ago

This seems completely pointless. The elegance of bogosort is that it's an extremely simple algorithm, with a simple description of "randomize until it's sorted". Bogobogosort is complicated for no apparent reason. It's trying to be cute and clever, but there's no rationale for why additional complexity is being added.

Bogobogosort seems in the end to be no more worthwhile than sleepybogosort, where you must sleep() in between every operation.

deletes7• 13 years ago

No, since the complexity of bogosort with sleep is still O(n!), while the algorithm from OP has a higher bound.

eridius2• 13 years ago

Depends on how you do the sleeps.

egypturnash• 13 years ago

I think half the point of this is the straight-faced, detailed examination of exactly how terrible this proposed sort is.

Or at least that's the part that made me start giggling...

elwell3• 13 years ago

If all you have is a hammer, everything looks like a nail. It's for this reason that computer scientists created bogobogosort (and sleepybogosort, as you mentioned). For example, bogobogosort tests memory cards more efficiently than a smaller-space algorithm like bogosort. In this case, the recursive nature of bogobogosort acts as space multiplier and fully fills the memory cards (be it DIMM or others). Don't be so quick to judge an algorithm just because it's new.

Also, I'm working on a Bogo programming language with randomized compilation; if anyone is interested in contributing, let me know.

Zombieball• 13 years ago

My favourite is still Intelligent Design Sort:

http://www.dangermouse.net/esoteric/intelligentdesignsort.ht...

O(1) run time!

avaku• 13 years ago

Genius :)

mikeash4• 13 years ago

This got me thinking about a more generalized approach to this sort of thing.

Given a task where you can check completion somehow, you can then solve it using the following procedure:

1. Generate a random program. (This could be a Turing machine, bytecode, C source, whatever.)

2. Execute the program on the input for n steps, where n is an incrementing counter.

3. Execute the given check on the output. If the check passes, return the output.

4. Increment n and go back to 1.

The restriction on n steps avoids running afoul of the Halting Problem.

The check has to be a little more rigorous than the one used in Bogosort. It can't just check to see if the output is in order, because the output may contain completely different numbers, since the program could be doing anything. You'd have to check not only for order but also that the output is in fact a permutation of the input.

I wonder what the running time of this algorithm is. I wonder if it can even be calculated.

fragsworth2• 13 years ago

We both came up with nearly the same idea at nearly the same time (within one minute) - what are the odds of that?

My solution is slightly different - to avoid the Halting Problem, you can use a distributed approach. You have a very large (but finite) number of processors that you pass your programs to.

mikeash4• 13 years ago

"what are the odds of that?"

I'm not sure, maybe we should build an unbelievably inefficient program to calculate them.

gcr• 13 years ago

Why not just pass it to an infinite number of processors and use a nondeterministic Turing machine?

But with an NDTM, even NP-complete problems can be solved within polynomial time.

deletes7• 13 years ago

(Assuming the programs are of length n generated using random ascii characters 0-127, and the number n starts out at 1, and the next time around is 2, then 3, and so forth.)

We are splitting the programs generated this way into two piles.

First pile are all the programs that don't compile and all the programs that compile and don't rely on size of the array that we want to sort. A very small number of programs compile . As n grows larger the number of programs that compile grows smaller as the chance of a random character error grows larger factorially. As n goes to infinity the ratio of programs that don't compile to programs that do, becomes divergent; in other words: the number of programs that don't compile tends to infinity and programs that do compile tends to zero. Therefore we can assume every program in first pile is a program that doesn't compile.

The second pile are the programs that compile and actually rely on the size of the array. The complexity of these programs is dependent on their algorithm. We are assuming the worst case where every algorithm is of complexity O(n!).

But errors in the programs from second pile also grows factorially. So the number of programs in second pile compared to first also approaches zero as n goes to infinity.

Complexity of programs in the first pile, since they don't rely on the input( where input is the size of the array ), is constant. Where the constant is the number n( steps ).

As n tends to infinity the number of the seconds programs tends to zero and their complexity becomes negligible. Therefore the total complexity becomes either O(1) or O(inf).

If you choose the n to stop at a finite number, then the complexity of the program is O(1)

If you choose n never stop, to become infinite then the algorithm never ends.

Feel free to comment, please refer to specific parts of the solution.

edit: Complexity of programs that fails to compile, or compile and don't rely on the size of the array is O(1), since that specific program always executes in the same time as it takes no variable input that would change regarding to size of the array.

mikeash4• 13 years ago

If you choose n to be a non-infinite number, then the complexity of the program is O(1) If you choose n to be infinite then the complexity is O(inf)

I'm not sure I understand this, or you've understood me. The number n starts out at 1, and the next time around is 2, then 3, and so forth.

fragsworth2• 13 years ago

Here is a "distributed" sorting algorithm that requires even less thinking - you don't even have to write a shuffling algorithm!

1) Start with an empty string.

2) Increment the string in such a way that will eventually generate all strings.

3) Give the string (and your unsorted array) to a processor that attempts to run the string as a program and go back to step 2.

When a processor is given a program, if the output contains all the elements of A and the output is sorted, stop everything! You've sorted the array.

It requires O(n^m) processors, where n is the number of characters possible in a program, and m is the string length of the code that finds the solution. Lots of the processors will be stuck in infinite loops.

elwell3• 13 years ago

Isn't this how evolution works?

sesqu• 13 years ago

No.

Evolution doesn't involve resets - the hint is in the name.

ChristianMarks2• 13 years ago

I have a soft spot in my head for turdsort, which attempts to optimize over bogosort, but ends up being no better.

  #!/usr/bin/python
  from random import shuffle

  def turdsort(a):
    def turds(a):
      n = 0
      for i in xrange(len(a)-1):
        if a[i] > a[i+1]:
          n += 1
      return n

    count = 1
    n = len(a)
    t = turds(a)
    while n > 0:
      while t >= n:
        shuffle(a)
        t = turds(a)
        count += 1
      n = t
    return count

  if __name__ == '__main__':
    a = range(10)
    print a
    print turdsort(a)
    shuffle(a)
    print a
    print turdsort(a)

ChristianMarks2• 13 years ago

There is also the slightly less pointless ordersort, which works only on permutations. The complexity of ordersort is given by the Landau function. It is more efficient than bogosort, however.

  #!/usr/bin/python

  def gcd(a,b):
    while b:
      a, b = b, a % b
    return a

  def order(a):
    """compute the order of the permutation a"""
    lcm = 1 
    for i in range(len(a)):
      j = a[i]
      while j > i:
        j = a[j]
      if j == i: # i is a cycle leader
        j = a[j]	# get next element of cycle
        cyc = 1;	# the cycle has length at least 1
        while j != i:   # the cycle hasn't closed
          cyc += 1
          j = a[j]
        lcm = (lcm/gcd(lcm,cyc))*cyc
    return lcm

  def ordersort(a):
    ord = order(a)
    print ord
    b = range(len(a))
    while ord > 0:
      b = map((lambda i: a[i]), b)
      ord -= 1
    return b

  if __name__ == '__main__':
    from random import shuffle
    a = range(50);
    shuffle(a)
    print a, ordersort(a)

jerf• 13 years ago

I snort in fake outrage that nobody has seen fit to reference the definitive work on this topic: http://ivanych.net/doc/PessimalAlgorithmsAndSimplexityAnalys... (Check out section 5 in particular for today's topic.)

Bogo-bogosort

Related Stories