Re: [eigen] On a flexible API for submatrices, slicing, indexing, maskin

This and the shorter "Fix" are both nice. I still prefer the all lower case version though, since it's a function and there's no name collision.

yes, my favorites so far are: ic<N>, fix<N>, fixed<N>

There is a std::fixed, so fixed<N> is probably not good.

I personally find ic<N> too obscure. I would never be able to guess its meaning.

I also find aseq slightly more obscure than just seq, though its meaning is pretty clear once explained. I wonder what other people think of aseq vs seq.

I also want to revisit the ordering of first, last, and the (optional) incr parameters. We have these existing conventions:

- Matlab/Julia: (first, [incr,] last)
- Numpy: (first, end [, incr]), and also indices can be negative numbers

As you can see, it matches neither.

the first,last[,incr] convention is not new:

- Fortran,
- S-Lang,
- Mathematica
- boost::irange
- R: seq()
- Swift: stride()
- and probably more

I think the question is not if the convention is new, but if people familiar with the particular convention are likely to use Eigen for the same kind of work (i.e., scientific computing and HPC on PC?). So from the list above, only Fortran really counts maybe? That's why I was wondering if, realistically speaking, a lot of F90 users will look at Eigen as an alternative.

I fail to see a good reason why we shouldn't just adopt Matlab's convention of (first, incr, last), similar to libigl's colon(), so that there's one few set of convention to remember.

A strong argument is that in C++ optional parameters usually go last. Moreover, we also need to be consistant between the two variants, and aseqn(first,incr,size) would be really new, whereas many functions/language follows the (first,size,incr) order.

Okay that's a fair point.

Martlab aficionados are still free to declare "auto colon(first,incr,last) { return aseq(first,last,incr)); }", and done.

BTW, regarding inclusive vs exclusive upper bound, python's users seem to have several arguments, all grounded on the zero-based indexing thing: http://stackoverflow.com/questions/11364533/why-are-slice-and-range-upper-bound-exclusive.

I think half-open interval is very reasonable and conceptually clean with positive strides, but can get confusing with negative strides. For example, to express (n-1, ..., 0), aseq(n-1, -1, -1) looks really strange. With python you cannot even write A[n-1:-1:-1] since -1 is interpreted as n-1, so you write A[n-1::-1] instead, which does not fly with the notion of aseq defining a vector by itself. But then again, aseq cannot stand on its own if we allow the "last" literal: what exactly is aseq(0, last)?

At this point of discussion, maybe we need to think more carefully about handling indexing relative to end. Here're some not very well-thought out ideas:

1. Have a "last" literal, and overload the shit out of its relevant arithmetic. This is a lot of work, and breaks as soon as an unsuspecting user invokes a function on "last".. This is in the wiki.

2. Allow negative indices like python, so all indices are understood to be (mod size)?

3. Similar to 2, but use a special "rev" mark to indicate the an index is taken with respect to end, e.g., A(aseq(0, rev(0))); A(aseq(0, rev(some complex computation)));

4: Differentiate between a forward aseq and backward aseq, i.e., A(seq(0, n-1)) gives A[0, ..., n-1], and A(rseq(n-1, 0)) gives A[n-1, ... 0]

(3) is a bit like (1). Since rev(i) is just (last - i), but you avoid doing calculation on last.

(4) is a bit like STL's begin()/end() and rbegin()/rend(). Note that we can define the half-interval rule so seq(a,b) is [a, b) and rseq(a, b) is [b, a).

gael