[eigen] block of dense-block should again be block |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: [eigen] block of dense-block should again be block
- From: Manoj Rajagopalan <rmanoj@xxxxxxxxx>
- Date: Sun, 27 Jun 2010 10:06:53 -0400
- Organization: EECS Dept., University of Michigan, Ann Arbor, MI, USA
Hi,
I have a dense matrix(expression). When I create a block out of it and
another block out of this block, I should get an object of type
Block<some-DenseBase-derivative>. Currently, I get
Block<Block<some-DenseBase-derivative> >. Studying the code, this is the
natural way to cover all cases but can the block-of-block-of-X be collapsed
to just block-of-X when X is dense? AFAIK this should also apply to all X
besides dense (please correct me).
I found this out the hard way. the block-of-block is not obvious till a user
reads the code - I kept assigning this to a simple block as follows
MatrixXcd X;
Block<MatrixXcd> const X_block = X.block().block();
and I kept getting seg-faults because X_block has a new return value for
data() when compared to X (I found this out in the debugger). Correct code
should look like,
Block<Block<MatrixXcd> > const X_block_block = X.block().block();
I previously used Boost::UBLAS where they had free subrange() and project()
functions which were associative in the above sense. This associativity would
be a nice addition to Eigen3.
If the associativity (endomorphism on the space of data-types, actually)
holds for all types X, then can a member function be introduced into class
Block that solves this problem? I thought I would try this and send a patch
but I am not sure the endomorphism will hold for all expression types X that
Block<> could apply to.
As a user I suggest that the documentation should warn users about this
case if this feature is not implemented.
Thanks,
Manoj