kalebdark / morelinq

Automatically exported from code.google.com/p/morelinq

KalebDark

Jekyll & Hide

morelinq's Issues

Need a wiki page for each operator

We should really create a wiki page with a simple example of each operator 
as we implement it.

Original issue reported on code.google.com by jonathan.skeet on 15 Feb 2009 at 9:28

Replace ImbalancedZipStrategy with distinct Zip* methods

The current use of an enumeration (ImbalancedZipStartegy) to express the 
required behavior seems awkward because it's not something you want to be 
able to vary externally, which is usually why you would make a parameter 
or argument. Plus, it's a little cumbersome to write and read back in code 
and not very LINQ-ish in spirit. The enumeration could certainly be used 
internally for sharing the implementation logic but the public API should 
use distinct and clear operator names that imply the strategy. For example:

- EquiZip:
  Sequences must be equal in length otherwise throw error

- Zip: 
  Truncates to shorter of the two sequences

- ZipLongest: 
  Uses longer of the two sequences while padding shorter of the two

There is a very subtle yet major idea behind extension methods and LINQ 
that the enumeration also works against. If the enumerable source type 
wants to provide an optimization for an operator, it can do so by 
providing a method by the same name and signature as the operator in 
question. If we use an enumeration that comes from MoreLINQ then the other 
type has to take in a dependency that won't be looked upon lightly. If we 
take the approach of embodying the strategy in the name (assuming this
is a compile-time decision), then we have simple signatures with Zip, 
EquiZip and ZipLongest being distinct and clear names. Now, if there is a 
type called SuperDuperList<T> that wants to provide an optimization for 
Zip, EquiZip and ZipLongest (or any one of the three) then one can do so 
using simply base and generic types. Right now, with the enumeration, 
there is no choice but to support all strategies and take a hit on 
MoreLINQ! This is how Enumerable.Contains works. When using Contains on 
variables typed as List<T> or IList<T>, the LINQ extension method is not 
used! If one wants to force use of the LINQ's Contains implementation then 
one has to hop over AsEnumerable first.

This approach keeps MoreLINQ close to how LINQ operators should be 
designed, taking built-in ones as guidance.

P.S. This issue was creation out of comments in issue #6.

Original issue reported on code.google.com by azizatif on 7 Apr 2009 at 7:35

Scan operation

A primitive that implements the [scan/prefix sum][1] operation. Useful in
many scenarios, e.g. radix sort can be implemented efficiently using such
an operation.

Scans also form an integral part of the Haskell Prelude and stream
programming APIs (see CUDPP for NVIDIA CUDA) – in part because it can be
implemented work efficiently for parallel architectures.

[1]: http://en.wikipedia.org/wiki/Prefix_sum

Original issue reported on code.google.com by [email protected] on 17 Feb 2009 at 8:07

Attachments:

• scan.patch

Review: MoreEnumerable.PermutedSubsets()

Purpose of code changes on this branch:

Rev 122: Implementation of the PermutedSubsets() extension method which
efficiently generates the set of all permutations of the set of all subsets
of a sequence. An overload is provided that restricts the results to only
subsets of a given size. The implementation is built by iteratively
composing the Subsets() and Permutations() operators.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 17 Jan 2010 at 5:09

Review: MoreEnumerable.PairUp()

Purpose of code changes on this branch:

Rev 127: Implementation of the PairUp extension method, which combines
adjacent pairs in the source sequence and returns the result of applying a
user-defined projection to them. PairUp can operate on either odd-length or
even-length sequences. In the case of add-length sequences, an optional
imbalance strategy can be supplied, which defines whether PairUp should
skip the last (unpaired) value, or process the terminal element with a
default value pairing. The result of PairUp applied to a non-empty
sequence, will always be a sequence of half the length of the source sequence.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 18 Jan 2010 at 5:08

Review: MoreEnumerable.NestedLoops()

Purpose of code changes on this branch:

Rev 119 - Implementation of the NestedLoops() operator, which expands an
Action into a sequence whose length is equivalent to the total number of
iterations of a set of nested loop. NestedLoops() builds on the Repeat()
operator to allow the dynamic construction of nested loops. It is passed an
Action and an IEnumerable<int> that reflects the number of iterations of
each level of the nested loop. The result is a sequence which repeats the
Action parameter as many times as the product of the loop counts. This
method allows the construction of virtualized, streaming sequences whose
length exceeds the representational bounds of Int32, Int64 and even
decimal. This is useful in those cases where you want to overcome the range
limitations of the built-in .NET numeric types (the Permutations extension
method is the primary beneficiary and best example of this).

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.
* Whether this is the simplest way to support the requirements of operators
like Permutations() - or whether it's overkill.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 17 Jan 2010 at 6:30

• Blocked on: #37

Add "Dump" methods

We should have "Dump" methods (and possibly equivalents which don't 
consume, just like ForEach vs Pipeline or whatever they'll be called) to 
make it easier to dump a sequence to the console, another TextWriter, or 
some arbitrary Action<string> consumer.

Original issue reported on code.google.com by jonathan.skeet on 25 Mar 2009 at 8:34

DistinctBy should allow a null comparer

What steps will reproduce the problem?

int[] source = { 1, 2, 3, 2, 1 };
source.DistinctBy(x => x, null);

What is the expected output? What do you see instead?

The expected output is { 1, 2, 3 } assuming the default comparer 
implementation since a null comparer is supplied. This would be consistent 
with the Enumerable.Distinct operator from Microsoft's base LINQ-to-
Objects implementation. However, what one sees instead is a 
ArgumentNullException from DistinctBy.

Original issue reported on code.google.com by azizatif on 15 Feb 2009 at 6:58

Silverlight Trace methods could output using Console.WriteLine or Debug.WriteLine

Silverlight doesn't currently support the concept of tracing, which leaves 
the Trace methods a little lacking, as you know. Perhaps Trace could in the 
Silverlight implementation could use Console.WriteLine or Debug.WriteLine 
or both so that we have some pseudo-tracing.

Original issue reported on code.google.com by [email protected] on 12 Mar 2009 at 1:32

Consider renaming Zip methods

(No need for one issue per method.)

We should look at what .NET 4.0 is going to do in terms of Zip methods, and 
try to match those so it's a simple hand-over when moving from 3.5 + 
MoreLinq to 4. We should also make sure that the duplicate naming doesn't 
cause a problem - or have a separate build which doesn't include it.

When .NET 4.0 beta 1 comes out we can take a look.

Original issue reported on code.google.com by jonathan.skeet on 7 Apr 2009 at 9:53

Review: MoreEnumerable.Exclude()

Purpose of code changes on this branch:

Rev 144: Implementation of the Exclude operator which eliminates a range of
items from a sequence. Exclude is the logical inverse of Slice and can
exclude elements from any portion of a sequence. Exclude operates in a
deferred and streaming manner.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 24 Jan 2010 at 12:31

Review: MoreEnumerable.Incremental()

Purpose of code changes on this branch:

Rev 137: Implementation of the Incremental operator which visits each
adjacent pair of elements in a sequence: {N,N+1}, {N+1,N+2}, {N+2,N+3} ...
and applies a projection to them. An overload is available that is also
supplied the zero-based index of the *second* element in the pair. The
number of items in the result sequence will always be one less than in the
source. Incremental returns an empty sequence if passed a sequence of less
than two items. Incremental operates in a deferred, streaming fashion. 

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 23 Jan 2010 at 5:16

Add Exhaust/Consume operator

An Exhaust operator exists in the test project. It should be offered as a 
public operator in the base library.

Rationale: There is already ForEach and Exhaust is just the loop factored 
out, permitting consumption of a source without side-effect where needed. 
Together with Pipe, ForEach can be implemented in terms of Pipe plus 
Exhaust.

Also, while we're at it, consider Consume versus Exhaust. ;)

Original issue reported on code.google.com by azizatif on 17 Feb 2009 at 11:42

Implement SingleOrNew

Implement SingleOrNew as per 
http://stackoverflow.com/questions/561762/what-about-a-singleornew-method-
instead-of-singleordefault-in-linq/561787#561787

Original issue reported on code.google.com by jonathan.skeet on 18 Feb 2009 at 4:19

Rename Pipe to ViaAction/Cause/Visit

The Pipe operator sounds too general and vague. Any set of LINQ operations
chained together could be seen as a pipeline or pipe formation/composition.
Pipe also does not imply any side effect. Consequently, consider renaming
Pipe to ViaAction. ViaAction clearly states two things: (1) the operator is
pass-through, as in via, and (2) it implies an action, which for the
majority case is understood to be a side-effect.

Original issue reported on code.google.com by azizatif on 17 Feb 2009 at 9:05

New methods MinOrDefault and MaxOrDefault

When you start playing with LINQ queries over sequences of elements (e.g.
getting min / max value for enumerable source) sooner or later you will
come across this one -- the InvalidOperationException (“Sequence contains
no elements”).

The problem occurs as by default queries like IEnumerable<T>.Min(…) and
IEnumerable<T>.Max(…) do not play nicely if you try to execute them on an
empty sequence and just throw the exception described above. Unfortunately
these methods do not have a corresponding counterpart like Single(…) /
SingleOrDefault(…) that is smart enough to query the sequence if it is not
empty or alternatively use the default value without raising an exception.

Basically you got two options now:

    * Either perform the check on the enumerable sequence every time you
are querying it
    * OR integrate the logic in an extension method.

The second approach is much preferable so let’s add the missing link.

http://blogs.telerik.com/manoldonev/posts/08-10-17/linq_sequence_contains_no_ele
ments_extension_methods_to_the_rescue.aspx

Original issue reported on code.google.com by [email protected] on 17 Sep 2009 at 8:56

Review: MoreEnumerable.Random()

Purpose of code changes on this branch:

Implementation of a set of operators that allow generating sequences of
random numbers. Overloads are available that map to the Next() and
NextDouble() methods of System.Random. All overloads of Random() are
intended to be lazy, streaming generators that produce an infinite sequence
of random numbers (compliant with the constraints placed by the particular
overload used). 

When reviewing my code changes, please focus on:

* The public interface of the extension methods.
* Their compatibility with typical use and public interface of the
System.Random class.
* The effectiveness and clarity of the available XML comment documentation.
* How well these operators fit will into the MoreLINQ ecosystem of
extension methods.
* The correctness of the implementation and the extent of coverage
available from the corresponding unit tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 17 Jan 2010 at 3:56

• Blocked on: #37

ToDelimitedString delimits incorrectly on sequence starting with empty strings

What steps will reproduce the problem?

Call MoreEnumerable.ToDelimitedString on a sequence where the initial 
values of the sequence result in an empty strings.

What is the expected output? What do you see instead?

Expect all values of the sequence to be delimited. Instead values are 
delimited only after the first value in the sequence that results in a non-
empty string.

The following IronPython code illustrates the problem:

IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3603
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReference('MoreLinq')
>>> from MoreLinq.MoreEnumerable import ToDelimitedString
>>> print ToDelimitedString(['foo','bar','baz'])
foo,bar,baz
>>> print ToDelimitedString(['foo','','baz'])
foo,,baz
>>> print ToDelimitedString(['','','baz'])
baz
>>>

The last statement, should have resulted in:

,,baz

Original issue reported on code.google.com by azizatif on 18 Jan 2010 at 4:17

AssertCount still asserts in a release

Currently, the AssertCount call does not actually act like a traditional 
assert as it is not ignored in a release build. Maybe it should have the 
ConditionalAttribute applied or be renamed to reflect this non-traditional 
behaviour.

Original issue reported on code.google.com by [email protected] on 10 Mar 2009 at 10:15

Review: MoreEnumerable.OrderBy() and MoreEnumerable.ThenBy()

Purpose of code changes on this branch:

Rev 139: Implementation of the OrderBy and ThenBy operators which can be
supplied a parameter to control the direction of sorting. This allows
callers to avoid complicating their code with branching logic to call
OrderByDescending/ThenBeDescending when the sort direction is only known at
run-time.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.
* Whether operators of the same name as those in LINQ may have negative
consequences.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 23 Jan 2010 at 6:33

Implement Concat in terms of existing LINQ operations

This is only a suggestion to simplify the implementation of 
Concatenation.Concat operator in MoreLINQ. The attached patch proposes to 
implement Concat in terms of existing LINQ operators, yielding shorter 
code and reusing a tested base. Hopefully, you agree.

Original issue reported on code.google.com by azizatif on 12 Feb 2009 at 10:42

Attachments:

• Concatenation.patch

Review: MoreEnumerable.While()

Purpose of code changes on this branch:

Rev 138: Implementation of the While operator which consumes a sequence and
returns a projection of each element while some condition is true. Unlike
TakeWhile(), While supplies the condition delegate with the current and
previous element in the sequence, allowing conditions to be based on
changes between elements of the sequence. Wile operators in a deferred and
streaming manner.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 23 Jan 2010 at 6:18

Adding series generation/comprehension methods

Consider adding series generation/comprehension methods for programmatic
generation of collections "from scratch".

Not sure this would not technically be called a LINQ operator, but it is
very useful for generating data permutations more complex than a 1-step
range (as with Enumerable.Range), for tests or otherwise, as well as
generating ordinals to be paired with collection items using the Zip operator.

The method would have the following behavior given fairly vanilla generator
and terminal functions:

Series.Expand(2, n => n * n, n > 1000) => (2, 4, 8, 16, 32, 64, 128, 256, 512)

The method would have the following behavior given a vanilla generator
function and an element count:

Series.Expand(1, n => n + 3, 8) => (1, 4, 7, 10, 13, 16, 19, 22)

The method would generate new elements lazily and stream them.  This would
also allow an effectively "infinite" sequence to be generated, for example
for the purposes of Zipping with a collection of indeterminate length.

I have attached a patch with a proposed implementation and tests.  I placed
the method in its own file and static class because it is not strictly an
operator like the others.

Original issue reported on code.google.com by [email protected] on 16 Feb 2009 at 2:55

Attachments:

• Series.patch

Consider adding Zip operator

Consider adding Zip operator for sequences, somewhat akin to the built-in 
zip function in Python. See:
http://www.python.org/doc/2.5.2/lib/built-in-funcs.html#l2h-81

Zip has the following logical behavior given two sequences:

zip((1, 2, 3), (4, 5, 6)) -> ((1, 4), (2, 5), (3, 6))

It returns tuples, where each tuple contains the N-th element from each of 
the argument sequences. The returned sequence is truncated in length to 
the length of the shortest argument sequence.

The attached patch contains a proposed implementation along with unit 
tests. I think Zip belongs in the grouping category of operators (since it 
groups elements by their position).

It looks like Zip will make it into .NET Framework 4.0 (see 
http://codebetter.com/blogs/matthew.podwysocki/archive/2008/11/16/functiona
l-net-4-0-tuples-and-zip.aspx) so all the better to make it available to 
3.5 applications via this project.

Original issue reported on code.google.com by azizatif on 13 Feb 2009 at 12:01

Attachments:

• Zip.patch

Code review request for Split

Purpose of code changes on this branch:

When I added the Batch operator, I thought I could implement it in terms 
of a generalized Split operator. I was wrong, but the damage was already 
done and I had implemented and factored out all the work to implement a 
Split operator for any enumerable source. However, I have doubts about its 
general usefulness and is the reason why I am putting it in a branch.

When reviewing my code changes, please focus on:

I would appreciate it if you could review and comment on "utility" and 
general application of this operator. If you find that it makes good sense 
then I can merge it back into the turnk. Otherwise the branch can just 
serve as an archive.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by azizatif on 17 Feb 2009 at 6:17

• Merged into: #73

TakeRangeEvery method

TakeEvery is great for taking just one item at regular intervals, but it 
would also be useful to take a range of items at regular intervals.

TakeRangeEvery(this IEnumerable<T> items, int rangeCount, int step)

Original issue reported on code.google.com by [email protected] on 11 Mar 2009 at 4:22

Add support for enumerable noise sets

A useful method to perform algorithms that use noise would be to set up the
noise data as an enumeration, much like Enumerable.Range(int start, int
count). The proposed method would be Enumerable.Noise(int seed), yielding
infinite procedural noise generation. 

Then, to take five random numbers one would call var randomNumbers =
Enumerable.Noise(seed).Take(5); 

There is alot of uses for floating point noise aswell, mainly in procedural
fractal generation. 

Enumerable.Noise<float>(seed); // Generate noise between 0-1
Enumerable.NoiseSigned<float>(seed); // Generate noise between (-1)-1

Due to the problem of infinite enumeration, foreach loops on raw
enumerations of noise would be problematic. Perhaps one should set up a
maximum range of numbers?

Original issue reported on code.google.com by [email protected] on 25 Mar 2009 at 2:40

Create "RandomElement" method

We should have an extension method with returns a random element from the 
sequence.

See http://stackoverflow.com/questions/648196/random-row-from-
linq/648240#648240 for sample code.

Original issue reported on code.google.com by jonathan.skeet on 15 Mar 2009 at 6:08

Review: MoreEnumerable.RunLengthEncode()

Purpose of code changes on this branch:

Rev 125: Implementation of the RunLengthEncode() extension method which
operates on sequences and produces a new sequence representing the
occurrence of repeated runs of the same value in the original. The
resulting (transformed) sequence consists of zero or more
KeyValuePair<T,int> elements - where the Key identifies the item and the
Value is the occurrence count of that item in the original sequence.
RunLengthEncode has an overload that allows the caller to supply equality
semantics for the elements of the sequence being transformed.
RunLengthEncode is intended to operate in a deferred, streaming fashion -
allowing it to process sequences of arbitrary (or infinite) length.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.
* Whether the operator adheres to the description and behavior described above.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 18 Jan 2010 at 3:14

Code review request for reorg

Purpose of code changes on this branch:

Re-organize MoreLINQ so that all operators are implemented under the
Enumerable class, providing several advantages over the current structure
that classifies operators under their so-called category class.

When reviewing my code changes, please focus on:

The branch puts all operators under a single class called Enumerable, much
like the base LINQ operators it extends. However, each operator resides in
its own file and uses a partial modifier to allow the Enumerable definition
to fan out. The benefits of this new structure over the current are the
following:

* Regions are not needed to superficially organize and delimit operators
within a class just because the class seems to be growing big as new
overloads and operators are added to it. Regions work fine as a visual
navigation aid if you are in a sophisticated IDE like VS, but not when you
are browsing the source through other means, such as the online Subversion
browser, terminal or e-mail.

* Categorization of the operator is more of a documentation and learning
aid than an implementation concern. Once the MoreLinq.Pull namespace is
imported, all types extending IEnumerable<T> are available irrespective of
how the authors categorized them. The point is, it doesn't serve as aid for
the user of the pull operators. In the new organization, categorization
could be done (if absolutely needed) with a custom XML doc summary element.

* A single partial Enumerable is simple than multiple category classes.
There is no added benefit of the latter. Naming LINQ operators is hard
enough. Proper categorization adds additional subjectivity and headache for
authors. Before you can add an operator, you need to think about how to
name it and categorize (the exercise may not be entirely unhealthy or
useless). With the new organization, you just put it under Enumerable.

* If an operator needs to be located, one has to first try and remember the
class category, open that file and then add the operator or overload an
existing at the right place. With the new organization, you just create a
new file, define Enumerable as partial and add the operator implementation.
For an existing operator, locating its source code is dead easy because the
file is named after the operator.

* Since each operator lies in it own file in the proposed new organization,
there is less contention or risk of edit conflicts between authors working
on the same source file.

* With the proposed new organization, providing on-line links to a single
operator and all its overloads is as simple as providing a URL the
operator's file, as in http://tinyurl.com/MoreLinq-DistinctBy, whereas with
the current organization, the best you can do is point someone to the
category class and then ask them to look for the operator under there.

The are, however, two downsides, none of which seem to outweigh the
aforementioned advantages:

* All 134 tests now appear under a single fat fixture. For now, I have
classified the operators by category using the Category attribute from
NUnit. With this, you can still decide to run tests of only a single
category (using, for example, the /include switch from nunit-console) or
visually distinguish them in the GUI.

* If someone wants to use an operator that is not implemented as an
extension method or invoke it without the extension invocation syntax, then
the compiler may be confused between System.Linq.Enumerable and
MoreLinq.Pull.Enumerable. The conflict occurs only if System.Linq and
MoreLinq.Pull are imported in the same source file. This could be resolved
in one of two ways: (i) we use MoreEnumerable instead of Enumerable or (ii)
let the user of the code decide by introducing type aliases to her liking,
as in:

using LinqEnumerable = System.Linq.Enumerable;
using MoreEnumerable = MoreLinq.Pull.Enumerable;

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by azizatif on 4 Apr 2009 at 10:27

Make the assembly strong named

Without a strong name the assembly cannot be referenced by other strong 
named assemblies.

I know I can just grab the code and sign it myself, but it would be better 
if you could save me the hassle...

Original issue reported on code.google.com by martinho.fernandes on 1 Nov 2009 at 9:56

Review: MoreEnumerable.SortedMerge

Purpose of code changes on this branch:

Rev 126: Implementation of SortedMerge operator which combines two or more
ordered sequences into a single sequence that preserves the order. Merge
allows callers to supply comparison semantics using an overload that
accepts an IComparer<T>. SortedMerge operates in a deferred and streaming
fashion - it uses a (relatively) efficient algorithm whose run time is
proportional to the combined length of all sequences being merges.

SortedMerge DOES NOT guarantee a stable ordering if elements in multiple
sequences have the same value - meaning that no promises are made about
which items will appear first in the merged sequence. The results of
performing a SortedMerge on sequences that are not ordered or are not in
the same order is undefined.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.
* Whether the computational complexity (big-O) of the algorithm used is
appropriate for the problem being solved.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 18 Jan 2010 at 4:27

Add a roadmap

It would be helpful to add a wiki page that outlines a roadmap for the this
project. The roadmap could be expanded later on as the vision and scope
develops, but it should start by giving a clear idea of what constitutes
version 1.0. For example, how many operators are enough for 1.0? Is that
any measure? And so on.

Original issue reported on code.google.com by azizatif on 16 Feb 2009 at 11:03

Review: MoreEnumerable.Repeat()

Purpose of code changes on this branch:

Rev 118: Implementation of the Repeat() extension method that operates on
sequences rather than single elements. This extension method serves as a
logical expansion of the Enumerable.Repeat() method - except it repeats all
of the elements of a sequence, rather than a single element. It is a
building block for more sophisticated operators such as NestedLoops() and
Permutations().

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 17 Jan 2010 at 5:54

• Blocked on: #37

Review: MoreEnumerable.Partition()

Purpose of code changes on this branch:

Rev 128: Implementation of the Partition extension method, which transforms
a sequence into a series of sequences whose elements are defined by a set
of supplied partition sizes. Partition can be passed a projection function,
in which case the result is a sequence formed by first partitioning and
then transforming each partition into a result. An underflow strategy can
also be supplied, which control how partition behaves when there are
elements remaining in the source sequence after all explicit partitions
have been evaluated. Partition uses an unusual strategy for coping with
returning the "rest" of a sequence - it uses a special IEnumerable
implementation which caches the original enumerator.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.
* Whether the YieldRestEnumerator implementation is correctly implemented
and appropriately tested.
* Whether there is an easier way to deal with yielding the remainder of a
sequence, other than the YieldRestEnumerator approach.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 18 Jan 2010 at 5:38

EvenMoreLINQ branch (r119) build is broken

What steps will reproduce the problem?

1. Check out the branch EvenMoreLINQ:
   https://morelinq.googlecode.com/svn/branches/EvenMoreLINQ
2. Run build.cmd or buildw.cmd in the root of the working copy.

What is the expected output? What do you see instead?

Expected the build to succeed across the entire solution. Instead the test 
project fails with the following extract (see attached file for full 
output) towards the end that highlights the problem:

"C:\EvenMoreLINQ\MoreLinq.sln" (default target) (1) ->
"C:\EvenMoreLINQ\MoreLinq.Test\MoreLinq.Test.csproj" (default target) (3) -
>
(CoreCompile target) ->
  CSC : error CS2001: Source file 'Combinatorics.cs' could not be found

    0 Warning(s)
    1 Error(s)

Original issue reported on code.google.com by azizatif on 17 Jan 2010 at 11:21

• Blocking: #33, #35, #36

Attachments:

• build.txt

Add link to potential StackOverflow queries related to this project

Consider adding the following URL under "Links" on this project site:
http://stackoverflow.com/search?q=morelinq 

...as http://www.google.com/search?q=morelinq doesn't do justice. ;)

Original issue reported on code.google.com by azizatif on 7 Apr 2009 at 1:26

SelectWithIndex (or something similar)

I've seen a number of questions like this one: 
http://stackoverflow.com/questions/1593235/linq-to-xml-dictionary-conversion

Where the overload for Select taking a `Func<TSource,int,TResult>` is 
basically used to create key/value pairs. We should make this easier with a 
single method call - either using KeyValuePair or a new IndexValuePair 
struct.

Original issue reported on code.google.com by jonathan.skeet on 20 Oct 2009 at 8:52

Review: MoreEnumerable.Slice()

Purpose of code changes on this branch:

Rev 140: Implementation of the Slice operator which allows extraction of
the middle elements of a sequence, given a start index and a count. Slice
is functionally equivalent to: sequence.Skip(startIndex).Take(count) -
however it is clearer, and contains an optimization for collections that
implement IList<T>.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 23 Jan 2010 at 6:47

Silverlight 2.0 assembly

It would be great if the source was compilable for Silverlight deployment 
as well as regular .NET framework use. This should, in most cases, be as 
simple as using the same source and compiling for Silverlight.

Original issue reported on code.google.com by [email protected] on 18 Feb 2009 at 5:46

Make the assembly strong named

Without a strong name the assembly cannot be referenced by other strong 
named assemblies.

I know I can just grab the code and sign it myself, but it would be better 
if you could save me the hassle...

Original issue reported on code.google.com by martinho.fernandes on 1 Nov 2009 at 9:56

• Merged into: #30

Trace methods should only work on TRACE define

As with other Trace methods, the MoreLINQ Trace methods should not operate 
if the TRACE define is not specified.

Original issue reported on code.google.com by [email protected] on 11 Mar 2009 at 4:34

Error in description of TakeEvery

http://code.google.com/p/morelinq/source/browse/trunk/MoreLinq/TakeEvery.cs

The example documentation says "numbers.Every(2);" which obviously should
be "numbers.TakeEvery(2);"

Original issue reported on code.google.com by [email protected] on 11 Sep 2009 at 6:44

Add BreakWhen method

There are some nice Assert methods to simplify assertion but it would also 
be nice to specify breakpoints in a similar manner for use when debugging 
problems. It would certainly be easier than adding conditional breakpoints.

Original issue reported on code.google.com by [email protected] on 10 Mar 2009 at 10:11

New method: Sequence.Traverse

Sequence.Generate is able to traverse linked lists of reference types, but
it produces an infinite list and also doesn't check for null (nor
should/could it, generally speaking).

So it has to be used in a boilerplate idiom where it is combined with
TakeWhile, e.g.

Exception innermost = Sequence.Generate(caught, e =>
e.InnerException).While(e => e != null).Last();

The name Generate then becomes a little misleading, as we are not
generating a new list but traversing an existing list.

Also it is a bit counter-intuitive to have the check for null termination
appearing after the Generate call - perfectly safe due to the laziness, but
it looks dodgy.

Given the usefulness of this pattern, and the fact that we are not really
generating anything, it might make sense to make it a separate method
called Traverse, limited of course to reference types:

public static IEnumerable<TResult> Traverse<TResult>(TResult initial,
Func<TResult, TResult> generator) where TResult : class
{
    for (TResult current = initial; current != null; current =
generator(current))
        yield return current;
}

Original issue reported on code.google.com by [email protected] on 10 Mar 2009 at 11:18

IList<T> view operators from Stephen Cleary

Merge some or all of the operators from Stephen Cleary:

Operators for IEnumerable<T> lifted from List<T>/Array:
  int IndexOf<T>(this IEnumerable<T> source, T value)
  int IndexOf<T>(this IEnumerable<T> source, Func<T, bool> predicate) // 
List<T>.FindIndex
  int LastIndexOf<T>(this IEnumerable<T> source, T value)
  int LastIndexOf<T>(this IEnumerable<T> source, Func<T, bool> 
predicate) // List<T>.FindLastIndex

Operators for IList<T> lifted from List<T>/Array:
  IList<T> AsReadOnly<T>(this IList<T> list)
  void CopyTo<T>(this IList<T> list, int index, IList<T> destination, int 
destinationIndex, int count)
  void CopyTo<T>(this IList<T> list, IList<T> destination, int 
destinationIndex)
  void CopyTo<T>(this IList<T> list, IList<T> destination)
  int LastIndexOf<T>(this IList<T> list, T value)
  int LastIndexOf<T>(this IList<T> list, Func<T, bool> predicate) // 
List<T>.FindLastIndex

Operators optimized for IList<T> from Enumerable (.NET 3.5):
  IList<TResult> Select<TSource, TResult>(this IList<TSource> list, 
Func<TSource, TResult> selector)
  IList<TResult> Select<TSource, TResult>(this IList<TSource> list, 
Func<TSource, int, TResult> selector)
  IList<T> Skip<T>(this IList<T> list, int offset)
  IList<T> Take<T>(this IList<T> list, int count)
  IList<T> Reverse<T>(this IList<T> list)
  T Last(this IList<T> list, Func<T, bool> selector)
  T LastOrDefault(this IList<T> list, Func<T, bool> selector)

Operators optimized for IList<T> from EnumerableEx (Rx):
  IList<T> Repeat<T>(this IList<T> list, int count)
  IList<TResult> Zip<TFirst, TSecond, TResult>(this IList<TFirst> first, 
IList<TSecond> second, Func<TFirst, TSecond, TResult> zipper)
  IList<T> Memoize<T>(this IList<T> list)
  IList<T> MemoizeAll<T>(this IList<T> list)

Sources optimized for IList<T> from EnumerableEx (Rx):
  IList<T> Return<T>(T source)
  IList<T> Repeat<T>(T source, int count)
  IList<T> Concat<T>(params IList<T>[] others)
  IList<T> Concat<T>(IList<IList<T>> lists)
  IList<T> Generate<T>(int count, Func<T> generator)
  IList<T> Generate<T>(int count, Func<int, T> generator)

My own sequence/list operators:
 Zip (3-argument version):
  IEnumerable<TResult> Zip<TFirst, TSecond, TThird, TResult>(this 
IEnumerable<TFirst> first, IEnumerable<TSecond> second, 
IEnumerable<TThird> third, Func<TFirst, TSecond, TThird, TResult> zipper)
  IList<TResult> Zip<TFirst, TSecond, TThird, TResult>(this IList<TFirst> 
first, IList<TSecond> second, IList<TThird> third, Func<TFirst, TSecond, 
TThird, TResult> zipper)
 Flatten:
  IEnumerable<T> Flatten<T>(this IEnumerable<IEnumerable<T>> list)
  IList<T> FlattenList<T>(this IList<IList<T>> list)
 Select (bidirectional projection):
  IList<TResult> Select<TSource, TResult>(this IList<TSource> list, 
Func<TSource, TResult> selector, Func<TResult, TSource> reverseSelector)
 Slice:
  IList<T> Slice<T>(this IList<T> list, int offset, int count)
  IList<T> Step<T>(this IList<T> list, int step)
 CopyBackward:
  void CopyBackward<T>(this IList<T> list, int index, IList<T> 
destination, int destinationIndex, int count)

Original issue reported on code.google.com by [email protected] on 20 Nov 2009 at 3:29

Review: MoreEnumerable.Segment()

Purpose of code changes on this branch:

Rev 136: Implementation of the Segment operator which transforms a sequence
int a series of sequence that divide up the elements of the original
sequence. Segment uses a caller-supplied segmentation detector which
informs Segment when an element should begin a new segment. Overloads exist
which supply the segmentation detector with an element, or an element and
its zero-based index, or an element, previous element and index.
Individuals segments are buffered, but the overall operation is performed
in a streaming fashion - segments never visited are not computed.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 23 Jan 2010 at 5:13

Review: MoreEnumerable.Subsets()

Purpose of code changes on this branch:

Rev 117 - Implementation of a set of operators that produce a sequence of
subsets of an original source sequence. Subsets are produced in a deferred,
streaming manner. There are two primary overloads - one that produces all
subsets of a given sequence (of which there are 2^N), and an overload that
produces all k-sized subsets of a sequence (of which there are N!/((N-m)!m!)).

When reviewing my code changes, please focus on:

* The public interface of the extension methods.
* The effectiveness and clarity of the available XML comment documentation.
* How well these operators fit will into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* The clarity and division of responsibility of the implementation.
* Whether edge cases are correctly identified and handled in the
implementation and tests.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 17 Jan 2010 at 5:25

Allow caller to specify value for padding shorter of Zip sequences

I think it would be good to allow the caller to control what is being used
to pad the shorter collection if desired, rather than relying on
default(TResult).  Especially for numerics, where 0 may very well have a
meaning for the caller, other than "not there".

Since this would change the method signature, new method overrides would
probably be required.  These methods would probably have no need for a zip
strategy argument either.

Here is the method signature I would envision:
private static IEnumerable<TResult> ZipImpl<TFirst, TSecond, TResult>(
    IEnumerable<TFirst> first, 
    IEnumerable<TSecond> second, 
    Func<TFirst, TSecond, TResult> resultSelector,
    TFirst padFirst,
    TSecond padSecond)

Original issue reported on code.google.com by [email protected] on 16 Feb 2009 at 3:05

Review: MoreEnumerable.RandomSubset()

Purpose of code changes on this branch:

Rev 123: Implementation of the RandomSubset extension method which returns
a sequence of randomly selected elements from the original sequence. This
operator is deferred but it is NOT streaming. This operator performs a
random shuffle of the original elements, from which it then selects the
first N elements. As an optimization, only a partial shuffle is performed -
instead of a complete shuffle.

When reviewing my code changes, please focus on:

* The public interface of the extension method.
* The effectiveness and clarity of the available XML comment documentation.
* How well this operator fits into the MoreLINQ ecosystem of
extension methods.
* The extent of coverage available from the corresponding unit tests.
* Whether edge cases are correctly identified and handled in the
implementation and tests.
* The potential performance implications of the selected algorithm.

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 17 Jan 2010 at 5:31