RangeExtra

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> > Reindex:  Takes a zero-indexed random access range and converts it to a range
> > with an arbitrary base index.  Useful for one-indexed arrays to fit
> > mathematical notation conventions, etc.
> Hm. I'd take the opportunity to actually reindex the range in an
> arbitrary way, e.g. by computing a separate index for it and using it
> transparently. I see little utility in just changing base (I tried such
> based_vector code for C++ and it created more confusion than it removed.)

So it would take something like a lambda function as a template alias parameter to
map an index in whatever space you want onto normal zero-indexing?  This sounds
like a very good idea:

Array with only even indices:

uint[] foo = [0,2,4,6,8,10];
auto bar = reindex!("assert(a & 1 == 0); a / 2")(foo);
assert(bar[2] == 2);
assert(bar[10] == 10);

One-indexing:

foo = [1,2,3,4,5];
auto baz = reindex!("a - 1")(foo);
assert(foo[1] == 1);
assert(foo[5] == 5);

Array indexed by powers of two:

foo = [1,2,4,8,16,32,64];
auto pow2 = reindex!((a) { return cast(size_t) log2(a); })(foo);
assert(foo[32] == 32);
assert(foo[4] == 4);

> > Joint:  Kind of like std.range.Zip, but returns a tuple of values of the
> > elements in the underlying ranges instead of a proxy of pointers to the
> > elements of the underlying range.  Zip is great for what it's designed for,
> > but sometimes the pointer/reference semantics are problematic.
> Joint is a risque name

This idea grew out of dstats.infotheory and joint probability distributions.

> > Rotated:  Gives a rotated view of a random access range without modifying the
> > underlying range.  Also has a put() method.  Given an underlying range of
> > length L, this provides an efficient way to remember the last L elements seen
> > by the range:
> I think that's very related to Cycle.
> http://www.digitalmars.com/d/2.0/phobos/std_range.html#Cycle
> Keep the great ideas coming!


True, I didn't see the index parameter in cycle when I initially looked at it.
This one could go either way.  On the one hand, avoiding bloat and having a few
very general primitives is usually a good thing.  On the other hand, if you use
cycle and take, you're implementing someting fairly simple on top of something
much more complex, and you can't have the put() function that makes the range
track the last L items written to it  in order with O(1) put() calls, only one
memory allocation over the object's lifetime and minimal space overhead, which was
my original motivation for Rotate.