Some combinatorics?

[bearophile]

dsimcha:

> I need this often enough
> that I'd be interested in having them in Phobos.

Good.


> Some code by Philippe Sigaud does it better than my implementations
> (http://svn.dsource.org/projects/dranges/trunk/dranges/docs/algorithm.html) and is
> Boost licensed.  He was thinking of getting parts of this lib into Phobos, but I
> don't know what the status of that is.  If this project is abandoned and you like
> it, you could take it over, or you could just write your own.

I will take a look at the code. In the meantime some comments:
- frequency, scan, flatMap, subranges, separate: good;
- tmap: this is the default semantics map should have, in my opinion;
- unfold: nice, but maybe a bit too much hard to understand for nonfunctional programmers;
- comp, setComp: I'd like a built in syntax instead of this. In my dlibs1 I have select() that has a different syntax;
- select: I am not sure, maybe this is this better in the array module;
- first, second: maybe good, but I suggest to add a leading "s" to their names;
- combinations: good, but the name has to change;
- permutations: I prefer my version;
- choose: good, but with name change;
- consumer: too much complex to use;

This stuff is good to have in Phobos. But I was thinking about some more combinatorics.


> One important issue is whether the number of elements for a combination should be
> specified at compile time (more efficient), runtime (more flexible) or both
> (possibly bloated).

The runtime version is needed. The compile time is surely a different version, and it's probably less needed. So I suggest to add the runtime version only, and then add the compile time version later if needed.


> As far as where these should go, I'd say either std.range or a module publicly
> imported by std.range.  They deal with range topology.

Most of those things from dranges are fit in std.range (or std.algorithm?), or a little module that they publicly import, as you say. But if enough combinatorics stuff is added, then maybe a std.combinatorics module will be better.

If Andrei is OK with this then I will probably create a patch for std.range.

See you later,
bearophile