[eigen] sub-matrix extensions

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Hi list,

I'd like your opinion about sub/super diagonal and an "every" expression API.

** sub/super diagonal expression **

I recently added sub/super diagonal expressions by extending diagonal
(like matlab). Example:

mat.diagonal<1>()  <=> 1st super diagonal
mat.diagonal<-2>()  <=> 2nd sub diagonal

Questions:

a) currently the sub/super diagonal index must be a compile time
integer. Do you think it is worth it to add support for runtime index
? (aka do you have a use case for that)
     Eg.: mat.diagonal(id)

b) Do you like the reuse of diagonal() with negative indices to
address sub-diagonals ? or would you prefer something more explicit
like:
     mat.superDiagonal<1>()
     mat.subDiagonal<2>()
     mat.subDiagonal(runtime_index)
   The advantage of the current solution is that you can use meta
programming to address either the 1st sub or super diagonal of a
lower/upper triangular matrix. So it is more flexible.


** "Every" expression **

Then there is the problem of accessing every elements, columns or rows
with a given stride. Proposal:

vec.every(2) => would return a reduced vector expression (half size)
with all even coefficients.

mat.every(2) => would "remove" all odd columns and rows

mat.colwise().every(2) => would return all even rows. Yes all even
rows and not even columns because colwise().every(2) has to be read as
"for each column call .every(2) on it". Just like all other
colwise()/rowwise() functions. Now I can understand that might be
confusing. This is why I'm asking here:
 a) is it really confusing for someone ?
 b) if yes, then any better naming idea to overcome the ambiguity ?
(eg.: mat.everyCols(2), mat.everyRows(2) ?)

Last questions:
 c) here I have a use case where runtime strides are needed, but do
you think we also need compile-time strides ? (probably yes)
 d) do you think bidirectional strides might be useful ? eg:
mat.stride(2,3) (picks the intersections of all even rows and k*3
columns)

For the implementation the "every" functions would probably simply
return assemblies of Map and Block expressions.

cheers,
Gael.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/