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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Thu, Jan 5, 2017 at 4:33 PM, Massimiliano Janes <max.jns@xxxxxxxxx> wrote:

Regarding your example, it actually boils down to:

A( 5 <= iota*2+1 <= 9 ) // all odd numbers between 5 and 9 inclusive

I know ( I was an APL fan when I was younger … :) ), they do define the same progression, but IMO they are not quite equivalent

from a coding point of view; for example, let’s say you start from an _expression_ like

A( 5 <= iota <= 9 )

and later on you want to add some further constraints in the least error prone way … this is what I meant by composable.

Yes, writing _expression_ templates to automatically parse it in some kind of primitive/optimal progression may be tricky

,but not impossible, unless I’m missing something.

ok, fair enough. Regarding the implementation, if you don't go too fancy, then yes you could do something, but if you take the intersection of too sequences one with incr==2 and the other with incr==4, you need to know them at compile-time plus that the difference in the starting points is a multiple of 4 (at compile-time) to be able to construct an arithmetic sequence...

 

The thing I mostly hate about python-range-like gymnastics is that they’re easy to write but so error prone to read and modify,

probably because they focus on the how rather than the what.

this only works with literals, does not work with, e.g.,  template<int Dim> .... then pass Dim as compile-time

I see, yet I see no harm in using a completely different syntax in that case, isn’t it ?

sure, in c++14 one can also write 13_c after a "using namespace boost::hana::literals"

gael