HiveBrain v1.2.0
Get Started
← Back to all entries
patternMinor

Why is Brent's Cycle Detection method faster at finding a Linked List cycle than Floyd's Cycle Detection method?

Submitted by: @import:stackexchange-cs··
0
Viewed 0 times
cyclewhyfloydmethodthanlinkedfasterdetectionfindinglist

Problem

I understand in Floyd’s cycle, you are finding a cycle in a linked list by moving two counters- one by a factor of 2, other by a factor of 1. In Brent’s you are basically doing the same but the one factor moves by multiplying 2 instead by merely adding 2. Is there any math explanation behind why Brent’s is faster than Floyd’s?

Solution

The performance of cycle-finding algorithms depends on two parameters $m,n$. Here $n$ is the length of the cycle, and $m$ is the initial position of the cycle. For example, consider the sequence
$$ 2, 3, 5, 6, 5, 6, 5, 6, \ldots $$
Here the cycle is $5,6$ and so $n = 2$. The first index of the cycle (assuming $x_1 = 2$ and so on) is $m = 3$.

We assume that the sequence is generated by repeatedly applying some function $f$. We measure the complexity of cycle-finding algorithms by the number of applications of $f$.

According to Brent's paper, the complexity of Floyd's algorithm is between $3\max(m,n)$ and $3(m+n)$, and that of Brent's is at most $2\max(m,n) + n$, which is always better than $3\max(m,n)$.

A perhaps more meaningful comparison is what happens in the average case. In this case we assume that $f$ is a random function on a universe of size $N$ (the starting point doesn't matter in this case). Knuth showed that the expected running time of Floyd's algorithm is roughly $3.0924\sqrt{N}$, whereas Brent's algorithm runs in expected time roughly $1.9828\sqrt{N}$, as worked out in Brent's paper.

For more details, take a look at Brent's paper and the references therein.

Context

StackExchange Computer Science Q#63234, answer score: 4

Revisions (0)

No revisions yet.