views:

4214

answers:

32

I had this question on an Algorithms test yesterday, and I can't figure out the answer. It is driving me absolutely crazy, because it was worth about 40 points. I figure that most of the class didn't solve it correctly, because I haven't come up with a solution in the past 24 hours.

Given a arbitrary binary string of length n, find three evenly spaced ones within the string if they exist. Write an algorithm which solves this in O(n * log(n)) time.

so strings like these have three ones that are "evenly spaced": 11100000, 0100100100

edit: It is a random number, so it should be able to work for any number. The examples I gave were to illustrate the "evenly spaced" property. So 1001011 is a valid number. With 1, 4, and 7 being ones that are evenly spaced.

A: 

An adaptation of the Rabin-Karp algorithm could be possible for you. Its complexity is 0(n) so it could help you.

Take a look http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm

esylvestre
Rabin-Karp uses string hashing to find exact substrings, so it can't help with the problem.
Robert Parker
+6  A: 

I suspect that a simple approach that looks like O(n^2) will actually yield something better, like O(n ln(n)). The sequences that take the longest to test (for any given n) are the ones that contain no trios, and that puts severe restrictions on the number of 1's that can be in the sequence.

I've come up with some hand-waving arguments, but I haven't been able to find a tidy proof. I'm going to take a stab in the dark: the answer is a very clever idea that the professor has known for so long that it's come to seem obvious, but it's much too hard for the students. (Either that or you slept through the lecture that covered it.)

Beta
lol, no I didn't sleep through any lectures. I talked with a few other students, and no one had a clear idea on how to solve it. Most wrote some BS about divide and conquer in a plea to get some partial credit.
Robert Parker
+1 that's exactly what I found out in my experiments.
flybywire
A: 

This seemed liked a fun problem so I decided to try my hand at it.

I am making the assumption that 111000001 would find the first 3 ones and be successful. Essentially the number of zeroes following the 1 is the important thing, since 0111000 is the same as 111000 according to your definition. Once you find two cases of 1, the next 1 found completes the trilogy.

Here it is in Python:

def find_three(bstring):
    print bstring
    dict = {}
    lastone = -1
    zerocount = 0
    for i in range(len(bstring)):
        if bstring[i] == '1':
            print i, ': 1'
            if lastone != -1:
                if(zerocount in dict):
                    dict[zerocount].append(lastone)
                    if len(dict[zerocount]) == 2:
                        dict[zerocount].append(i)
                        return True, dict
                else:
                    dict[zerocount] = [lastone]
            lastone = i
            zerocount = 0
        else:
            zerocount = zerocount + 1
    #this is really just book keeping, as we have failed at this point
    if lastone != -1:
        if(zerocount in dict):
            dict[zerocount].append(lastone)
        else:
            dict[zerocount] = [lastone]
    return False, dict

This is a first try, so I'm sure this could be written in a cleaner manner. Please list the cases where this method fails down below.

James McMahon
Doesn't seem to work on 1101001
recursive
@recursive, those are not evenly spaced.
James McMahon
What do you mean by evenly spaced? Look at index 0, 3, and 6. All ones, and with two separating each.
recursive
Oh I see, as I understood it, zeros were only included in the spacing.
James McMahon
The question does mention "1001011", on which this doesn't work. There was an earlier (now deleted) answer, posted immediately after the question was asked, which solved the same (other) problem as this one. :-)
ShreevatsaR
I was looking at this at work today and I didn't understand what Rob meant with his edit. I've edited the question for clarity. I should have known I was missing something when I had an easy time with it.
James McMahon
how can you prove your algorithm is O(nlogn)?
ldog
+2  A: 

Wasn't able to come up with the solution yet :(, but have some ideas.

What if we start from a reverse problem: construct a sequence with the maximum number of 1s and WITHOUT any evenly spaced trios. If you can prove the maximum number of 1s is o(n), then you can improve your estimate by iterating only through list of 1s only.

Olexiy
Well, the number of 1's is certainly bounded above by O(n). It can't be O(n**2), right -- the number of 1's grows faster than the data? The important question is whether the upper limit is lower than that.
hughdbrown
I used the small o, not the big one
Olexiy
+1  A: 

For the simple problem type (i.e. you search three "1" with only (i.e. zero or more) "0" between it), Its quite simple: You could just split the sequence at every "1" and look for two adjacent subsequences having the same length (the second subsequence not being the last one, of course). Obviously, this can be done in O(n) time.

For the more complex version (i.e. you search an index i and an gap g>0 such that s[i]==s[i+g]==s[i+2*g]=="1"), I'm not sure, if there exists an O(n log n) solution, since there are possibly O(n²) triplets having this property (think of a string of all ones, there are approximately n²/2 such triplets). Of course, you are looking for only one of these, but I have currently no idea, how to find it ...

MartinStettner
Yes, we are discussing the harder version of the problem. Still, the n*log(n) solution may be possible.
Olexiy
there are actually n choose 3 which is O(n^3) possible triples, I think when you said approximately n^2/2 you where thinking n choose 2
ldog
@gmatt: n choose 2 is enough; if we fix two 1s the position of the third is determined and it's constant-time to see if there's a 1 at that position or not.
ShreevatsaR
@ShreevatsaR: yea thats right I think, I was thinking of the unconstrained case.
ldog
@gmatt: actually, we're looking for Tuples (i,g) as defined above with the constraints that 0<=i<(n-3) and 0<g<(n-i-1)/2, hence the estimate of n^2/2 ...
MartinStettner
If it can be proven that worst density of ones is k*log(n) that it is easy to solve this in n*log(n). That mean that this is not problem of algorhitm but of provability
ralu
A: 

Could this be a solution? I', not sure if it's O(nlogn) but in my opinion it's better than O(n²) because the the only way not to find a triple would be a prime number distribution.

There's room for improvement, the second found 1 could be the next first 1. Also no error checking.

#include <iostream>

#include <string>

int findIt(std::string toCheck) {
    for (int i=0; i<toCheck.length(); i++) {
     if (toCheck[i]=='1') {
      std::cout << i << ": " << toCheck[i];
      for (int j = i+1; j<toCheck.length(); j++) {
       if (toCheck[j]=='1' && toCheck[(i+2*(j-i))] == '1') {
        std::cout << ", " << j << ":" << toCheck[j] << ", " << (i+2*(j-i)) << ":" << toCheck[(i+2*(j-i))] << "    found" << std::endl;
        return 0;
       }
      }
     }
    }
    return -1;
}

int main (int agrc, char* args[]) {
    std::string toCheck("1001011");
    findIt(toCheck);
    std::cin.get();
    return 0;
}
DaClown
Technically this is O(n^2). On average the inner loop will iterate over half of n each time it is run. So it could be written as O(n*(n/2)), and that can be simplified to O(n^2)
Robert Parker
Hm, looks like you're right. This is not a simple problem, just to find all the 1 takes O(n), not much room for any further search/comparision with O(logn) complexity.
DaClown
A: 

One inroad into the problem is to think of factors and shifting.

With shifting, you compare the string of ones and zeroes with a shifted version of itself. You then take matching ones. Take this example shifted by two:

1010101010
  1010101010
------------
001010101000

The resulting 1's (bitwise ANDed), must represent all those 1's which are evenly spaced by two. The same example shifted by three:

1010101010
   1010101010
-------------
0000000000000

In this case there are no 1's which are evenly spaced three apart.

So what does this tell you? Well that you only need to test shifts which are prime numbers. For example say you have two 1's which are six apart. You would only have to test 'two' shifts and 'three' shifts (since these divide six). For example:

10000010 
  10000010 (Shift by two)
    10000010
      10000010 (We have a match)

10000010
   10000010 (Shift by three)
      10000010 (We have a match)

So the only shifts you ever need to check are 2,3,5,7,11,13 etc. Up to the prime closest to the square root of size of the string of digits.

Nearly solved?

I think I am closer to a solution. Basically:

  1. Scan the string for 1's. For each 1 note it's remainder after taking a modulus of its position. The modulus ranges from 1 to half the size of the string. This is because the largest possible separation size is half the string. This is done in O(n^2). BUT. Only prime moduli need be checked so O(n^2/log(n))
  2. Sort the list of modulus/remainders in order largest modulus first, this can be done in O(n*log(n)) time.
  3. Look for three consecutive moduli/remainders which are the same.
  4. Somehow retrieve the position of the ones!

I think the biggest clue to the answer, is that the fastest sort algorithms, are O(n*log(n)).

WRONG

Step 1 is wrong as pointed out by a colleague. If we have 1's at position 2,12 and 102. Then taking a modulus of 10, they would all have the same remainders, and yet are not equally spaced apart! Sorry.

Jonathan Swift
This is an interesting approach, let us know if you come up with a full solution.
James McMahon
shift by a number k O(n) times and then O(n) checks per shift yields an O(n^2) algorithm, even if you were shifting by one number. Your algorithm would have to shift by more than one number.
ldog
I think you're on the right track here, check my solution.
NickLarsen
A: 

This is possible to solve in linear time O(n)

  1. start at beginning, and wait for first 1
  2. Start counting zeros.
  3. When you hit 1 store number of counted zeros (valid number is also 0) NumberOfZeros -> PrevZeros
  4. Start counting zeros.
  5. When you hit 1 check NumberOfZeros == PrevZeros

    If true return counter

    else NumberOfZeros -> prev_zeros and goto 4

ralu
@ralu, this is what I did in my answer. The problem is a lot more complicated because 1 can also be a spacer.
James McMahon
i didn not think of that, but if whole stackowerflow did not crack this in in 2 days, how would somebody solve this problem in 1hour during exam?
ralu
Best idea I can think of now, would be using property that desity of ones is at most n/ln(n) (phi funtcion from prime density) if there is no solution.That mean that this can be solved in n^2/log(n) time.
ralu
This can be easily solved in n*log(n) if can be proven that worst density is k*log(n) in long run.
ralu
+1  A: 

A fun question, but once you realise that the actual pattern between two '1's does not matter, the algorithm becomes:

  • scan look for a '1'
  • starting from the next position scan for another '1' (to the end of the array minus the distance from the current first '1' or else the 3rd '1' would be out of bounds)
  • if at the position of the 2nd '1' plus the distance to the first 1' a third '1' is found, we have evenly spaces ones.

In code, JTest fashion, (Note this code isn't written to be most efficient and I added some println's to see what happens.)

import java.util.Random;

import junit.framework.TestCase;

public class AlgorithmTest extends TestCase {

 /**
  * Constructor for GetNumberTest.
  *
  * @param name The test's name.
  */
 public AlgorithmTest(String name) {
  super(name);
 }

 /**
  * @see TestCase#setUp()
  */
 protected void setUp() throws Exception {
  super.setUp();
 }

 /**
  * @see TestCase#tearDown()
  */
 protected void tearDown() throws Exception {
  super.tearDown();
 }

 /**
  * Tests the algorithm.
  */
 public void testEvenlySpacedOnes() {

  assertFalse(isEvenlySpaced(1));
  assertFalse(isEvenlySpaced(0x058003));
  assertTrue(isEvenlySpaced(0x07001));
  assertTrue(isEvenlySpaced(0x01007));
  assertTrue(isEvenlySpaced(0x101010));

  // some fun tests
  Random random = new Random();

  isEvenlySpaced(random.nextLong());
  isEvenlySpaced(random.nextLong());
  isEvenlySpaced(random.nextLong());
 }

 /**
  * @param testBits
  */
 private boolean isEvenlySpaced(long testBits) {
  String testString = Long.toBinaryString(testBits);
  char[] ones = testString.toCharArray();
  final char ONE = '1';

  for (int n = 0; n < ones.length - 1; n++) {

   if (ONE == ones[n]) {
    for (int m = n + 1; m < ones.length - m + n; m++) {

     if (ONE == ones[m] && ONE == ones[m + m - n]) {
      System.out.println(" IS evenly spaced: " + testBits + '=' + testString);
      System.out.println("               at: " + n + ", " + m + ", " + (m + m - n));
      return true;
     }
    }
   }
  }

  System.out.println("NOT evenly spaced: " + testBits + '=' + testString);
  return false;
 }
}
rsp
If I'm not mistaken, this is O(n²) because the outer loop runs n times and the inner loop runs n/2 times on average.
StriplingWarrior
The outer loop runs n times and the inner loop runs n/4 on average but is only started from positions following an '1'. To approach an n^2 behaviour the number of '1's must be high which results in a true result early thereby stopping processing. Therefore the n^2 behaviour will never occur. How to determine an O based on known properties of the data escapes me at the moment.
rsp
Unfortunatly it's not about average real life runtime but rather theoretical Big O runtime. And your approach is O(n²) (same as mine because your approach is the same as mine)
DaClown
I was not talking about average behaviour, but maximum behaviour. I would not be surprised if it's provable that the maximum entropy that fails the test contains log n '1's in the string.
rsp
What if you update the index in the outer loop with that of the first 1 found in the inner loop i.e., if (ones[m] == ONE) {n = m}? Does that help the big O?
steamer25
You can add optimisations like that which help a bit, but the outer loop skips '0's quickly already so I'ld expect the extra code making you change the outer index only to the first '1' found negates the time won in the outer loop. The overall behaviour of the system does not change.
rsp
A: 

I assume the reason this is nlog(n) is due to the following:

  • To find the 1 that is the start of the triplet, you need to check (n-2) characters. If you haven't found it by that point, you won't (chars n-1 and n cannot start a triplet) (O(n))
  • To find the second 1 that is the part of the triplet (started by the first one), you need to check m/2 (m=n-x, where x is the offset of the first 1) characters. This is because, if you haven't found the second 1 by the time you're halfway from the first one to the end, you won't... since the third 1 must be exactly the same distance past the second. (O(log(n)))
  • It O(1) to find the last 1 since you know the index it must be at by the time you find the first and second.

So, you have n, log(n), and 1... O(nlogn)

Edit: Oops, my bad. My brain had it set that n/2 was logn... which it obviously isn't (doubling the number on items still doubles the number of iterations on the inner loop). This is still at n^2, not solving the problem. Well, at least I got to write some code :)


Implementation in Tcl

proc get-triplet {input} {
    for {set first 0} {$first < [string length $input]-2} {incr first} {
        if {[string index $input $first] != 1} {
            continue
        }
        set start [expr {$first + 1}]
        set end [expr {1+ $first + (([string length $input] - $first) /2)}]
        for {set second $start} {$second < $end} {incr second} {
            if {[string index $input $second] != 1} {
                continue
            }
            set last [expr {($second - $first) + $second}]
            if {[string index $input $last] == 1} {
                return [list $first $second $last]
            }
        }
    }
    return {}
}

get-triplet 10101      ;# 0 2 4
get-triplet 10111      ;# 0 2 4
get-triplet 11100000   ;# 0 1 2
get-triplet 0100100100 ;# 1 4 7
RHSeeger
+1  A: 

I thought of a divide-and-conquer approach that might work.

First, in preprocessing you need to insert all numbers less than one half your input size (n/3) into a list.

Given a string: 0000010101000100 (note that this particular example is valid)

Insert all primes (and 1) from 1 to (16/2) into a list: {1, 2, 3, 4, 5, 6, 7}

Then divide it in half:

100000101 01000100

Keep doing this until you get to strings of size 1. For all size-one strings with a 1 in them, add the index of the string to the list of possibilities; otherwise, return -1 for failure.

You'll also need to return a list of still-possible spacing distances, associated with each starting index. (Start with the list you made above and remove numbers as you go) Here, an empty list means you're only dealing with one 1 and so any spacing is possible at this point; otherwise the list includes spacings that must be ruled out.

So continuing with the example above:

1000 0101 0100 0100

10 00 01 01 01 00 01 00

1 0 0 0 0 1 0 1 0 1 0 0 0 1 0 0

In the first combine step, we have eight sets of two now. In the first, we have the possibility of a set, but we learn that spacing by 1 is impossible because of the other zero being there. So we return 0 (for the index) and {2,3,4,5,7} for the fact that spacing by 1 is impossible. In the second, we have nothing and so return -1. In the third we have a match with no spacings eliminated in index 5, so return 5, {1,2,3,4,5,7}. In the fourth pair we return 7, {1,2,3,4,5,7}. In the fifth, return 9, {1,2,3,4,5,7}. In the sixth, return -1. In the seventh, return 13, {1,2,3,4,5,7}. In the eighth, return -1.

Combining again into four sets of four, we have:

1000: Return (0, {4,5,6,7}) 0101: Return (5, {2,3,4,5,6,7}), (7, {1,2,3,4,5,6,7}) 0100: Return (9, {3,4,5,6,7}) 0100: Return (13, {3,4,5,6,7})

Combining into sets of eight:

10000101: Return (0, {5,7}), (5, {2,3,4,5,6,7}), (7, {1,2,3,4,5,6,7}) 01000100: Return (9, {4,7}), (13, {3,4,5,6,7})

Combining into a set of sixteen:

10000101 01000100

As we've progressed, we keep checking all the possibilities so far. Up to this step we've left stuff that went beyond the end of the string, but now we can check all the possibilities.

Basically, we check the first 1 with spacings of 5 and 7, and find that they don't line up to 1's. (Note that each check is CONSTANT, not linear time) Then we check the second one (index 5) with spacings of 2, 3, 4, 5, 6, and 7-- or we would, but we can stop at 2 since that actually matches up.

Phew! That's a rather long algorithm.

I don't know 100% if it's O(n log n) because of the last step, but everything up to there is definitely O(n log n) as far as I can tell. I'll get back to this later and try to refine the last step.

EDIT: Changed my answer to reflect Welbog's comment. Sorry for the error. I'll write some pseudocode later, too, when I get a little more time to decipher what I wrote again. ;-)

Platinum Azure
I don't follow your algorithm, but +1 for trying an algorithm that actually tries to be O(n log n)
ldog
Thanks. I'll try to explain it better when I get more time (maybe write some pseudocode or something).
Platinum Azure
Why are you only looking at gap possibilities of primes? How would you propose to match a string like `100010001`? If I understand your approach correctly, it won't be able to match it because the correct answer `(0,{4})` isn't possible to compute. Given that you need non-primes in your list, it's easy to come up with pathological strings that inflate the lists of possibilities that you need to check to higher than O(n log(n)), I think.
Welbog
*swears* Well, I was originally going to do multiples, but I sort of changed my answer midway through and didn't get to changing everything. Sorry. Will fix shortly
Platinum Azure
I don't think it's O(n log n). In the first combine step, you treat (n/2) sets, each of which possibly returning a set of O(n) possible spacings. This alone makes it O(n^2), unfortunately.
MartinStettner
Unfortunate indeed. I have yet to see anything better, though. Personally I don't think an O(n log n) solution is possible for this problem.
Platinum Azure
@Platinum Azure: I tend to agree. I agree with the comment on the question that suggests maybe the asker is remembering the problem statement wrong.
Welbog
A: 

I think I have found a way of solving the problem, but I can't construct a formal proof. The solution I made is written in Java, and it uses a counter 'n' to count how many list/array accesses it does. So n should be less than or equal to stringLength*log(stringLength) if it is correct. I tried it for the numbers 0 to 2^22, and it works.

It starts by iterating over the input string and making a list of all the indexes which hold a one. This is just O(n).

Then from the list of indexes it picks a firstIndex, and a secondIndex which is greater than the first. These two indexes must hold ones, because they are in the list of indexes. From there the thirdIndex can be calculated. If the inputString[thirdIndex] is a 1 then it halts.

public static int testString(String input){
//n is the number of array/list accesses in the algorithm
int n=0;

//Put the indices of all the ones into a list, O(n)
ArrayList<Integer> ones = new ArrayList<Integer>();
for(int i=0;i<input.length();i++){
 if(input.charAt(i)=='1'){
  ones.add(i);
 }
}

//If less than three ones in list, just stop
if(ones.size()<3){
 return n;
}

int firstIndex, secondIndex, thirdIndex;
for(int x=0;x<ones.size()-2;x++){
 n++;
 firstIndex = ones.get(x);

 for(int y=x+1; y<ones.size()-1; y++){
  n++;
  secondIndex = ones.get(y);
  thirdIndex = secondIndex*2 - firstIndex;

  if(thirdIndex >= input.length()){
   break;
  }

  n++;
  if(input.charAt(thirdIndex) == '1'){
   //This case is satisfied if it has found three evenly spaced ones
   //System.out.println("This one => " + input);
   return n;
  }
 }
}

return n;

}

additional note: the counter n is not incremented when it iterates over the input string to construct the list of indexes. This operation is O(n), so it won't have an effect on the algorithm complexity anyway.

Robert Parker
You still seem to have two loops of O(n), nested, which makes it O(n^2)
RHSeeger
The array of indexes isn't the same size as the input string. This is making it hard for me to write a real proof or to prove it is incorrect. I suspect that there is some underlying mathematical idea that makes this work.
Robert Parker
A random string would have, in general, an equal number of 1s and 0s. Your array of indexes would be of length n/2... it grows in length at a speed of n/2, so the algorithmic complexity should be unchanged at n^2.
RHSeeger
I tested it for the entire range 0 to 2^22, and for any of these cases it was never more than O(nlogn). This isn't an exhaustive proof, but I think it shows that there is something here.
Robert Parker
I think the trick to this problem is that despite your algorithm being O(n^2), the worst possible case of a string you can get will only result in O(nlogn) iterations otherwise you will have found a solution using your algorithm.
yx
a O(nlogn) divide and conquer solution will keep splitting the input array into 2 or more parts and recurse on each part; I'm pretty sure your algorithm is O(n^2) unless you can somehow prove that the two loops in your algorithm are O(n log n) (from my experience this never works, unless there is a very very specific mathematical property of what you are looping over.)
ldog
testing it up to 2^22 doesn't really test it's complexity. 2^22 only has 22 bits, which means your N is 22. Try it for a few values where N is a few million.
Peter Recore
Try this algorithm with one of the maximal "bad" strings given in yx's answer and you'll find this is an `O(n^2)` algorithm.
Welbog
+7  A: 

This is not a solution, but a similar line of thought to what Olexiy was thinking

I was playing around with creating sequences with maximum number of ones, and they are all quite interesting, I got up to 125 digits and here are the first 3 numbers it found by attempting to insert as many '1' bits as possible:

  • 11011000011011000000000000001101100001101100000000000000000000000000000000000000000110110000110110000000000000011011000011011
  • 10110100010110100000000000010110100010110100000000000000000000000000000000000000000101101000101101000000000000101101000101101
  • 10011001010011001000000000010011001010011001000000000000000000000000000000000000010011001010011001000000000010011001010011001

Notice they are all fractals (not too surprising given the constraints). There may be something in thinking backwards, perhaps if the string is not a fractal of with a characteristic, then it must have a repeating pattern?

Thanks to beta for the better term to describe these numbers.

Update: Alas it looks like the pattern breaks down when starting with a large enough initial string, such as: 10000000000001:

100000000000011
10000000000001101
100000000000011011
10000000000001101100001
100000000000011011000011
10000000000001101100001101
100000000000011011000011010000000001
100000000000011011000011010000000001001
1000000000000110110000110100000000010011
1000000000000110110000110100000000010011001
10000000000001101100001101000000000100110010000000001
10000000000001101100001101000000000100110010000000001000001
1000000000000110110000110100000000010011001000000000100000100000000000001
10000000000001101100001101000000000100110010000000001000001000000000000011
1000000000000110110000110100000000010011001000000000100000100000000000001101
100000000000011011000011010000000001001100100000000010000010000000000000110100001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001
1000000000000110110000110100000000010011001000000000100000100000000000001101000010010000010000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001
1000000000000110110000110100000000010011001000000000100000100000000000001101000010010000010000001100010000000010000000000000000000000000000000000000000100000010000000000000011
1000000000000110110000110100000000010011001000000000100000100000000000001101000010010000010000001100010000000010000000000000000000000000000000000000000100000010000000000000011000000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001000100100000100000000000001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001000001000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001000100100000100000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001000001000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000011
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001000001000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000011000001
1000000000000110110000110100000000010011001000000000100000100000000000001101000010010000010000001100010000000010000000000000000000000000000000000000000100000010000000000000011000000001100100000000100100000000000010000000010000100000100100010010000010000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000110000010000000000000000000001
1000000000000110110000110100000000010011001000000000100000100000000000001101000010010000010000001100010000000010000000000000000000000000000000000000000100000010000000000000011000000001100100000000100100000000000010000000010000100000100100010010000010000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000110000010000000000000000000001001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001000100100000100000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000001100000100000000000000000000010010000000000000000000000000000000000001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001000001000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000011000001000000000000000000000100100000000000000000000000000000000000011
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001000001000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000011000001000000000000000000000100100000000000000000000000000000000000011001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001000100100000100000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000001100000100000000000000000000010010000000000000000000000000000000000001100100000000000000000000001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001000100100000100000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000001100000100000000000000000000010010000000000000000000000000000000000001100100000000000000000000001001
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001000100100000100000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000001100000100000000000000000000010010000000000000000000000000000000000001100100000000000000000000001001000001
100000000000011011000011010000000001001100100000000010000010000000000000110100001001000001000000110001000000001000000000000000000000000000000000000000010000001000000000000001100000000110010000000010010000000000001000000001000010000010010001001000001000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000011000001000000000000000000000100100000000000000000000000000000000000011001000000000000000000000010010000010000001
1000000000000110110000110100000000010011001000000000100000100000000000001101000010010000010000001100010000000010000000000000000000000000000000000000000100000010000000000000011000000001100100000000100100000000000010000000010000100000100100010010000010000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000110000010000000000000000000001001000000000000000000000000000000000000110010000000000000000000000100100000100000011
10000000000001101100001101000000000100110010000000001000001000000000000011010000100100000100000011000100000000100000000000000000000000000000000000000001000000100000000000000110000000011001000000001001000000000000100000000100001000001001000100100000100000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000001100000100000000000000000000010010000000000000000000000000000000000001100100000000000000000000001001000001000000110000000000001
yx
Holy *@!!, these are FRACTALS! If this holds up, it puts an upper bound on the number of 1's, and it's less than O(n).
Beta
fractals, that's a much better term to describe them. Thanks
yx
Interesting, these patterns closely resembles Cantor's ternary set (http://en.wikipedia.org/wiki/Cantor_set). If this is so, then the proportion of ones has to tend to zero...
flybywire
Is it obvious that the sequences with the maximum number of 1s without triples are directly relevant to the worst-case running time of the algorithm? It is conceivable that you could have strings with lots of 1s but in which you only find the triples very late, as those 1s are in the positions that are examined late by your algorithm.
ShreevatsaR
My analysis of the number of ones in the strings compared to their overall size seems to indicate that there is a linear relationship between number of ones and size of string, leading me to believe that there is no happy upper bound that lets us say that the number of ones in a string will be at most log(n) for a given string. So the solutions dealing only with the positions of the ones and not the entire string itself are going to be O(n^2), too. Or, more accurately, O(n+m^2), where m is the number of ones in the string, and n is the size of the string, and m is big-theta(n).
Welbog
I've observed that the candidates that take the most iterations to examine in sets of n-length binary strings are those that have 3/8 to 5/8 1's. The 1-length/total length for a worst-case candidate falls below 50% after 17 characters. No science here, just observations.
hughdbrown
+1  A: 

I'll give my rough guess here, and let those who are better with calculating complexity to help me on how my algorithm fares in O-notation wise

  1. given binary string 0000010101000100 (as example)
  2. crop head and tail of zeroes -> 00000 101010001 00
  3. we get 101010001 from previous calculation
  4. check if the middle bit is 'one', if true, found valid three evenly spaced 'ones' (only if the number of bits is odd numbered)
  5. correlatively, if the remained cropped number of bits is even numbered, the head and tail 'one' cannot be part of evenly spaced 'one',
  6. we use 1010100001 as example (with an extra 'zero' to become even numbered crop), in this case we need to crop again, then becomes -> 10101 00001
  7. we get 10101 from previous calculation, and check middle bit, and we found the evenly spaced bit again

I have no idea how to calculate complexity for this, can anyone help?

edit: add some code to illustrate my idea

edit2: tried to compile my code and found some major mistakes, fixed

char *binaryStr = "0000010101000100";

int main() {
   int head, tail, pos;
   head = 0;
   tail = strlen(binaryStr)-1;
   if( (pos = find3even(head, tail)) >=0 )
      printf("found it at position %d\n", pos);
   return 0;
}

int find3even(int head, int tail) {
   int pos = 0;
   if(head >= tail) return -1;
   while(binaryStr[head] == '0') 
      if(head<tail) head++;
   while(binaryStr[tail] == '0') 
      if(head<tail) tail--;
   if(head >= tail) return -1;
   if( (tail-head)%2 == 0 && //true if odd numbered
       (binaryStr[head + (tail-head)/2] == '1') ) { 
         return head;
   }else {
      if( (pos = find3even(head, tail-1)) >=0 )
         return pos;
      if( (pos = find3even(head+1, tail)) >=0 )
         return pos;
   }
   return -1;
}
andycjw
It seems to fail on 1000111 if I'm reading correctly.
recursive
@recursive i think it will work when it reached the call find3even(head+1, tail), which will then crop it to become 111 at head = 4, could you check again for me?
andycjw
@recursive please check the code I added to better explain the pseudo code I made up earlier, which is not very strict and concise
andycjw
This is nlogn - for n bits we expect approximately logn iterations checking n*c bits where C is a constant.
Ron Warholic
Yeah, this seems to fail on 111001 and 100111 as the simplest cases. The evenly spaced 1's don't have to center on the middle bit.
Dean J
It handles those cases correctly, 111001 has an even number of bits so it is immediately split into 111 and 001. Since 111 has an odd number of bits and the middle bit is one it returns successfully.
Ron Warholic
It doesn't split the string in half, it removes the tail and the head bits and tests them each. In this case, it drops the tailing 1 and recurses on 11100, which it will find. This looks correct, but I don't know about the complexity.
job
I read it wrong, I had assumed a binary split however it's just truncating 1 at a time which is an O(n) making this O(n^2).
Ron Warholic
@sid this is especially difficult for calculating complexity because of the problem space, it's not truncating 1 at a time as you mentioned, it's truncating to the next available bit 'one', e.g. 101010000001, it fails at first try, then it will truncate till 10101, which is the next available bit 'one' from the tail; it is very difficult to think of a worse case for this algorithm, the best i could think if is 1010100101010101.....01, this would take only O(n/2) = O(n) for this algorithm, can anyone give a worse case for this solve?
andycjw
I like the divide and conquer approach, but I got a headache trying to compute the complexity... based on your approach, I would think as a 'void' string as your worst case, by that I mean 1..10..01..1 pattern (like 110011 or 111000111), the idea is to prevent the 0-stripping and yet always have a 0 at the middle of the string.
Matthieu M.
Correction, we can exploit the lack of symmetry of the algorithm, since it always starts stripping by the end. So 10..01..1 would be even worse. That's what you get with a lack of parallelism (though it would not change the complexity, just the runtime).
Matthieu M.
@Matthieu I think you're right, the asymmetry is caused by the depth first search approach of the algorithm, if slightly modified to work it as breadth first search approach (e.g. strip left, if fail then go back to strip right, so on and so on, instead of stripping left, fail, then keep on stripping left). hope you get what I mean.
andycjw
Yes I understand. However my first remark using 111100001111 would still remain valid even with this modification... now I don't know what would be the complexity :(
Matthieu M.
A: 

I think this algorithm has O(n log n) complexitiy (C++, DevStudio 2k5). Now, I don't know the details of how to analyse an algorithm to determine its complexity, so I have added some metric gathering information to the code. The code counts the number of tests done on the sequence of 1's and 0's for any given input (hopefully, I've not made a balls of the algorithm). We can compare the actual number of tests against the O value and see if there's a correlation.

#include <iostream>
using namespace std;

bool HasEvenBits (string &sequence, int &num_compares)
{
  bool
    has_even_bits = false;

  num_compares = 0;

  for (unsigned i = 1 ; i <= (sequence.length () - 1) / 2 ; ++i)
  {
    for (unsigned j = 0 ; j < sequence.length () - 2 * i ; ++j)
    {
      ++num_compares;
      if (sequence [j] == '1' && sequence [j + i] == '1' && sequence [j + i * 2] == '1')
      {
        has_even_bits = true;
        // we could 'break' here, but I want to know the worst case scenario so keep going to the end
      }
    }
  }

  return has_even_bits;
}

int main ()
{
  int
    count;

  string
    input = "111";

  for (int i = 3 ; i < 32 ; ++i)
  {
    HasEvenBits (input, count);
    cout << i << ", " << count << endl;
    input += "0";
  }
}

This program outputs the number of tests for each string length up to 32 characters. Here's the results:

 n  Tests  n log (n)
=====================
 3     1     1.43
 4     2     2.41
 5     4     3.49
 6     6     4.67
 7     9     5.92
 8    12     7.22
 9    16     8.59
10    20    10.00
11    25    11.46
12    30    12.95
13    36    14.48
14    42    16.05
15    49    17.64
16    56    19.27
17    64    20.92
18    72    22.59
19    81    24.30
20    90    26.02
21   100    27.77
22   110    29.53
23   121    31.32
24   132    33.13
25   144    34.95
26   156    36.79
27   169    38.65
28   182    40.52
29   196    42.41
30   210    44.31
31   225    46.23

I've added the 'n log n' values as well. Plot these using your graphing tool of choice to see a correlation between the two results. Does this analysis extend to all values of n? I don't know.

Skizz

Skizz
It's not a perfect correlation, I agree. However, the curve is closer to n log n than it is to n^2.
Skizz
Try pumping the input size up through a million or more. At small inputs the curve often looks similar to the the curves of algorithms which are obviously better when the input sized is pumped up.
NickLarsen
A double for loop with the inner one bounded by the outer one makes for a triangular shape, which is still O(n^2) in complexity. Think of all (i,j) such that i in [0,n] and j in [0,n-2*i], you have a triangle, and the area of a triangle has a quadratic tendency.
Matthieu M.
To be precise, Tests = (n^2-2n)/4 for even n; obviously quadratic.
Grandpa
+1  A: 

I came up with something like this:

def IsSymetric(number):
    number = number.strip('0')

    if len(number) < 3:
        return False
    if len(number) % 2 == 0:
        return IsSymetric(number[1:]) or IsSymetric(number[0:len(number)-2])
    else:
        if number[len(number)//2] == '1':
            return True
        return IsSymetric(number[:(len(number)//2)]) or IsSymetric(number[len(number)//2+1:])
    return False

This is inspired by andycjw.

  1. Truncate the zeros.
  2. If even then test two substring 0 - (len-2) (skip last character) and from 1 - (len-1) (skip the first char)
  3. If not even than if the middle char is one than we have success. Else divide the string in the midle without the midle element and check both parts.

As to the complexity this might be O(nlogn) as in each recursion we are dividing by two.

Hope it helps.

Beku
It looks like you're converting a problem with N elements into 2 problems with N-1 elements. Dividing it in half would mean converting it into 2 problems with N/2 elements.
RHSeeger
That's only the case for even lengths. So if the len is 8 the algorithm creates strings of length: 7, 7, 3, 3, 3, 3. The hight of the recursion tree is 3 and that equals lg(8).
Beku
+2  A: 

This may help....

This problem reduces to the following:

Given a sequence of positive integers, find a contiguous subsequence partitioned into a prefix and a suffix such that the sum of the prefix of the subsequence is equal to the sum of the suffix of the subsequence.

For example, given a sequence of [ 3, 5, 1, 3, 6, 5, 2, 2, 3, 5, 6, 4 ], we would find a subsequence of [ 3, 6, 5, 2, 2] with a prefix of [ 3, 6 ] with prefix sum of 9 and a suffix of [ 5, 2, 2 ] with suffix sum of 9.

The reduction is as follows:

Given a sequence of zeros and ones, and starting at the leftmost one, continue moving to the right. Each time another one is encountered, record the number of moves since the previous one was encountered and append that number to the resulting sequence.

For example, given a sequence of [ 0, 1, 1, 0, 0, 1, 0, 0, 0, 1 0 ], we would find the reduction of [ 1, 3, 4]. From this reduction, we calculate the contiguous subsequence of [ 1, 3, 4], the prefix of [ 1, 3] with sum of 4, and the suffix of [ 4 ] with sum of 4.

This reduction may be computed in O(n).

Unfortunately, I am not sure where to go from here.

Justice
It's a more compact notation, but it won't help the time complexity. The set of "prefix" partitions is isomorphic to an all-pairs search in all the occurences of "1", which is O(n^2).
p00ya
There are apparently algorithms out there dealing with contiguous subsequence sums. Unfortunately they all seem to deal with finding the contiguous subsequence with maximal sum in O(n).
Justice
@p00ya this is not correct. Using this algorhitm the time coplexity depends on upper limit of number of false ones, which by assupton on Cantor generated string is ((3/2)^(log(n)/log(3))) and the space complexity become this, but time complexity become this multiplyed by n. Check my second answer. (not the negative one) :D
ralu
@ralu: that's under your assumption that Cantor-generated strings are worst case, which is wrong. For the record, the number of pairs is certainly O(n^2); but I guess I was really implying that it was big-Omega(n^2), which is incorrect given [these results](http://www.math.uni.wroc.pl/~jwr/non-ave/) (see NrootN link particularly), suggesting a lower bound in the pairs of big-Omega(n^(2/1.52)) by proof or big-Omega(n^(4/3)) by conjecture.
p00ya
A: 

Assumption:

Just wrong, talking about log(n) number of upper limit of ones

EDIT:

Now I found that using Cantor numbers (if correct), density on set is (2/3)^Log_3(n) (what a weird function) and I agree, log(n)/n density is to strong.

If this is upper limit, there is algorhitm who solves this problem in at least O(n*(3/2)^(log(n)/log(3))) time complexity and O((3/2)^(log(n)/log(3))) space complexity. (check Justice's answer for algorhitm)

This is still by far better than O(n^2)

This function ((3/2)^(log(n)/log(3))) really looks like n*log(n) on first sight.

How did I get this formula?

Applaying Cantors number on string.
Supose that length of string is 3^p == n
At each step in generation of Cantor string you keep 2/3 of prevous number of ones. Apply this p times.

That mean (n * ((2/3)^p)) -> (((3^p)) * ((2/3)^p)) remaining ones and after simplification 2^p. This mean 2^p ones in 3^p string -> (3/2)^p ones . Substitute p=log(n)/log(3) and get
((3/2)^(log(n)/log(3)))

ralu
False: Cantor set has density n^log_3(2).
sdcvvc
A: 

While scanning 1s, add their positions to a List. When adding the second and successive 1s, compare them to each position in the list so far. Spacing equals currentOne (center) - previousOne (left). The right-side bit is currentOne + spacing. If it's 1, the end.

The list of ones grows inversely with the space between them. Simply stated, if you've got a lot of 0s between the 1s (as in a worst case), your list of known 1s will grow quite slowly.

using System;
using System.Collections.Generic;

namespace spacedOnes
{
    class Program
    {
        static int[] _bits = new int[8] {128, 64, 32, 16, 8, 4, 2, 1};

        static void Main(string[] args)
        {
            var bytes = new byte[4];
            var r = new Random();
            r.NextBytes(bytes);
            foreach (var b in bytes) {
                Console.Write(getByteString(b));
            }
            Console.WriteLine();
            var bitCount = bytes.Length * 8;
            var done = false;
            var onePositions = new List<int>();
            for (var i = 0; i < bitCount; i++)
            {
                if (isOne(bytes, i)) {
                    if (onePositions.Count > 0) {
                        foreach (var knownOne in onePositions) {
                            var spacing = i - knownOne;
                            var k = i + spacing;
                            if (k < bitCount && isOne(bytes, k)) {
                                Console.WriteLine("^".PadLeft(knownOne + 1) + "^".PadLeft(spacing) + "^".PadLeft(spacing));
                                done = true;
                                break;
                            }
                        }
                    }
                    if (done) {
                        break;
                    }
                    onePositions.Add(i);
                }
            }
            Console.ReadKey();
        }

        static String getByteString(byte b) {
            var s = new char[8];
            for (var i=0; i<s.Length; i++) {
                s[i] = ((b & _bits[i]) > 0 ? '1' : '0');
            }
            return new String(s);
        }

        static bool isOne(byte[] bytes, int i)
        {
            var byteIndex = i / 8;
            var bitIndex = i % 8;
            return (bytes[byteIndex] & _bits[bitIndex]) > 0;
        }
    }
}
steamer25
A: 

Here are some thoughts that, despite my best efforts, will not seem to wrap themselves up in a bow. Still, they might be a useful starting point for someone's analysis.

Consider the proposed solution as follows, which is the approach that several folks have suggested, including myself in a prior version of this answer. :)

  1. Trim leading and trailing zeroes.
  2. Scan the string looking for 1's.
  3. When a 1 is found:
    1. Assume that it is the middle 1 of the solution.
    2. For each prior 1, use its saved position to compute the anticipated position of the final 1.
    3. If the computed position is after the end of the string it cannot be part of the solution, so drop the position from the list of candidates.
    4. Check the solution.
  4. If the solution was not found, add the current 1 to the list of candidates.
  5. Repeat until no more 1's are found.

Now consider input strings strings like the following, which will not have a solution:

101
101001
1010010001
101001000100001
101001000100001000001

In general, this is the concatenation of k strings of the form j 0's followed by a 1 for j from zero to k-1.

k=2  101
k=3  101001
k=4  1010010001
k=5  101001000100001
k=6  101001000100001000001

Note that the lengths of the substrings are 1, 2, 3, etc. So, problem size n has substrings of lengths 1 to k such that n = k(k+1)/2.

k=2  n= 3  101
k=3  n= 6  101001
k=4  n=10  1010010001
k=5  n=15  101001000100001
k=6  n=21  101001000100001000001

Note that k also tracks the number of 1's that we have to consider. Remember that every time we see a 1, we need to consider all the 1's seen so far. So when we see the second 1, we only consider the first, when we see the third 1, we reconsider the first two, when we see the fourth 1, we need to reconsider the first three, and so on. By the end of the algorithm, we've considered k(k-1)/2 pairs of 1's. Call that p.

k=2  n= 3  p= 1  101
k=3  n= 6  p= 3  101001
k=4  n=10  p= 6  1010010001
k=5  n=15  p=10  101001000100001
k=6  n=21  p=15  101001000100001000001

The relationship between n and p is that n = p + k.

The process of going through the string takes O(n) time. Each time a 1 is encountered, a maximum of (k-1) comparisons are done. Since n = k(k+1)/2, n > k**2, so sqrt(n) > k. This gives us O(n sqrt(n)) or O(n**3/2). Note however that may not be a really tight bound, because the number of comparisons goes from 1 to a maximum of k, it isn't k the whole time. But I'm not sure how to account for that in the math.

It still isn't O(n log(n)). Also, I can't prove those inputs are the worst cases, although I suspect they are. I think a denser packing of 1's to the front results in an even sparser packing at the end.

Since someone may still find it useful, here's my code for that solution in Perl:

#!/usr/bin/perl

# read input as first argument
my $s = $ARGV[0];

# validate the input
$s =~ /^[01]+$/ or die "invalid input string\n";

# strip leading and trailing 0's
$s =~ s/^0+//;
$s =~ s/0+$//;

# prime the position list with the first '1' at position 0
my @p = (0);

# start at position 1, which is the second character
my $i = 1;

print "the string is $s\n\n";

while ($i < length($s)) {
   if (substr($s, $i, 1) eq '1') {
      print "found '1' at position $i\n";
      my @t = ();
      # assuming this is the middle '1', go through the positions
      # of all the prior '1's and check whether there's another '1'
      # in the correct position after this '1' to make a solution
      while (scalar @p) {
         # $p is the position of the prior '1'
         my $p = shift @p;
         # $j is the corresponding position for the following '1'
         my $j = 2 * $i - $p;
         # if $j is off the end of the string then we don't need to
         # check $p anymore
         next if ($j >= length($s));
         print "checking positions $p, $i, $j\n";
         if (substr($s, $j, 1) eq '1') {
            print "\nsolution found at positions $p, $i, $j\n";
            exit 0;
         }
         # if $j isn't off the end of the string, keep $p for next time
         push @t, $p;
      }
      @p = @t;
      # add this '1' to the list of '1' positions
      push @p, $i;
   }
   $i++;
}

print "\nno solution found\n";
jbourque
Your "non-solution" sequence is wrong; the index of each 1 is the sequence of triangular numbers 1, 3, 6, 10, 15... etc. and it includes the numbers 6, 36, and 66, which form an arithmetic progression.
Jason S
+23  A: 

Your problem is called AVERAGE in this paper (1999):

A problem is 3SUM-hard if there is a sub-quadratic reduction from the problem 3SUM: Given a set A of n integers, are there elements a,b,c in A such that a+b+c = 0? It is not known whether AVERAGE is 3SUM-hard. However, there is a simple linear-time reduction from AVERAGE to 3SUM, whose description we omit.

Wikipedia:

When the integers are in the range [−u ... u], 3SUM can be solved in time O(n + u lg u) by representing S as a bit vector and performing a convolution using FFT.

This is enough to solve your problem :).

What is very important is that O(n log n) is complexity in terms of number of zeroes and ones, not the count of ones (which could be given as an array, like [1,5,9,15]). Checking if a set has an arithmetic progression, terms of number of 1's, is hard, and according to that paper as of 1999 no faster algorithm than O(n2) is known, and is conjectured that it doesn't exist. Everybody who doesn't take this into account is attempting to solve an open problem.

Other interesting info, mostly irrevelant:

Lower bound:

An easy lower bound is Cantor-like set (numbers 1..3^n-1 not containing 1 in their ternary expansion) - its density is n^(log_3 2) (circa 0.631). So any checking if the set isn't too large, and then checking all pairs is not enough to get O(n log n). You have to investigate the sequence smarter. A better lower bound is quoted here - it's n1-c/(log(n))^(1/2). This means Cantor set is not optimal.

Upper bound - my old algorithm:

It is known that for large n, a subset of {1,2,...,n} not containing arithmetic progression has at most n/(log n)^(1/20) elements. The paper On triples in arithmetic progression proves more: the set cannot contain more than n * 228 * (log log n / log n)1/2 elements. So you could check if that bound is achieved and if not, naively check pairs. This is O(n2 * log log n / log n) algorithm, faster than O(n2). Unfortunately "On triples..." is on Springer - but the first page is available, and Ben Green's exposition is available here, page 28, theorem 24.

By the way, the papers are from 1999 - the same year as the first one I mentioned, so that's probably why the first one doesn't mention that result.

sdcvvc
ShreevatsaR
Er, what exactly is the "Cantor-like" binary sequence that contains n^(log_3 2) 1s in it and no three evenly spaced 1s?
ShreevatsaR
Example: 101000101000000000101000101. Its length is 3^n, and has 2^n ones (so n^0.63 density). If you write down the places of 1's in binary, it will be {0,2,20,22,200,202,220,222}. Another possible way to think of it is take a sequence of ones, and continuously remove "middle" ones as in normal Cantor set construction: 111111111 -> 111000111 -> 101000101. The reason why it doesn't contain arithmetic progression is: if x, y, z formed one, then y=(x+z)/2 and x and z differ on some expansion place. Take the most significant one. Say x has 0 and z has 2. Then y must have 1 there. contradiction.
sdcvvc
Again, great research! I followed up on the 2008 3SUM paper, and it referred to CLRS Exercise. 30.1-7, after looking at which I got the answer — the O(n log n) algorithm is actually quite simple! (Just squaring a polynomial/generatingfunction.) I've posted the answer below. (Now kicking myself for not having thought of it earlier... simple solutions always elicit that reaction :p)
ShreevatsaR
So, the answer to his exam question was something like, "This problem is reducible to the 3-SUM hard problem, and 3-SUM hard has no sub-quadratic solution, so this problem cannot be solved in O(n logn)." Yes?
hughdbrown
@hughdbrown: No, the problem *can* be solved easily in O(n log n), because the numbers are in [-u, u] where u is n. The solution is a convolution using FFT as this answer says; it's also explained in more detail in my answer below. The Ω(n^2) lower-bound is only for the more general problem of finding 3-term APs in an *arbitrary* sequence of n numbers, here the n numbers are all in [1,n].
ShreevatsaR
Damn, nice answer. Nice research. I was looking at all the string matching algorithms I had ever seen but this is totally neato.
wheaties
Ahh thanks sdcvvc, I think you just showed us the worth of sitting down and seeing if anybody has tried to solve a problem if that problem is taking you a long time to solve.
ldog
A: 

(removed, invalid theoretical argument)

Loadmaster
+1  A: 

Ok, I'm going to take another stab at the problem. I think I can prove a O(n log(n)) algorithm that is similar to those already discussed by using a balanced binary tree to store distances between 1's. This approach was inspired by Justice's observation about reducing the problem to a list of distances between the 1's.

Could we scan the input string to construct a balanced binary tree around the position of 1's such that each node stores the position of the 1 and each edge is labeled with the distance to the adjacent 1 for each child node. For example:

10010001 gives the following tree

      3
     / \
  2 /   \ 3
   /     \
  0       7

This can be done in O(n log(n)) since, for a string of size n, each insertion takes O(log(n)) in the worst case.

Then the problem is to search the tree to discover whether, at any node, there is a path from that node through the left-child that has the same distance as a path through the right child. This can be done recursively on each subtree. When merging two subtrees in the search, we must compare the distances from paths in the left subtree with distances from paths in the right. Since the number of paths in a subtree will be proportional to log(n), and the number of nodes is n, I believe this can be done in O(n log(n)) time.

Did I miss anything?

jbourque
"Since the number of paths in a subtree will be proportional to log(n)" Why not n? Generally this is a promising approach.
sdcvvc
@sdcwc: It's proportional to log(n) and not n because in a balanced tree each subtree has half the nodes, and the number of paths to the root of the subtree is the same as the number of nodes in the subtree (excluding the root).
jbourque
+3  A: 

Revision: 2009-10-17 23:00

I've run this on large numbers (like, strings of 20 million) and I now believe this algorithm is not O(n logn). Notwithstanding that, it's a cool enough implementation and contains a number of optimizations that makes it run really fast. It evaluates all the arrangements of binary strings 24 or fewer digits in under 25 seconds.

I've updated the code to include the 0 <= L < M < U <= X-1 observation from earlier today.


Original

This is, in concept, similar to another question I answered. That code also looked at three values in a series and determined if a triplet satisfied a condition. Here is C# code adapted from that:

using System;
using System.Collections.Generic;

namespace StackOverflow1560523
{
    class Program
    {
        public struct Pair<T>
        {
            public T Low, High;
        }
        static bool FindCandidate(int candidate, 
            List<int> arr, 
            List<int> pool, 
            Pair<int> pair, 
            ref int iterations)
        {
            int lower = pair.Low, upper = pair.High;
            while ((lower >= 0) && (upper < pool.Count))
            {
                int lowRange = candidate - arr[pool[lower]];
                int highRange = arr[pool[upper]] - candidate;
                iterations++;
                if (lowRange < highRange)
                    lower -= 1;
                else if (lowRange > highRange)
                    upper += 1;
                else
                    return true;
            }
            return false;
        }
        static List<int> BuildOnesArray(string s)
        {
            List<int> arr = new List<int>();
            for (int i = 0; i < s.Length; i++)
                if (s[i] == '1')
                    arr.Add(i);
            return arr;
        }
        static void BuildIndexes(List<int> arr, 
            ref List<int> even, ref List<int> odd, 
            ref List<Pair<int>> evenIndex, ref List<Pair<int>> oddIndex)
        {
            for (int i = 0; i < arr.Count; i++)
            {
                bool isEven = (arr[i] & 1) == 0;
                if (isEven)
                {
                    evenIndex.Add(new Pair<int> {Low=even.Count-1, High=even.Count+1});
                    oddIndex.Add(new Pair<int> {Low=odd.Count-1, High=odd.Count});
                    even.Add(i);
                }
                else
                {
                    oddIndex.Add(new Pair<int> {Low=odd.Count-1, High=odd.Count+1});
                    evenIndex.Add(new Pair<int> {Low=even.Count-1, High=even.Count});
                    odd.Add(i);
                }
            }
        }

        static int FindSpacedOnes(string s)
        {
            // List of indexes of 1s in the string
            List<int> arr = BuildOnesArray(s);
            //if (s.Length < 3)
            //    return 0;

            //  List of indexes to odd indexes in arr
            List<int> odd = new List<int>(), even = new List<int>();

            //  evenIndex has indexes into arr to bracket even numbers
            //  oddIndex has indexes into arr to bracket odd numbers
            List<Pair<int>> evenIndex = new List<Pair<int>>(), 
                oddIndex = new List<Pair<int>>(); 
            BuildIndexes(arr, 
                ref even, ref odd, 
                ref evenIndex, ref oddIndex);

            int iterations = 0;
            for (int i = 1; i < arr.Count-1; i++)
            {
                int target = arr[i];
                bool found = FindCandidate(target, arr, odd, oddIndex[i], ref iterations) || 
                    FindCandidate(target, arr, even, evenIndex[i], ref iterations);
                if (found)
                    return iterations;
            }
            return iterations;
        }
        static IEnumerable<string> PowerSet(int n)
        {
            for (long i = (1L << (n-1)); i < (1L << n); i++)
            {
                yield return Convert.ToString(i, 2).PadLeft(n, '0');
            }
        }
        static void Main(string[] args)
        {
            for (int i = 5; i < 64; i++)
            {
                int c = 0;
                string hardest_string = "";
                foreach (string s in PowerSet(i))
                {
                    int cost = find_spaced_ones(s);
                    if (cost > c)
                    {
                        hardest_string = s;
                        c = cost;
                        Console.Write("{0} {1} {2}\r", i, c, hardest_string);
                    }
                }
                Console.WriteLine("{0} {1} {2}", i, c, hardest_string);
            }
        }
    }
}

The principal differences are:

  1. Exhaustive search of solutions
    This code generates a power set of data to find the hardest input to solve for this algorithm.
  2. All solutions versus hardest to solve
    The code for the previous question generated all the solutions using a python generator. This code just displays the hardest for each pattern length.
  3. Scoring algorithm
    This code checks the distance from the middle element to its left- and right-hand edge. The python code tested whether a sum was above or below 0.
  4. Convergence on a candidate
    The current code works from the middle towards the edge to find a candidate. The code in the previous problem worked from the edges towards the middle. This last change gives a large performance improvement.
  5. Use of even and odd pools
    Based on the observations at the end of this write-up, the code searches pairs of even numbers of pairs of odd numbers to find L and U, keeping M fixed. This reduces the number of searches by pre-computing information. Accordingly, the code uses two levels of indirection in the main loop of FindCandidate and requires two calls to FindCandidate for each middle element: once for even numbers and once for odd ones.

The general idea is to work on indexes, not the raw representation of the data. Calculating an array where the 1's appear allows the algorithm to run in time proportional to the number of 1's in the data rather than in time proportional to the length of the data. This is a standard transformation: create a data structure that allows faster operation while keeping the problem equivalent.

The results are out of date: removed.


Edit: 2009-10-16 18:48

On yx's data, which is given some credence in the other responses as representative of hard data to calculate on, I get these results... I removed these. They are out of date.

I would point out that this data is not the hardest for my algorithm, so I think the assumption that yx's fractals are the hardest to solve is mistaken. The worst case for a particular algorithm, I expect, will depend upon the algorithm itself and will not likely be consistent across different algorithms.


Edit: 2009-10-17 13:30

Further observations on this.

First, convert the string of 0's and 1's into an array of indexes for each position of the 1's. Say the length of that array A is X. Then the goal is to find

0 <= L < M < U <= X-1

such that

A[M] - A[L] = A[U] - A[M]

or

2*A[M] = A[L] + A[U]

Since A[L] and A[U] sum to an even number, they can't be (even, odd) or (odd, even). The search for a match could be improved by splitting A[] into odd and even pools and searching for matches on A[M] in the pools of odd and even candidates in turn.

However, this is more of a performance optimization than an algorithmic improvement, I think. The number of comparisons should drop, but the order of the algorithm should be the same.


Edit 2009-10-18 00:45

Yet another optimization occurs to me, in the same vein as separating the candidates into even and odd. Since the three indexes have to add to a multiple of 3 (a, a+x, a+2x -- mod 3 is 0, regardless of a and x), you can separate L, M, and U into their mod 3 values:

M  L  U
0  0  0
   1  2
   2  1
1  0  2
   1  1
   2  0
2  0  1
   1  0
   2  2

In fact, you could combine this with the even/odd observation and separate them into their mod 6 values:

M  L  U
0  0  0
   1  5
   2  4
   3  3
   4  2
   5  1

and so on. This would provide a further performance optimization but not an algorithmic speedup.

hughdbrown
A: 

I thought I'd add one comment before posting the 22nd naive solution to the problem. For the naive solution, we don't need to show that the number of 1's in the string is at most O(log(n)), but rather that it is at most O(sqrt(n*log(n)).

Solver:

def solve(Str):
 indexes=[]
 #O(n) setup
 for i in range(len(Str)):
  if Str[i]=='1':
   indexes.append(i)

 #O((number of 1's)^2) processing
 for i in range(len(indexes)):
  for j in range(i+1, len(indexes)):
                            indexDiff = indexes[j] - indexes[i]
   k=indexes[j] + indexDiff
   if k<len(Str) and Str[k]=='1':
    return True
 return False

It's basically a fair bit similar to flybywire's idea and implementation, though looking ahead instead of back.

Greedy String Builder:

#assumes final char hasn't been added, and would be a 1 
def lastCharMakesSolvable(Str):
 endIndex=len(Str)
 j=endIndex-1
 while j-(endIndex-j) >= 0:
  k=j-(endIndex-j)
  if k >= 0 and Str[k]=='1' and Str[j]=='1':
   return True
  j=j-1
 return False



def expandString(StartString=''):
 if lastCharMakesSolvable(StartString):
  return StartString + '0'
 return StartString + '1'

n=1
BaseStr=""
lastCount=0
while n<1000000:
 BaseStr=expandString(BaseStr)
 count=BaseStr.count('1')
 if count != lastCount:
  print(len(BaseStr), count)
 lastCount=count
 n=n+1

(In my defense, I'm still in the 'learn python' stage of understanding)

Also, potentially useful output from the greedy building of strings, there's a rather consistent jump after hitting a power of 2 in the number of 1's... which I was not willing to wait around to witness hitting 2096.

strlength   # of 1's
    1    1
    2    2
    4    3
    5    4
   10    5
   14    8
   28    9
   41    16
   82    17
  122    32
  244    33
  365    64
  730    65
 1094    128
 2188    129
 3281    256
 6562    257
 9842    512
19684    513
29525    1024
CoderTao
A: 

I'll try to present a mathematical approach. This is more a beginning than an end, so any help, comment, or even contradiction - will be deeply appreciated. However, if this approach is proven - the algorithm is a straight-forward search in the string.

  1. Given a fixed number of spaces k and a string S, the search for a k-spaced-triplet takes O(n) - We simply test for every 0<=i<=(n-2k) if S[i]==S[i+k]==S[i+2k]. The test takes O(1) and we do it n-k times where k is a constant, so it takes O(n-k)=O(n).

  2. Let us assume that there is an Inverse Proportion between the number of 1's and the maximum spaces we need to search for. That is, If there are many 1's, there must be a triplet and it must be quite dense; If there are only few 1's, The triplet (if any) can be quite sparse. In other words, I can prove that if I have enough 1's, such triplet must exist - and the more 1's I have, a more dense triplet must be found. This can be explained by the Pigeonhole principle - Hope to elaborate on this later.

  3. Say have an upper bound k on the possible number of spaces I have to look for. Now, for each 1 located in S[i] we need to check for 1 in S[i-1] and S[i+1], S[i-2] and S[i+2], ... S[i-k] and S[i+k]. This takes O((k^2-k)/2)=O(k^2) for each 1 in S - due to Gauss' Series Summation Formula. Note that this differs from section 1 - I'm having k as an upper bound for the number of spaces, not as a constant space.

We need to prove O(n*log(n)). That is, we need to show that k*(number of 1's) is proportional to log(n).

If we can do that, the algorithm is trivial - for each 1 in S whose index is i, simply look for 1's from each side up to distance k. If two were found in the same distance, return i and k. Again, the tricky part would be finding k and proving the correctness.

I would really appreciate your comments here - I have been trying to find the relation between k and the number of 1's on my whiteboard, so far without success.

Adam Matan
A: 

Below is a solution. There could be some little mistakes here and there, but the idea is sound.

Edit: It's not n * log(n)

PSEUDO CODE:

foreach character in the string
  if the character equals 1 {         
     if length cache > 0 { //we can skip the first one
        foreach location in the cache { //last in first out kind of order
           if ((currentlocation + (currentlocation - location)) < length string)
              if (string[(currentlocation + (currentlocation - location))] equals 1)
                 return found evenly spaced string
           else
              break;
        }
     }
     remember the location of this character in a some sort of cache.
  }

return didn't find evenly spaced string

C# code:

public static Boolean FindThreeEvenlySpacedOnes(String str) {
    List<int> cache = new List<int>();

    for (var x = 0; x < str.Length; x++) {
        if (str[x] == '1') {
            if (cache.Count > 0) {
                for (var i = cache.Count - 1; i > 0; i--) {
                    if ((x + (x - cache[i])) >= str.Length)
                        break;

                    if (str[(x + (x - cache[i]))] == '1')
                        return true;                            
                }
            }
            cache.Add(x);                    
        }
    }

    return false;
}

How it works:

iteration 1:
x
|
101101001
// the location of this 1 is stored in the cache

iteration 2:
 x
 | 
101101001

iteration 3:
a x b 
| | | 
101101001
//we retrieve location a out of the cache and then based on a 
//we calculate b and check if te string contains a 1 on location b

//and of course we store x in the cache because it's a 1

iteration 4:
  axb  
  |||  
101101001

a  x  b  
|  |  |  
101101001


iteration 5:
    x  
    |  
101101001

iteration 6:
   a x b 
   | | | 
101101001

  a  x  b 
  |  |  | 
101101001
//return found evenly spaced string
Niek H.
Your algorithm works, but you need to prove that it is less than O(n^2). The trivial analysis gets you to O(n^2). For each 1, you go over all of the 1s that were before it. Making the complexity function be 1+2+3+...+(k/2-1)=O(k^2) [where k is the number of 1s].
Anna
I checked and indeed the worst case scenario with no solution is larger then O(n * log(n))
Niek H.
A: 

How about a simple O(n) solution, with O(n^2) space? (Uses the assumption that all bitwise operators work in O(1).)

The algorithm basically works in four stages:

Stage 1: For each bit in your original number, find out how far away the ones are, but consider only one direction. (I considered all the bits in the direction of the least significant bit.)

Stage 2: Reverse the order of the bits in the input;

Stage 3: Re-run step 1 on the reversed input.

Stage 4: Compare the results from Stage 1 and Stage 3. If any bits are equally spaced above AND below we must have a hit.

Keep in mind that no step in the above algorithm takes longer than O(n). ^_^

As an added benefit, this algorithm will find ALL equally spaced ones from EVERY number. So for example if you get a result of "0x0005" then there are equally spaced ones at BOTH 1 and 3 units away

I didn't really try optimizing the code below, but it is compilable C# code that seems to work.

using System;

namespace ThreeNumbers
{
 class Program
 {
  const int uint32Length = 32;

  static void Main(string[] args)
  {
   Console.Write("Please enter your integer: ");
   uint input = UInt32.Parse(Console.ReadLine());

   uint[] distancesLower = Distances(input);
   uint[] distancesHigher = Distances(Reverse(input));

   PrintHits(input, distancesLower, distancesHigher);
  }

  /// <summary>
  /// Returns an array showing how far the ones away from each bit in the input.  Only 
  /// considers ones at lower signifcant bits.  Index 0 represents the least significant bit 
  /// in the input.  Index 1 represents the second least significant bit in the input and so 
  /// on.  If a one is 3 away from the bit in question, then the third least significant bit 
  /// of the value will be sit.
  /// 
  /// As programed this algorithm needs: O(n) time, and O(n*log(n)) space.  
  /// (Where n is the number of bits in the input.)
  /// </summary>
  public static uint[] Distances(uint input)
  {
   uint[] distanceToOnes = new uint[uint32Length];
   uint result = 0;

   //Sets how far each bit is from other ones. Going in the direction of LSB to MSB
   for (uint bitIndex = 1, arrayIndex = 0; bitIndex != 0; bitIndex <<= 1, ++arrayIndex)
   {
    distanceToOnes[arrayIndex] = result;
    result <<= 1;

    if ((input & bitIndex) != 0)
    {
     result |= 1;
    }
   }

   return distanceToOnes;
  }

  /// <summary>
  /// Reverses the bits in the input.
  /// 
  /// As programmed this algorithm needs O(n) time and O(n) space.  
  /// (Where n is the number of bits in the input.)
  /// </summary>
  /// <param name="input"></param>
  /// <returns></returns>
  public static uint Reverse(uint input)
  {
   uint reversedInput = 0;
   for (uint bitIndex = 1; bitIndex != 0; bitIndex <<= 1)
   {
    reversedInput <<= 1;
    reversedInput |= (uint)((input & bitIndex) != 0 ? 1 : 0);
   }

   return reversedInput;
  }

  /// <summary>
  /// Goes through each bit in the input, to check if there are any bits equally far away in 
  /// the distancesLower and distancesHigher
  /// </summary>
  public static void PrintHits(uint input, uint[] distancesLower, uint[] distancesHigher)
  {
   const int offset = uint32Length - 1;

   for (uint bitIndex = 1, arrayIndex = 0; bitIndex != 0; bitIndex <<= 1, ++arrayIndex)
   {
    //hits checks if any bits are equally spaced away from our current value
    bool isBitSet = (input & bitIndex) != 0;
    uint hits = distancesLower[arrayIndex] & distancesHigher[offset - arrayIndex];

    if (isBitSet && (hits != 0))
    {
     Console.WriteLine(String.Format("The {0}-th LSB has hits 0x{1:x4} away", arrayIndex + 1, hits));
    }
   }
  }
 }
}

Someone will probably comment that for any sufficiently large number, bitwise operations cannot be done in O(1). You'd be right. However, I'd conjecture that every solution that uses addition, subtraction, multiplication, or division (which cannot be done by shifting) would also have that problem.

Rob Rolnick
A: 

Obviously we need to at least check bunches of triplets at the same time, so we need to compress the checks somehow. I have a candidate algorithm, but analyzing the time complexity is beyond my ability*time threshold.

Build a tree where each node has three children and each node contains the total number of 1's at its leaves. Build a linked list over the 1's, as well. Assign each node an allowed cost proportional to the range it covers. As long as the time we spend at each node is within budget, we'll have an O(n lg n) algorithm.

--

Start at the root. If the square of the total number of 1's below it is less than its allowed cost, apply the naive algorithm. Otherwise recurse on its children.

Now we have either returned within budget, or we know that there are no valid triplets entirely contained within one of the children. Therefore we must check the inter-node triplets.

Now things get incredibly messy. We essentially want to recurse on the potential sets of children while limiting the range. As soon as the range is constrained enough that the naive algorithm will run under budget, you do it. Enjoy implementing this, because I guarantee it will be tedious. There's like a dozen cases.

--

The reason I think that algorithm will work is because the sequences without valid triplets appear to go alternate between bunches of 1's and lots of 0's. It effectively splits the nearby search space, and the tree emulates that splitting.

The run time of the algorithm is not obvious, at all. It relies on the non-trivial properties of the sequence. If the 1's are really sparse then the naive algorithm will work under budget. If the 1's are dense, then a match should be found right away. But if the density is 'just right' (eg. near ~n^0.63, which you can achieve by setting all bits at positions with no '2' digit in base 3), I don't know if it will work. You would have to prove that the splitting effect is strong enough.

Strilanc
A: 

No theoretical answer here, but I wrote a quick Java program to explore the running-time behavior as a function of k and n, where n is the total bit length and k is the number of 1's. I'm with a few of the answerers who are saying that the "regular" algorithm that checks all the pairs of bit positions and looks for the 3rd bit, even though it would require O(k^2) in the worst case, in reality because the worst-case needs sparse bitstrings, is O(n ln n).

Anyway here's the program, below. It's a Monte-Carlo style program which runs a large number of trials NTRIALS for constant n, and randomly generates bitsets for a range of k-values using Bernoulli processes with ones-density constrained between limits that can be specified, and records the running time of finding or failing to find a triplet of evenly spaced ones, time measured in steps NOT in CPU time. I ran it for n=64, 256, 1024, 4096, 16384* (still running), first a test run with 500000 trials to see which k-values take the longest running time, then another test with 5000000 trials with narrowed ones-density focus to see what those values look like. The longest running times do happen with very sparse density (e.g. for n=4096 the running time peaks are in the k=16-64 range, with a gentle peak for mean runtime at 4212 steps @ k=31, max runtime peaked at 5101 steps @ k=58). It looks like it would take extremely large values of N for the worst-case O(k^2) step to become larger than the O(n) step where you scan the bitstring to find the 1's position indices.

package com.example.math;

import java.io.PrintStream;
import java.util.BitSet;
import java.util.Random;

public class EvenlySpacedOnesTest {
    static public class StatisticalSummary
    {
     private int n=0;
     private double min=Double.POSITIVE_INFINITY;
     private double max=Double.NEGATIVE_INFINITY;
     private double mean=0;
     private double S=0;

     public StatisticalSummary() {}
     public void add(double x) {
      min = Math.min(min, x);
      max = Math.max(max, x);
      ++n;
      double newMean = mean + (x-mean)/n;
      S += (x-newMean)*(x-mean);
      // this algorithm for mean,std dev based on Knuth TAOCP vol 2
      mean = newMean;
     }
     public double getMax() { return (n>0)?max:Double.NaN; }
     public double getMin() { return (n>0)?min:Double.NaN; }
     public int getCount() { return n; }
     public double getMean() { return (n>0)?mean:Double.NaN; }
     public double getStdDev() { return (n>0)?Math.sqrt(S/n):Double.NaN; } 
     // some may quibble and use n-1 for sample std dev vs population std dev 
     public static void printOut(PrintStream ps, StatisticalSummary[] statistics) {
      for (int i = 0; i < statistics.length; ++i)
      {
       StatisticalSummary summary = statistics[i];
       ps.printf("%d\t%d\t%.0f\t%.0f\t%.5f\t%.5f\n",
         i,
         summary.getCount(),
         summary.getMin(),
         summary.getMax(),
         summary.getMean(),
         summary.getStdDev());
      }
     }
    }

    public interface RandomBernoulliProcess // see http://en.wikipedia.org/wiki/Bernoulli_process
    {
     public void setProbability(double d);
     public boolean getNextBoolean();
    }

    static public class Bernoulli implements RandomBernoulliProcess
    {
     final private Random r = new Random();
     private double p = 0.5;
     public boolean getNextBoolean() { return r.nextDouble() < p; }
     public void setProbability(double d) { p = d; }
    } 
    static public class TestResult {
     final public int k;
     final public int nsteps;
     public TestResult(int k, int nsteps) { this.k=k; this.nsteps=nsteps; } 
    }

    ////////////
    final private int n;
    final private int ntrials;
    final private double pmin;
    final private double pmax;
    final private Random random = new Random();
    final private Bernoulli bernoulli = new Bernoulli();
    final private BitSet bits;
    public EvenlySpacedOnesTest(int n, int ntrials, double pmin, double pmax) {
     this.n=n; this.ntrials=ntrials; this.pmin=pmin; this.pmax=pmax;
     this.bits = new BitSet(n);
    }

    /*
     * generate random bit string
     */
    private int generateBits()
    {
     int k = 0; // # of 1's
     for (int i = 0; i < n; ++i)
     {
      boolean b = bernoulli.getNextBoolean();
      this.bits.set(i, b);
      if (b) ++k;
     }
     return k;
    }

    private int findEvenlySpacedOnes(int k, int[] pos) 
    {
     int[] bitPosition = new int[k];
     for (int i = 0, j = 0; i < n; ++i)
     {
      if (this.bits.get(i))
      {
       bitPosition[j++] = i;
      }
     }
     int nsteps = n; // first, it takes N operations to find the bit positions.
     boolean found = false;
     if (k >= 3) // don't bother doing anything if there are less than 3 ones. :(
     {  
      int lastBitSetPosition = bitPosition[k-1];
      for (int j1 = 0; !found && j1 < k; ++j1)
      {
       pos[0] = bitPosition[j1];
       for (int j2 = j1+1; !found && j2 < k; ++j2)
       {
        pos[1] = bitPosition[j2];

        ++nsteps;
        pos[2] = 2*pos[1]-pos[0];
        // calculate 3rd bit index that might be set;
        // the other two indices point to bits that are set
        if (pos[2] > lastBitSetPosition)
         break;
        // loop inner loop until we go out of bounds

        found = this.bits.get(pos[2]);
        // we're done if we find a third 1!
       }
      }
     }
     if (!found)
      pos[0]=-1;
     return nsteps;
    }

    /*
     * run an algorithm that finds evenly spaced ones and returns # of steps.
     */
    public TestResult run()
    {
     bernoulli.setProbability(pmin + (pmax-pmin)*random.nextDouble());
     // probability of bernoulli process is randomly distributed between pmin and pmax

     // generate bit string.
     int k = generateBits();
     int[] pos = new int[3];
     int nsteps = findEvenlySpacedOnes(k, pos);
     return new TestResult(k, nsteps); 
    }

    public static void main(String[] args)
    {
     int n;
     int ntrials;
     double pmin = 0, pmax = 1;
     try {
      n = Integer.parseInt(args[0]);
      ntrials = Integer.parseInt(args[1]);
      if (args.length >= 3)
       pmin = Double.parseDouble(args[2]);
      if (args.length >= 4)
       pmax = Double.parseDouble(args[3]);
     }
     catch (Exception e)
     {
      System.out.println("usage: EvenlySpacedOnesTest N NTRIALS [pmin [pmax]]");
      System.exit(0);
      return; // make the compiler happy
     }

     final StatisticalSummary[] statistics;
     statistics=new StatisticalSummary[n+1];
     for (int i = 0; i <= n; ++i)
     {
      statistics[i] = new StatisticalSummary();
     }

     EvenlySpacedOnesTest test = new EvenlySpacedOnesTest(n, ntrials, pmin, pmax);
     int printInterval=100000;
     int nextPrint = printInterval;
     for (int i = 0; i < ntrials; ++i)
     {
      TestResult result = test.run();
      statistics[result.k].add(result.nsteps);
      if (i == nextPrint)
      {
       System.err.println(i);
       nextPrint += printInterval;
      }
     }
     StatisticalSummary.printOut(System.out, statistics);
    }
}
Jason S
+61  A: 

Finally! Following up leads in sdcvvc's answer, we have it: the O(n log n) algorithm for the problem! It is simple too, after you understand it. Those who guessed FFT were right.

The problem: we are given a binary string S of length n, and we want to find three evenly spaced 1s in it. For example, S may be 110110010, where n=9. It has evenly spaced 1s at positions 2, 5, and 8.

  1. Scan S left to right, and make a list L of positions of 1. For the S=110110010 above, we have the list L = [1, 2, 4, 5, 8]. This step is O(n). The problem is now to find an arithmetic progression of length 3 in L, i.e. to find distinct a, b, c in L such that b-a = c-b, or equivalently a+c=2b. For the example above, we want to find the progression (2, 5, 8).

  2. Make a polynomial p with terms xk for each k in L. For the example above, we make the polynomial p(x) = (x + x2 + x4 + x5+x8). This step is O(n).

  3. Find the polynomial q = p2, using the Fast Fourier Transform. For the example above, we get the polynomial q(x) = x16 + 2x13 + 2x12 + 3x10 + 4x9 + x8 + 2x7 + 4x6 + 2x5 + x4 + 2x3 + x2. This step is O(n log n).

  4. Ignore all terms except those corresponding to x2k for some k in L. For the example above, we get the terms x16, 3x10, x8, x4, x2. This step is O(n), if you choose to do it at all.

Here's the crucial point: the coefficient of any x2b for b in L is precisely the number of pairs (a,c) in L such that a+c=2b. [CLRS, Ex. 30.1-7] One such pair is (b,b) always (so the coefficient is at least 1), but if there exists any other pair (a,c), then the coefficient is at least 3, from (a,c) and (c,a). For the example above, we have the coefficient of x10 to be 3 precisely because of the AP (2,5,8). (These coefficients x2b will always be odd numbers, for the reasons above. And all other coefficients in q will always be even.)

So then, the algorithm is to look at the coefficients of these terms x2b, and see if any of them is greater than 1. If there is none, then there are no evenly spaced 1s. If there is a b in L for which the coefficient of x2b is greater than 1, then we know that there is some pair (a,c) — other than (b,b) — for which a+c=2b. To find the actual pair, we simply try each a in L (the corresponding c would be 2b-a) and see if there is a 1 at position 2b-a in S. This step is O(n).

That's all, folks.


One might ask: do we need to use FFT? Many answers, such as beta's, flybywire's, and rsp's, suggest that the approach that checks each pair of 1s and sees if there is a 1 at the "third" position, might work in O(n log n), based on the intuition that if there are too many 1s, we would find a triple easily, and if there are too few 1s, checking all pairs takes little time. Unfortunately, while this intuition is correct and the simple approach is better than O(n2), it is not significantly better. As in sdcvvc's answer, we can take the "Cantor-like set" of strings of length n=3k, with 1s at the positions whose ternary representation has only 0s and 2s (no 1s) in it. Such a string has 2k = n(log 2)/(log 3) ≈ n0.63 ones in it and no evenly spaced 1s, so checking all pairs would be of the order of the square of the number of 1s in it: that's 4k ≈ n1.26 which unfortunately is asymptotically much larger than (n log n). In fact, the worst case is even worse: Leo Moser in 1953 constructed (effectively) such strings which have n1-c/√(log n) 1s in them but no evenly spaced 1s, which means that on such strings, the simple approach would take Θ(n2-2c/√(log n)) — only a tiny bit better than Θ(n2), surprisingly!


About the maximum number of 1s in a string of length n with no 3 evenly spaced ones (which we saw above was at least n0.63 from the easy Cantor-like construction, and at least n1-c/√(log n) with Moser's construction) — this is OEIS A003002. It can also be calculated directly from OEIS A065825 as the k such that A065825(k) ≤ n < A065825(k+1). I wrote a program to find these, and it turns out that the greedy algorithm does not give the longest such string. For example, for n=9, we can get 5 1s (110100011) but the greedy gives only 4 (110110000), for n=26 we can get 11 1s (11001010001000010110001101) but the greedy gives only 8 (11011000011011000000000000), and for n=74 we can get 22 1s (11000010110001000001011010001000000000000000010001011010000010001101000011) but the greedy gives only 16 (11011000011011000000000000011011000011011000000000000000000000000000000000). They do agree at quite a few places until 50 (e.g. all of 38 to 50), though. As the OEIS references say, it seems that Jaroslaw Wroblewski is interested in this question, and he maintains a website on these non-averaging sets. The exact numbers are known only up to 194.

ShreevatsaR
Very nice. Impressive. It seems a bit much to expect someone to come up with this in a test.
hughdbrown
Well, Step 1, translating the problem to finding an AP, is straightforward. Step 3, that polynomials can be multiplied in O(n log n) time, is just a fact. The real trick, and what makes the problem hard, is the idea of thinking of 11011 as the polynomial with coefficients [1,1,0,1,1], etc. This is a clever and often useful idea, which goes all the way back to Euler. [See Wilf's awesome book "generatingfunctionology" for a modern exposition: http://www.math.upenn.edu/~wilf/DownldGF.html ] So it depends on whether the students were exposed to generating functions in recent memory or not. :-)
ShreevatsaR
Actually, strictly speaking, generating functions / polynomials are not even needed. Someone familiar with the engineering side of Fourier transforms might be able to see it directly, without using polynomials (you're just convolving S with itself). I just used polynomials because this approach is more transparent to me. :-)
ShreevatsaR
Out of interest you can do strings where there are less than ten 1's on a calculator. Simply type the number in and square it. For example 110110010^2=12102202520220121. We note the odd number 5 in position 8 (count from the right, starting at zero). This tells you that in position 4 (i.e. 8/2), there is the middle of a triple.
Jonathan Swift
Sorry got my calculation completely wrong. It should be 110110010^2=12124214302200100. But the idea stands. Just note the position of the 3.
Jonathan Swift
Very impressive. It is really cool to see this thread/question come together and find a solution. I was starting to think it wasn't possible. Also, this professor is evil.
KingNestor
Wow, you're a genius! Could you clarify that last step, beginning with "If there is an x^(2b) that is 3 or more...?" I was struggling to keep up, but that's where you finally lost me.
StriplingWarrior
@Jonathon: Indeed. Observe that the digits (12124214302200100) are the same as the coefficients of the polynomial (backwards). Polynomial multiplication is like integer multiplication except there is no "carry", and as you said, when there are 10 digits or fewer, there can be no carry so the results are identical. <br/>@Stripling: Sorry it wasn't clear enough. If, for some b in L, the coefficient of x^(2b) is greater than 1, then we know that there is some pair (a,c) — other than (b,b) — such that a+c=2b. So we try each a (corresponding c has to be 2b-a) and check if S has a 1 at position c.
ShreevatsaR
The only thing the algorithm doesn't tell you is the spacing between the 1's. But I guess this can be got in O(n) time, starting from the centre 1 given by the algorithm?
Jonathan Swift
First you find the middle 1 (b) and then you find (a,c) in O(n) time. Once you know the actual positions (a,b,c), you also know the spacing: it is b-a [= c-b]. BTW, note that this only finds *one* triple of evenly spaced 1s (or, say, all triples with *one* fixed middle 1) — to find all triples might take O(n^2) (e.g. consider S=111111....).
ShreevatsaR
Very cool. It's disappointing that this is CW and you can't get any rep for it though. :-(
Kip
Hmm, is it really O(nlogn)? The last step checks all terms of even order 2b, and for each such term checks all terms of lesser order, until it finds a match. Sounds O(n^2) to me...
Paggas
Aha, disregard my previous comment, last step is O(n) + O(n), rather than O(n) * O(n), since we just find one term of order 2b with coefficient >1 (O(n)) and then we find a second one of order c such that there is a term of order a = 2b - c (O(n))!
Paggas
How can performing q = p^2 be O(n log(n)), when q could have O(n^2) terms? Just writing out the polynomial would take O(n^2).
RexE
@RexE: If p is of degree n-1 (has n terms), q=p^2 is of degree 2n-2 (has at most 2n-1 terms). How did you get n^2? (Also, multiplying two polynomials of degree n in O(n log n) time using the FFT is a pretty standard operation; please click on the link in the answer or see the [Wikipedia article](http://en.wikipedia.org/wiki/Fast_Fourier_transform).)
ShreevatsaR
Ah yes, I was wrong. Thanks.
RexE
A: 
# <algorithm>
def contains_evenly_spaced?(input)
  return false if input.size < 3
  one_indices = []
  input.each_with_index do |digit, index|
    next if digit == 0
    one_indices << index
  end
  return false if one_indices.size < 3
  previous_indexes = []
  one_indices.each do |index|
    if !previous_indexes.empty?
      previous_indexes.each do |previous_index|
        multiple = index - previous_index
        success_index = index + multiple
        return true if input[success_index] == 1
      end
    end
    previous_indexes << index
  end
  return false
end
# </algorithm>

def parse_input(input)
  input.chars.map { |c| c.to_i }
end

I'm having trouble with the worst-case scenarios with millions of digits. Fuzzing from /dev/urandom essentially gives you O(n), but I know the worst case is worse than that. I just can't tell how much worse. For small n, it's trivial to find inputs at around 3*n*log(n), but it's surprisingly hard to differentiate those from some other order of growth for this particular problem.

Can anyone who was working on worst-case inputs generate a string with length greater than say, one hundred thousand?

Bob Aman
As I pointed out in my answer, it's easy to generate bad (though not worst-case) strings of any number of digits: put 1s at exactly those positions p which do not contain any "1"s in their ternary representation (i.e at positions 2, 6, 8, 18, 20, 24, 26, 54, 56, 60... : see formulae at research.att.com/~njas/sequences/… ). For 3^13 ≈ 1 million, this has 2^13 ≈ 8000 1s. The running time on such strings will be ≈ n^(1.26) — which might still be hard to distinguish from O(n log n) for such small n. Try it and see.
ShreevatsaR