The logic for determing static/dynamic f-block size in
DetectStructure was broken in a corner case, where the very first
row block which was used to initialize the f_block_size contained
more than one f blocks of varying sizes. The way the if block
was structured, no iteration was performed on the remaining
f-blocks and the loop failed to detect that the f-block size
was actually changing.
If in the remaining row blocks, there were no row blocks
with varying f-block sizes, the function will erroneously
return a static f-block size.
Thanks to Johannes Schonberger for providing a reproduction for this
rather tricky corner case.
Change-Id: Ib442a041d8b7efd29f9653be6a11a69d0eccd1ec
The schur eliminator treats rows with e blocks and row with
no e blocks separately. The template specialization logic only
applies to the rows with e blocks.
So, in cases where the rows with e-blocks have a fixed size f-block
but the rows without e-blocks have f-blocks of varying sizes,
DetectStructure will return a static f-block size, but we need to be
careful that we do not blindly use that static f-block size everywhere.
This patch fixes a bug where such care was not being taken, where
it was assumed that the static f-block size could be assumed for all
f-block sizes.
A new test is added, which triggers an exception in debug mode. In
release mode this error does not present itself, due to a peculiarity
of the way Eigen works.
Thanks to Werner Trobin for reporting this bug.
Change-Id: I8ae7aabf8eed8c3f9cf74b6c74d632ba44f82581
Since Ceres is moving to using GitHub for issues, and the Google
Code URL in the current copyright header will soon become invalid,
update all the headers.
Change-Id: I1fce70375d1bcf098591f07b4d8f01a5c1e0789c
Sameer Agarwal