Question

So finding the maximum element in a list takes O(n) time complexity (if the list has n elements). I tried to implement an algorithm that looks faster.

(define (clever-max lst)
  (define (odd-half a-list)
    (cond ((null? a-list) (list))
          ((null? (cdr a-list))
           (cons (car a-list) (list)))
          (else
           (cons (car a-list)
                 (odd-half (cdr (cdr a-list)))))))
  (define (even-half a-list)
    (if (null? a-list)
        (list)
        (odd-half (cdr a-list))))
  (cond ((null? lst) (error "no elements in list!"))
        ((null? (cdr lst)) (car lst))
        (else
         (let ((l1 (even-half lst))
               (l2 (odd-half lst)))
           (max (clever-max l1) (clever-max l2))))))

Is this actually faster?! What would you say the asymptotic time complexity is (tight bound)?

Answer 1

Given a list of data which you know nothing about, there is no way to find the maximum element without examining each element and thus taking O(n) time because if you don’t check it, you might miss it. So no, your algorithm isn’t faster than O(n) it is in fact O(n log n) as you are basically just running merge sort.

Here is more data on the Selection problem

I thought about it and realized I should probably do something a bit more than just state this as fact. So I’ve coded up a quick speed test. Now full disclosure, I’m not a Scheme programmer, so this is in Common Lisp but I think I converted your algorithm faithfully.

;; Direct "iteration" method -- theoretical O(n)
(defun find-max-001 ( list )
  (labels ((fm ( list cur )
             (if (null list) cur
               (let ((head (car list))
                     (rest (cdr list)))
                 (fm rest (if (> head cur) head cur))))))
    (fm (cdr list) (car list))))

;; Your proposed method  
(defun find-max-002 ( list )
  (labels ((odd-half ( list )
             (cond ((null list) list)
                   ((null (cdr list)) (list (car list)))
                   (T (cons (car list) (odd-half (cddr list))))))
           (even-half ( list )
             (if (null list) list (odd-half (cdr list)))))
    (cond ((null list) list)
          ((null (cdr list)) (car list))
          (T (let ((l1 (even-half list))
                   (l2 (odd-half list)))
               (max (find-max-002 l1) (find-max-002 l2)))))))

;; Simplistic speed test              
(let ((list (loop for x from 0 to 10000 collect (random 10000))))
  (progn
    (print "Running find-max-001")
    (time (find-max-001 list))
    (print "Running find-max-002")
    (time (find-max-002 list))))

Now you may be asking your self why you I am only using 10000 for the list size, because really that is fairly small for asymptotic calculations. The truth is there that sbcl recognizes that the first function is tail recursive and therefore abstracts it into a loop whereas it doesn’t with the second so that’s about as big as I could get without killing my stack. Though as you can see from the results below this is large enough to illustrate the point.

"Running find-max-001"
Evaluation took:
  0.000 seconds of real time
  0.000000 seconds of total run time (0.000000 user, 0.000000 system)
  100.00% CPU
  128,862 processor cycles
  0 bytes consed

"Running find-max-002"
Evaluation took:
  0.012 seconds of real time
  0.012001 seconds of total run time (0.012001 user, 0.000000 system)
  [ Run times consist of 0.008 seconds GC time, and 0.005 seconds non-GC time. ]
  100.00% CPU
  27,260,311 processor cycles
  2,138,112 bytes consed

Even at this level we are talking about a massive slowdown. It takes an increase to about one million items before the direct check each items once method slows down to the 10k evaluation of your algorithm.

 (let ((x (loop for x from 0 to 1000000 collect (random 1000000))))
   (time (find-max-001 x)))

Evaluation took:
  0.007 seconds of real time
  0.008000 seconds of total run time (0.008000 user, 0.000000 system)
  114.29% CPU
  16,817,949 processor cycles
  0 bytes consed

Final Thoughts and conclusions

So the next question that has to be asked is why the second algorithm really is taking that much longer. Without going into to much detail about tail recursion elimination there are a few things that really jump out.

The first one being cons. Now yes, cons is O(1) but it’s still another operation for the system to go through. And it requires the system to allocate and free memory ( have to fire up the garbage collector ). The second thing that really jumps out is that you are basically running a merge sort, except rather than just grabbing the lower and upper half of the list you are grabbing the even and odd nodes ( that also will take longer because you have to iterate every time to build the lists ). What you have here is an O(n log n) algorithm at best ( mind you, it’s merge sort which is really good for sorting ) but it carries a lot of extra overhead.