[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LIST-LENGTH & circular lists

This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.



Sorry to be bringing up such an old subject, but I ran across this thread
as the result of a web search and couldn't help replying.

Before quoting the following, let me remind you that Harvey Stein proposed
that the "generalized length" of a list should be defined as the number of
elements, not the number of times you could apply cdr to the list.  

On Feb 22 1999, Doug Currie wrote the following:
>At 9:35 PM +0200 2/22/99, Harvey J. Stein wrote:
>>...
>>However, I don't think a generalized length is such a good idea.  It
>>implies a substantial amount of additional overhead on computing the
>>length of a list.  This overhead remains no matter what you return for
>>circular lists - it's the act of detecting them which adds the
>>overhead.
>
>Not necessarily. The length function must compute a count. At some point
>this count will exceed a (implementation dependent) limit, e.g., the size
>of the heap, when it becomes clear that the list is circular. For
>non-circular lists this adds little overhead, just one integer compare per
>iteration (in a clever low level implementation, it may add no overhead if
>it's combined with the detection of fixnum overflow to switch to bignum
>addition). For circular lists, this may take a while to detect, but on
>today's fast processors with lists that fit in cache it can be quite
>competitive with more complex approaches that allocate memory or use N*N*N
>algorithms. Using these counting techniques a list-length can be provided
>competitive in performance with a non-circular-list-detecting version.
>However, this approach doesn't provide a result for circular list more
>useful than 0 or #f.

I think you can compute the number of distinct elements in a circular list
in linear time and constant space without resorting to any
implemented-defined behavior of the runtime environment.

I defined the function below in MIT Scheme and evaluated the following:

    (define l '(1 2 3 4 5 6 7))
    (set-cdr! (list-tail l 6) (list-tail l 3))

    (circular-list-length l)
    ;Value: 7

    (circular-list-length '(1 2 3))
    ;Value: 3

    (circular-list-length '())
    ;Value: 0

Here's the function definition, which works for non-circular lists as well.
(define (circular-list-length lst)
  "Return the number of distinct elements of circular list LST."
  (let ((tortoise lst)
        (hare lst)
        (tortoise-advance #t)
        (len 0))
    ;; Find a member of the list guaranteed to be within the cycle, and
    ;; compute length if list turns out to be non-circular.
    (do ()
        ((null? hare))
      (set! hare (cdr hare))
      (set! len  (1+ len))
      (set! tortoise-advance (not tortoise-advance))
      (if tortoise-advance
           (set! tortoise (cdr tortoise)))
      (if (eq? hare tortoise)
          (begin
            (set! hare '())
            (set! len  0))))

    (if (and (not (null? lst))
             (zero? len))
        (begin
          ;; Find period of cycle.
          (set! hare (cdr tortoise))
          (set! len 1)
          (do ()
              ((eq? hare tortoise))
            (set! hare (cdr hare))
            (set! len (1+ len)))

          ;; Give hare a head start from the start of the list equal to the
          ;; loop size.  If both move at the same speed they must meet at
          ;; the nexus because they are in phase, i.e. when tortoise enters
          ;; the loop, hare must still be exactly one loop period
          ;; ahead--but that means it will be pointing at the same list
          ;; element.
          (set! tortoise lst)
          (set! hare (list-tail lst len))
          (do ()
              ((eq? tortoise hare))
            (set! hare (cdr hare))
            (set! tortoise (cdr tortoise))
            (set! len (1+ len)))))
    len))