Re: [eigen] On a flexible API for submatrices, slicing, indexing, masking, etc.

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Fri, Jan 6, 2017 at 11:46 PM, Yuanchen Zhu <yuanchen.zhu@xxxxxxxxxx> wrote:

Dude I don't know... This is a bit too fancy for me. So now A(3 * any_mat + 4) actually means A(1), A(4), A(7) ...?

To write A(seq(4, 10, 3)), you cannot just write A(4 + 3 * any_mat <= 10), but you need to write  A(4<= 4 + 3 * any_mat <= 10).

1 )I revised my essay: http://eigen.tuxfamily.org/index.php?title=Working_notes_-_Indexing%2B%2B#Variant_C:_expression-based_API

Hopefully it is more consistent now.

2) Note that the 'classic' seq function has some caveats too: http://eigen.tuxfamily.org/index.php?title=Working_notes_-_Indexing%2B%2B#Caveats

In short the 'first' and 'last' inclusive bounds are not always symmetric.

3) Before pushing too much towards fancy syntax, I would propose to push further the current seq/seqN paradigms my making them ArrayXi alike. This way we can seamlessly integrate the 'APL' approach and perhaps even cover some aspect of the filtering approach: http://eigen.tuxfamily.org/index.php?title=Working_notes_-_Indexing%2B%2B#Generalization

gael

 

 

And yes, a<=any_nat does not return a boolean or a vector of booleans, but once put using this new wording, how could it be?

gael

 

A(2*iota(5) ) // even numbers up to 8

A(3+2*iota(all-2) ) // 3,5,7,… up to N-2

A(all - iota(5) ) // N-1,N-2,..,N-5

...

where bound checking is meant to follow Eigen habits ( eg. hard error if compile time, assert on runtime )