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

On Wed, Jan 4, 2017 at 7:21 PM, Yuanchen Zhu <yuanchen.zhu@xxxxxxxxx> wrote:

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

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

std::fixed is completely different (not a function, completely different semantic and context), so I don't think that's a concern.

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

Sure, you need to look up the doc at least once.

Regarding fix<N>, I think that 3 characters is short enough to not make too distracting, though using a transitive verb here is a bit borderline.

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.

Using negative indices to index from the end is not an option for us, for at three reasons:

1) in python your saved because you can (and sometimes have too) omit the bounds. You provided one example, another simpler one with incr==1 is to get the last k elements in ascending order, you have to write: A[-k:], you cannot write: A[-k:-1+1],though in python -1 means last. In contrast, A[-k:last+1] would be fine.

2) we need to known this information at compile-time, we don't want to branch at runtime!

3) outside the indexing context, qseq(-4,-1)==[-4,-3,-2,-1] is what we want.

But then again, aseq cannot stand on its own if we allow the "last" literal: what exactly is aseq(0, last)?

same for matlab colon syntax, compilation error. Negative indices, rev(), or whatever else won't save you here.

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)?

not an option.

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)));

not as flexible/extensible as last, for instance with some work we could allow last/2

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]

rseq is too confusing regarding parameter orders, on the other hand, reverse( aseq(i,j) ) would be fine, and we already have a reverse _expression_ in Eigen.

Also recall that indexing from the end and negative increment are orthogonal, so we have to consider all 4 cases.

gael

gael