Find the 'pits' in a list of integers. Fast

Question

I'm attempting to write a program which finds the 'pits' in a list of integers.

A pit is any integer x where x is less than or equal to the integers immediately preceding and following it. If the integer is at the start or end of the list it is only compared on the inward side.

For example in: 
    [2,1,3] 1 is a pit.
    [1,1,1] all elements are pits.
    [4,3,4,3,4] the elements at 1 and 3 are pits.

I know how to work this out by taking a linear approach and walking along the list however i am curious about how to apply divide and conquer
techniques to do this comparatively quickly. I am quite inexperienced and am not really sure where to start, i feel like something similar to a binary tree could be applied?

If its pertinent i'm working in Python 3. Thanks for your time :).

Is there a reason that you expect divide and conquer to be fast? Linear is provably the best you can do if you are trying to identify all the pits since you necessarily must examine every item in the list. — Jeremy West, Mar 11 '15 at 21:59
Curious about why i was down-voted? please elaborate. @JeremyWest I was told that there was a faster way of doing it. :/. I may have been misinformed. — MapReduceFilter, Mar 11 '15 at 21:59
You could use `divide and conquer` IF you were to find the smallest `pit`. If you want to find all the `pits` you have to do it linearly — letsc, Mar 11 '15 at 22:03
You can do some tricks to get a 'better linear' (ex: If I just found a pit, I know that by definition the next number is not a pit and I can skip an iteration), but it's still going to be linear for finding all pits. — aruisdante, Mar 11 '15 at 22:05
@aruisdante Except that, by definition, the next number may be a pit if it is equal to the current number and less than or equal to the following number... But yes, if the next number is strictly larger, you could skip ahead. — Jeremy West, Mar 11 '15 at 23:48
@MapReduceFilter Divide and conquer algorithms are usually suited to problems with a recursive structure, for example, sorting (a list is sorted if every sublist of the list is sorted). This problem doesn't (at least to me) fit that mold. Being a pit is a local problem (it depends only on the value and values near it) and you are trying to identify every pit, so you necessarily must look at all of them. Perhaps they meant a parallel algorithm? — Jeremy West, Mar 11 '15 at 23:52
@JeremyWest Parallel perhaps, although you'd have take care to deal with the fact that you might have a chunk boundary that makes you miss a pit. And you're right, I misread the definition with respect to equalities. — aruisdante, Mar 11 '15 at 23:54

score 2 · Accepted Answer · answered Mar 11 '15 at 22:25

Without any additional information on the distribution of the values in the list, it is not possible to achieve any algorithmic complexity of less than O(x), where x is the number of elements in the list.

Logically, if the dataset is random, such as a brownian noise, a pit can happen anywhere, requiring a full 1:1 sampling frequency in order to correctly find every pit.

Even if one just wants to find the absolute lowest pit in the sequence, that would not be possible to achieve in sub-linear time without repercussions on the correctness of the results.

Optimizations can be considered, such as mere parallelization or skipping values neighbor to a pit, but the overall complexity would stay the same.

Find the 'pits' in a list of integers. Fast

1 Answers1