Here's an alternative, for .NET 3.5:
public static IEnumerable<T> RotateLeft<T>(IEnumerable<T> collection)
{
return RotateLeft(collection, 1);
}
public static IEnumerable<T> RotateLeft<T>(IEnumerable<T> collection,
int places)
{
return collection.Skip(places).Concat(collection.Take(places));
}
And since in 3.5 you get "Count()", it's simple enough to extend the idea
to handle left and right rotations:
public static IEnumerable<T> Rotate<T>(IEnumerable<T> collection, int
places)
{
if (places < 0)
{
places += collection.Count();
}
return collection.Skip(places).Concat(collection.Take(places));
}
Where "places" is assumed to be within range, of course (I figure that
since that seemed to be an assumption in your version, I'm allowed to make
the same assumption
...note that the original handles out-of-range input
just fine, if inefficiently).
Though, one thing I'm wondering about is the efficiency of the Count()
method. Except for the 1-place rotate, the above would still always at
least as efficient as the originally-proposed "rotate by 1, once for each
place" approach. But it's tempting to throw in another call to Count() to
deal with out-of-range values of "place" (by using % to bring it back into
range), and if it's going to keep enumerating the entire collection each
time you call Count(), that would be nice to know (so you could cache the
result).
Even barring 3.5, the original need not be so inefficient. Here's a
version that does only left-shifts without all the repeated enumerations
(has the same assumption that the specified rotation is within range):
public static IEnumerable<T> RotateLeft<T>(IEnumerable<T>
collection, int crotate)
{
using (IEnumerator<T> enumerator = collection.GetEnumerator())
{
T[] rgt = new T[crotate];
for (int irotate = 0; irotate < crotate; irotate++)
{
enumerator.MoveNext()
rgt[irotate] = enumerator.Current;
}
while (enumerator.MoveNext())
{
yield return enumerator.Current;
}
foreach (T t in rgt)
{
yield return t;
}
}
}
The above also doesn't deal with out-of-range input, but that's just for
the purpose of illustration. It wouldn't be difficult to detect hitting
the end of the collection in the initial for() loop and handling that
appropriately (i.e. at that point, you now know how large the collection
is and can calculate the size-constrained rotation that is equivalent to
the asked-for one; if handling that case one would probably want to use a
List<T> instead of a T[] to store the intermediate result as well, to
avoid allocating an arbitrarily huge array).
Also, noting that the non-3.5 versions rely heavily on the custom
enumerator syntax, avoiding allocation of a lot of extra data, at least
for small rotates to the left. The original has no real memory bounding
issues, and my version above is fine as long as the number of rotations
doesn't get too large (and frankly, if it's large enough to cause an
out-of-memory problem, I suspect that the nested iteration approach would
cause a "this algorithm can't finish in a reasonable amount of time"
problem
).
How does the 3.5 syntax handle this? Will it internally allocate a copy
or copies of the collection for the purpose of providing the various
intermediate results? Or is there something behind the scenes that is
essentially equivalent to these custom enumerator approaches?
And finally, how does this relate to the article/web page you posted
awhile back regarding custom enumerators attached to asynchronous i/o?
The two non-3.5 versions here only enumerate through the collection once;
does the 3.5 version break if you've got an enumerator that is only valid
for a single enumeration?
Pete
