Hacker News Reader

Comment by cperciva | Hacker News Reader

The author points out that a two-stage process consisting of 1. counting the number of elements in the list, and then 2. finding the right element, is quite inefficient -- but he then presents a different approach which uses two pointers instead of one, yet is equally inefficient -- almost every pointer is dereferenced twice.

Challenge: Show how, using three pointers, you can find the kth last element from a linked list of unknown length N with no more than N + O(k) pointer dereferences.

View on HN

That's a neat one. My solution: pointers A, B, and C. A proceeds through the list. B is always at the largest multiple of k that is at or before A. C is at B-k. Every k steps, set C=B and B=A. When A reaches the end, step C forward B-A times.

Yep, that's it. I like this puzzle because while there are lots of examples where having 2 pointers is better than 1, it's the only (non-contrived) example I can think of where 1 point is just as good as 2, but 3 pointers is much better.

Neato.

If reference locality is a big concern and k is small, the following might perform better: allocate a ring buffer of size k+1 (ideally on the stack), enqueue the pointers as you go, when you hit the end, return the tail of the buffer.

Among other things, this problem well illustrates how the rules of optimization can vary wildly depending on low level architecture.

That doesn't help significantly, since you only save the final O(k) dereferences. The situation (small k) where it's practical to allocate a ring buffer like this is exactly the situation where it isn't useful.

Actually, you're right, it's the larger values of k where this might make a difference. If the list items are scattered in memory, the cost of the buffer increases very slowly with k compared to the cost of hitting those extra k/2 items.

Your "every k steps" operation executes N / k times, which isn't O(k) so I don't think it meets the requirements given.

His "every k steps" operation doesn't dereference any pointers; 0 * N / k is indeed O(k).

Fair enough, reading comprehension fail.

It's not equally inefficient. The former will trash the CPU cache on large lists, whereas the latter will not if the k is small.

True. But the author hadn't gotten to the point of counting operations yet, so I don't think he was trying to make a subtle point about memory hierarchies and non-constant access times. :-)

The way I thought of immediately uses 0 pointers:

  (defun nthFromEnd (lst n)
    (labels ((from-end-helper (lst n)
      (if (null lst)
        0
        (let ((ret (from-end-helper (cdr lst) n)))
          (if (eq ret n)
            (throw 'answer (car lst))
            (+ ret 1))))))
      (catch 'answer
        (when (from-end-helper lst n)
          nil))))

  CL-USER> (nthfromend '(1 2 3 4 5) 6)
  NIL
  CL-USER> (nthfromend '(1 2 3 4 5) 3)
  2
  CL-USER> (nthfromend '(1 2 3 4 5) 0)
  5

I didn't hammer it very hard so maybe I missed a case or two. The other obvious problem is that it's not tail recursive (nor very elegant in general)

What about going through the list once, put each node onto a stack, then pop n - 1 elements off the stack, and the nth last element will be on the top of the stack. Edit: uses too many pointers as cperciva points out below.

That uses N additional memory locations, not 3.

heh. thanks for that comment. i had to sit and think for a moment.

Reply on news.ycombinator.com