<p>If all that you want to do is count the number of cycles, you can do this with 2|<em>S</em>| bits (plus change) worth of space. It seems unlikely that you will be able to do much better unless <em>S</em> or <em>f</em> have some particularly convenient properties.</p>

<p>Start with an array A storing integers {0,1,2} &mdash; one per element of <em>S</em> &mdash; initialized to zero; we will indicate these as <code>(unexplored)</code>, <code>(partially explored)</code>, and <code>(fully explored)</code>. Initialize a cycle counter to zero. For each element <em>s</em>&nbsp;&isin;&nbsp;<em>S</em> in order, do the following:</p>

<ol>
<li>If A[<em>s</em>]&nbsp;=&nbsp;<code>(fully explored)</code>, skip to step 6.</li>
<li>Set A[<em>s</em>]&nbsp;&larr;&nbsp;<code>(partially explored)</code>, and set an iterator <em>j</em>&nbsp;&larr;&nbsp;<em>f(s)</em>.</li>
<li>While A[<em>j</em>]&nbsp;=&nbsp;<code>(unexplored)</code>, set A[<em>j</em>]&nbsp;&larr;&nbsp;<code>(partially explored)</code>, and set <em>j</em>&nbsp;&larr;&nbsp;<em>f(j)</em>.</li>
<li>If A[<em>j</em>]&nbsp;=&nbsp;<code>(partially explored)</code>, we have closed a new cycle; increment <em>c</em> by 1. (If you want to keep a record of some representative of this cycle, the current value of <em>j</em> will do as an arbitrary choice; of course, this won't necessarily be the minimal element in the cycle under your preferred order &lt;.) Otherwise, we have A[<em>j</em>]&nbsp;=&nbsp;<code>(fully explored)</code>, which means that we have discovered a pre-explored orbit which ends in an already counted cycle; do not increment <em>c</em>.</li>
<li>To indicate that the orbit starting at <em>s</em> has now been fully explored, set <em>j</em>&nbsp;&larr;&nbsp;<em>s</em>. <br>While A[<em>j</em>]&nbsp;=&nbsp;<code>(partially explored)</code>, set A[<em>j</em>]&nbsp;&larr;&nbsp;<code>(fully explored)</code> and set <em>j</em>&nbsp;&larr;&nbsp;<em>f(j)</em>.</li>
<li>Proceed to the next element <em>s</em>&nbsp;&isin;&nbsp;<em>S</em>. </li>
</ol>

<p>Thus, each cycle among the orbits induced by <em>f</em> will be counted once; and any elements you record as representatives will be elements of distinct cycles. The memory requirements are 2|<em>S</em>| for the array A, O(log |<em>S</em>|) for the cycle count, and other odds and ends.</p>

<p>Each element <em>s</em>&nbsp;&isin;&nbsp;<em>S</em> will be visited at least twice: once when the value of A[<em>s</em>] is changed from <code>(unexplored)</code> to <code>(partially explored)</code>, and once for the change to <code>(fully explored)</code>. The total number of times that any nodes are revisited after having been <code>(fully explored)</code> is bounded above by the number of attempts to find new cycles which fail to do so, which is at most |<em>S</em>| &mdash; arising from the main loop iterating through all elements of <em>S</em>. Thus, we can expect this process to involve at most 3|<em>S</em>| node-traversals, counting all the times that nodes are visited or revisited. </p>

<p>If you want to keep track of representative elements of the cycles, and you really would like them to be the minimal elements, you can bound the number of node visitations to 4|<em>S</em>|, if you add an additional "lap around the cycle" at step 4 to find a representative which is smaller than the one where you close the loop. (If the orbits under <em>f</em> consisted <strong>only</strong> of cycles, this extra work could be avoided, but that's not true of arbitrary <em>f</em>.)</p>

CC BY-SA 3.0
2011-08-23T17:59:14.280Z
Excellent, this improves on the silly $O(|S|\log|S|)$ space algorithm I had in mind.  I don't actually need representatives; I introduced $<$ just in case it would be useful to some algorithm.
Charles
CC BY-SA 3.0
2011-08-23T18:05:03.973Z
I wonder if there's a way to use much less space in the case where there are few total cycles without using more than polynomial space.  Ah, no matter; this will do for my needs.
Charles
CC BY-SA 3.0
2011-08-23T19:20:42.250Z
It seems to me that this should be in #L (using matrix powering). Can this be #L-hard?
Kaveh
CC BY-SA 3.0
2011-08-23T20:11:52.393Z
@Charles: see my more recent answer which will give you improvements if you know that *#cycles* ∈ o(*|S|*). It's uses more than polylog *|S|* space, but if you're willing to trade off space and time it may be better for you.
Niel de Beaudrap
CC BY-SA 3.0
2011-08-23T20:41:02.150Z
@Niel de Beaudrap: Thank you!  +1 for both.  This algorithm seems best as long as the data fits in-memory; once it spills out I'll look at using the other.  (It's possible that the other would be better if I could fit everything in cache, but that may be too much hassle.)
Charles
CC BY-SA 3.0
2011-08-23T17:40:57.227Z
2011-08-23T17:48:46.357Z
2011-08-23T17:48:46.357Z
Niel de Beaudrap
<p>If you have very few cycles, here's an algorithm which will use less space, but take substantially longer to terminate.</p>

<p><strong>[Edit.]</strong> My previous run-time analysis missed the crucial cost of determining whether the nodes we visit are among those previously sampled; this answer has been somewhat revised to correct this.</p>

<p>We again iterate through all of the elements of <em>S</em>. As we explore orbits of the elements <em>s</em>&nbsp;&isin;&nbsp;<em>S</em>, we sample from the nodes that we've visited, in order to be able to check if we come across them again. We also maintain a list of samples from of 'components' &mdash; unions of orbits which terminate in a common cycle (and which are therefore equinumerous to cycles) &mdash; that have previously been visited.</p>

<p>Initialize an empty list of components, <code>complist</code>. Each component is represented by a collection of samples from that component; we also maintain a search tree <code>samples</code> which stores all those elements which have been selected as samples for some component or other. Let <em>G</em> be a sequence of integers up to <em>n</em>, for which membership is efficiently determinable by computing some boolean predicate; for example, powers of 2 or perfect <em>p</em><sup>th</sup> powers for some integer <em>p</em>.
For each <em>s</em>&nbsp;&isin;&nbsp;<em>S</em>, do the following:</p>

<ol>
<li>If <em>s</em> is in <code>samples</code>, skip to step #5.</li>
<li>Initialize an empty list <code>cursample</code>, an iterator <em>j</em>&nbsp;&larr;&nbsp;f(<em>s</em>), and a counter <em>t</em>&nbsp;&larr;&nbsp;1.</li>
<li>While <em>j</em> is not in <code>samples</code>:<br>
&mdash; If <em>t</em>&nbsp;&isin;&nbsp;<em>G</em>, insert <em>j</em> into both <code>cursample</code> and <code>samples</code>.<br>
&mdash; Increment <em>t</em> and set <em>j</em>&nbsp;&larr;&nbsp;<em>f(j)</em>.</li>
<li>Check to see if <em>j</em> is in <code>cursample</code>. If not, we have encountered a previously explored component: we check which component <em>j</em> belongs to, and insert all of the elements of <code>cursample</code> into the appropriate element of <code>complist</code> to augment it. Otherwise, we have re-encountered an element from the current orbit, meaning that we have traversed a cycle at least once without encountering any representatives of previously-discovered cycles: we insert <code>cursample</code>, as a collection of samples from a newly found component, into <code>complist</code>.</li>
<li>Proceed to the next element <em>s</em>&nbsp;&isin;&nbsp;<em>S</em>.</li>
</ol>

<p>For <em>n</em>&nbsp;=&nbsp;|<em>S</em>|, let <em>X(n)</em> be a monotone increasing function describing the expected number of cycles (<em>e.g.</em>&nbsp;<em>X(n)</em> =&nbsp;<em>n</em><sup>1/3</sup>), and let <em>Y(n)</em> = <em>y(n)</em>&nbsp;log(<em>n</em>) &isin; &Omega;(<em>X(n)</em>&nbsp;log(<em>n</em>)) be a monotone increasing function determining a target for memory usage (<em>e.g.</em>&nbsp;<em>y(n)</em> =&nbsp;<em>n</em><sup>1/2</sup>). We require <em>y(n)</em>&nbsp;&isin;&nbsp;&Omega;(<em>X(n)</em>) because it will take at least <em>X(n)</em>&nbsp;log(<em>n</em>) space to store one sample from each component.</p>

<ul>
<li><p>The more elements of an orbit we sample, the more likely we are to quickly select a sample in the cycle at the end of an orbit, and thereby quickly detect that cycle. From an asymptotics point of view, it then makes sense to obtain as many samples as our memory bounds permit: we may as well set <em>G</em> to have an expected <em>y(n)</em> elements which are less than <em>n</em>.<br>&mdash; If the maximum length of an orbit in <em>S</em> is expected to be <em>L</em>, we may let <em>G</em> be the integer multiples of <em>L</em>&nbsp;/&nbsp;<em>y(n)</em>.<br>&mdash; If there is no expected length, we may simply sample once every <em>n</em>&nbsp;/&nbsp;<em>y(n)</em> elements; this is in any case an upper bound on the intervals between samples.</p></li>
<li><p>If, in seeking a new component, we begin to traverse elements of <em>S</em> which we have previously visited (either from a new component being discovered or an old one whose terminal cycle has already been found), it will take at most <em>n</em>&nbsp;/&nbsp;<em>y(n)</em> iterations to encounter a previously sampled element; this is then an upper bound on the number of times, for each attempt to find a new component, we traverse redundant nodes. Because we make <em>n</em> such attempts, we will then redundantly visit elements of <em>S</em> at most <em>n</em><sup>2</sup>&nbsp;/&nbsp;<em>y(n)</em> times in total.</p></li>
<li><p>The work required to test for membership in <code>samples</code> is O(<em>y(n)</em>&nbsp;log&nbsp;<em>y(n)</em>), which we repeat at every visitation: the cumulative cost of this checking is O(<em>n</em><sup>2</sup>&nbsp;log&nbsp;<em>y(n)</em>). There is also the cost of adding the samples to their respective collections, which cumulatively is O(<em>y(n)</em>&nbsp;log&nbsp;<em>y(n)</em>). Finally, each time we re-encounter a previously discovered component, we must expend up to <em>X(n)</em>&nbsp;log*&nbsp;<em>y(n)</em> time to determine which component we rediscovered; as this may happen up to <em>n</em> times, the cumulative work involved is bounded by <em>n&nbsp;X(n)</em>&nbsp;log&nbsp;<em>y(n)</em>.</p></li>
</ul>

<p>Thus, the cumulative work performed in checking whether the nodes we visit are among the samples dominate the run-time: this costs O(<em>n</em><sup>2</sup>&nbsp;log&nbsp;<em>y(n)</em>). Then we should make <em>y(n)</em> as small as possible, which is to say O(<em>X(n)</em>).</p>

<p>Thus, one may enumerate the number of cycles (which is the same as the number of components which end in those cycles) in O(<em>X(n)</em>&nbsp;log(<em>n</em>)) space, taking O(<em>n</em><sup>2</sup>&nbsp;log&nbsp;<em>X(n)</em>) time to do so, where <em>X(n)</em> is the expected number of cycles.</p>

CC BY-SA 3.0
2011-08-23T19:58:29.830Z
2011-08-23T21:48:18.003Z
2011-08-23T21:48:18.003Z
Niel de Beaudrap
<p>You can avoid the multiple passes over the same elements by using a <a href="http://en.wikipedia.org/wiki/Disjoint-set_data_structure" rel="nofollow">union set data-structure</a>. One pass over each element $s$ unioning the set containing $s$ with the set containing $f(s)$. This still uses a lot of memory.</p>

CC BY-SA 3.0
2011-08-23T14:26:21.583Z
2011-08-23T14:26:21.583Z
Peter Taylor
<p>I have a finite set $S$, a function $f:S\to S$, and a total order $&lt;$ on $S$. I want to find the number of distinct cycles in $S$.</p>

<p>For a given element $s\in S$ I can use Floyd's algorithm (or Brent's, etc.) to find the length of the cycle that repeated applications of $f$ sends $s$ to; with a bit more effort I can identify this cycle (e.g. by its $&lt;$-minimal element).  A bad method for solving the problem would be to repeat this each element, sort the resulting minimal elements discarding duplicates, and return the count.  But this potentially involves many passes over the same elements and large space requirements.</p>

<p>What methods have better time and space performance?  I'm not even sure what's the best way to measure the space needed&mdash;if $f$ is the identity function then any method that stores all cycles will use $\Omega(n)$ space.</p>

CC BY-SA 3.0
2011-08-23T14:20:27.970Z
One of the natural ways to measure the space is to consider S as the set of n-bit strings and f as an oracle.  Then the naive algorithm which you described requires exponential space.  One may seek for an algorithm which uses only polynomial space, but this does not sound likely to be possible to me.
Tsuyoshi Ito
CC BY-SA 3.0
2011-08-23T14:57:22.840Z
That's what I meant by "I don't know what's the best way to measure space".  Possibly I should target O(poly(n) + y) where y is the output, so that space used is polynomial as long as y is sufficiently small.
Charles
CC BY-SA 3.0
2011-08-23T15:08:27.330Z
Does your function *f* have any usable properties? Whether or not the algorithm is polynomial or exponential in your preferred way of expressing the input size will be somewhat moot if the practical answer is that the algorithm will take both time and space on the order of the cardinality of *S*.
Niel de Beaudrap
CC BY-SA 3.0
2011-08-23T15:29:44.300Z
@Niel de Beaudrap: I'm not sure what properties would be useful.  I expect that the number of distinct cycles is small, though, probably $O(\sqrt[3]n)$; that's why I suggested a function of $y$ and $n$ instead of just $n$.  I'm willing to use space exponential in the number of bits of output, if needed.
Charles
<graph-theory><graph-algorithms>
Finding all cycles
Charles
# Finding all cycles

(Asked by: username_0 on 2011-08-23)

I have a finite set $S$, a function $f:S\to S$, and a total order $<$ on $S$. I want to find the number of distinct cycles in $S$.

For a given element $s\in S$ I can use Floyd's algorithm (or Brent's, etc.) to find the length of the cycle that repeated applications of $f$ sends $s$ to; with a bit more effort I can identify this cycle (e.g. by its $<$-minimal element). A bad method for solving the problem would be to repeat this each element, sort the resulting minimal elements discarding duplicates, and return the count. But this potentially involves many passes over the same elements and large space requirements.

What methods have better time and space performance? I'm not even sure what's the best way to measure the space needed—if $f$ is the identity function then any method that stores all cycles will use $\Omega(n)$ space.

**Tags:** graph-theory, graph-algorithms
> **Comments:**
> **username_1**: One of the natural ways to measure the space is to consider S as the set of n-bit strings and f as an oracle.  Then the naive algorithm which you described requires exponential space.  One may seek for an algorithm which uses only polynomial space, but this does not sound likely to be possible to me.  
> **username_0**: That's what I meant by "I don't know what's the best way to measure space".  Possibly I should target O(poly(n) + y) where y is the output, so that space used is polynomial as long as y is sufficiently small.  
> **username_2**: Does your function *f* have any usable properties? Whether or not the algorithm is polynomial or exponential in your preferred way of expressing the input size will be somewhat moot if the practical answer is that the algorithm will take both time and space on the order of the cardinality of *S*.  
> **username_0**: @Niel de Beaudrap: I'm not sure what properties would be useful.  I expect that the number of distinct cycles is small, though, probably $O(\sqrt[3]n)$; that's why I suggested a function of $y$ and $n$ instead of just $n$.  I'm willing to use space exponential in the number of bits of output, if needed.  

---

## 3 answers

### Answer by username_2 on 2011-08-23. Score: 7 | Accepted answer

If all that you want to do is count the number of cycles, you can do this with 2|*S*| bits (plus change) worth of space. It seems unlikely that you will be able to do much better unless *S* or *f* have some particularly convenient properties.

Start with an array A storing integers {0,1,2} — one per element of *S* — initialized to zero; we will indicate these as `(unexplored)`, `(partially explored)`, and `(fully explored)`. Initialize a cycle counter to zero. For each element *s* ∈ *S* in order, do the following:

1. If A[*s*] = `(fully explored)`, skip to step 6.
2. Set A[*s*] ← `(partially explored)`, and set an iterator *j* ← *f(s)*.
3. While A[*j*] = `(unexplored)`, set A[*j*] ← `(partially explored)`, and set *j* ← *f(j)*.
4. If A[*j*] = `(partially explored)`, we have closed a new cycle; increment *c* by 1. (If you want to keep a record of some representative of this cycle, the current value of *j* will do as an arbitrary choice; of course, this won't necessarily be the minimal element in the cycle under your preferred order <.) Otherwise, we have A[*j*] = `(fully explored)`, which means that we have discovered a pre-explored orbit which ends in an already counted cycle; do not increment *c*.
5. To indicate that the orbit starting at *s* has now been fully explored, set *j* ← *s*.   
   While A[*j*] = `(partially explored)`, set A[*j*] ← `(fully explored)` and set *j* ← *f(j)*.
6. Proceed to the next element *s* ∈ *S*.

Thus, each cycle among the orbits induced by *f* will be counted once; and any elements you record as representatives will be elements of distinct cycles. The memory requirements are 2|*S*| for the array A, O(log |*S*|) for the cycle count, and other odds and ends.

Each element *s* ∈ *S* will be visited at least twice: once when the value of A[*s*] is changed from `(unexplored)` to `(partially explored)`, and once for the change to `(fully explored)`. The total number of times that any nodes are revisited after having been `(fully explored)` is bounded above by the number of attempts to find new cycles which fail to do so, which is at most |*S*| — arising from the main loop iterating through all elements of *S*. Thus, we can expect this process to involve at most 3|*S*| node-traversals, counting all the times that nodes are visited or revisited.

If you want to keep track of representative elements of the cycles, and you really would like them to be the minimal elements, you can bound the number of node visitations to 4|*S*|, if you add an additional "lap around the cycle" at step 4 to find a representative which is smaller than the one where you close the loop. (If the orbits under *f* consisted **only** of cycles, this extra work could be avoided, but that's not true of arbitrary *f*.)

> **Comments:**
> **username_0**: Excellent, this improves on the silly $O(|S|\log|S|)$ space algorithm I had in mind.  I don't actually need representatives; I introduced $<$ just in case it would be useful to some algorithm.  
> **username_0**: I wonder if there's a way to use much less space in the case where there are few total cycles without using more than polynomial space.  Ah, no matter; this will do for my needs.  
> **username_3**: It seems to me that this should be in #L (using matrix powering). Can this be #L-hard?  
> **username_2**: @Charles: see my more recent answer which will give you improvements if you know that *#cycles* ∈ o(*|S|*). It's uses more than polylog *|S|* space, but if you're willing to trade off space and time it may be better for you.  
> **username_0**: @Niel de Beaudrap: Thank you!  +1 for both.  This algorithm seems best as long as the data fits in-memory; once it spills out I'll look at using the other.  (It's possible that the other would be better if I could fit everything in cache, but that may be too much hassle.)  

---

### Answer by username_2 on 2011-08-23. Score: 5

If you have very few cycles, here's an algorithm which will use less space, but take substantially longer to terminate.

**[Edit.]** My previous run-time analysis missed the crucial cost of determining whether the nodes we visit are among those previously sampled; this answer has been somewhat revised to correct this.

We again iterate through all of the elements of *S*. As we explore orbits of the elements *s* ∈ *S*, we sample from the nodes that we've visited, in order to be able to check if we come across them again. We also maintain a list of samples from of 'components' — unions of orbits which terminate in a common cycle (and which are therefore equinumerous to cycles) — that have previously been visited.

Initialize an empty list of components, `complist`. Each component is represented by a collection of samples from that component; we also maintain a search tree `samples` which stores all those elements which have been selected as samples for some component or other. Let *G* be a sequence of integers up to *n*, for which membership is efficiently determinable by computing some boolean predicate; for example, powers of 2 or perfect *p*th powers for some integer *p*.
For each *s* ∈ *S*, do the following:

1. If *s* is in `samples`, skip to step #5.
2. Initialize an empty list `cursample`, an iterator *j* ← f(*s*), and a counter *t* ← 1.
3. While *j* is not in `samples`:  
   — If *t* ∈ *G*, insert *j* into both `cursample` and `samples`.  
   — Increment *t* and set *j* ← *f(j)*.
4. Check to see if *j* is in `cursample`. If not, we have encountered a previously explored component: we check which component *j* belongs to, and insert all of the elements of `cursample` into the appropriate element of `complist` to augment it. Otherwise, we have re-encountered an element from the current orbit, meaning that we have traversed a cycle at least once without encountering any representatives of previously-discovered cycles: we insert `cursample`, as a collection of samples from a newly found component, into `complist`.
5. Proceed to the next element *s* ∈ *S*.

For *n* = |*S*|, let *X(n)* be a monotone increasing function describing the expected number of cycles (*e.g.* *X(n)* = *n*1/3), and let *Y(n)* = *y(n)* log(*n*) ∈ Ω(*X(n)* log(*n*)) be a monotone increasing function determining a target for memory usage (*e.g.* *y(n)* = *n*1/2). We require *y(n)* ∈ Ω(*X(n)*) because it will take at least *X(n)* log(*n*) space to store one sample from each component.

* The more elements of an orbit we sample, the more likely we are to quickly select a sample in the cycle at the end of an orbit, and thereby quickly detect that cycle. From an asymptotics point of view, it then makes sense to obtain as many samples as our memory bounds permit: we may as well set *G* to have an expected *y(n)* elements which are less than *n*.  
  — If the maximum length of an orbit in *S* is expected to be *L*, we may let *G* be the integer multiples of *L* / *y(n)*.  
  — If there is no expected length, we may simply sample once every *n* / *y(n)* elements; this is in any case an upper bound on the intervals between samples.
* If, in seeking a new component, we begin to traverse elements of *S* which we have previously visited (either from a new component being discovered or an old one whose terminal cycle has already been found), it will take at most *n* / *y(n)* iterations to encounter a previously sampled element; this is then an upper bound on the number of times, for each attempt to find a new component, we traverse redundant nodes. Because we make *n* such attempts, we will then redundantly visit elements of *S* at most *n*2 / *y(n)* times in total.
* The work required to test for membership in `samples` is O(*y(n)* log *y(n)*), which we repeat at every visitation: the cumulative cost of this checking is O(*n*2 log *y(n)*). There is also the cost of adding the samples to their respective collections, which cumulatively is O(*y(n)* log *y(n)*). Finally, each time we re-encounter a previously discovered component, we must expend up to *X(n)* log\* *y(n)* time to determine which component we rediscovered; as this may happen up to *n* times, the cumulative work involved is bounded by *n X(n)* log *y(n)*.

Thus, the cumulative work performed in checking whether the nodes we visit are among the samples dominate the run-time: this costs O(*n*2 log *y(n)*). Then we should make *y(n)* as small as possible, which is to say O(*X(n)*).

Thus, one may enumerate the number of cycles (which is the same as the number of components which end in those cycles) in O(*X(n)* log(*n*)) space, taking O(*n*2 log *X(n)*) time to do so, where *X(n)* is the expected number of cycles.


---

### Answer by username_4 on 2011-08-23. Score: 1

You can avoid the multiple passes over the same elements by using a [union set data-structure](http://en.wikipedia.org/wiki/Disjoint-set_data_structure). One pass over each element $s$ unioning the set containing $s$ with the set containing $f(s)$. This still uses a lot of memory.


---

