Hi,

probably there is a hard-coded limit on fixed-sized matrices.
But the error message (during compile) is strange.
And why is there a limit?
Many thanks for a hint,
Helmut.

#include
USING_PART_OF_NAMESPACE_EIGEN
const int BSz = BrettSize; // to be defined on the command line
typedef Matrix Brett_Typ;
Brett_Typ Free;

int main() {
Free= Brett_Typ::Ones(); // set all fields free
}

/*
g++ -g -DBrettSize=100 -I /usr/local/include EigenBug.C
/usr/local/include/Eigen/src/Core/CwiseNullaryOp.h: In static member function 'static const typename Eigen::MatrixBase::ConstantReturnType Eigen::MatrixBase::Constant(const typename Eigen::ei_traits::Scalar&) [with Derived = Eigen::Matrix]':
/usr/local/include/Eigen/src/Core/CwiseNullaryOp.h:419: instantiated from 'static const typename Eigen::MatrixBase::ConstantReturnType Eigen::MatrixBase::Ones() [with Derived = Eigen::Matrix]'
EigenBug.C:8: instantiated from here
/usr/local/include/Eigen/src/Core/CwiseNullaryOp.h:226: error: 'YOU_CALLED_A_FIXED_SIZE_METHOD_ON_A_DYNAMIC_SIZE_MATRIX_OR_VECTOR' is not a member of 'Eigen::ei_static_assert'
*/

The real problem description is this:
YOU_CALLED_A_FIXED_SIZE_METHOD_ON_A_DYNAMIC_SIZE_MATRIX_OR_VECTOR
And you indeed do in your call to Ones(). Brett_Typ is a dynamically sized matrix, so you have to call

Free= Brett_Typ::Ones(BSz, BSz);

Andre wrote:The real problem description is this:
YOU_CALLED_A_FIXED_SIZE_METHOD_ON_A_DYNAMIC_SIZE_MATRIX_OR_VECTOR
And you indeed do in your call to Ones(). Brett_Typ is a dynamically sized matrix, so you have to call

Free= Brett_Typ::Ones(BSz, BSz);

Why?

For BrettSize up to 99 it works just fine.
It looks as if Eigen switches to dynamic type automatically.?

HWJ wrote:Hi,

probably there is a hard-coded limit on fixed-sized matrices.

No, there is no hard-coded limit. But your email is kind of a proof that there should be...

What happens is that you just hit a new bug in Eigen. Let me explain.

The special value 'Dynamic' is set to 10000. So when you have a 100X100 matrix that's size 10000 which was confused for Dynamic.

So either we enforce a hardcoded limit on the total number of coefficients. Or we have to change the value of Dynamic.

The fix (it breaks the ABI, but anyway we are considering breaking the ABI for another reason, hopefully we can preserve the ABI after the 2.1 release) is just to set Dynamic to be a prime number, so that this kind of problem will virtually never happen. Or at the very least, 10000 was a bad choice because it is a square, 100^2.

It's already been discussed why not set Dynamic=-1. We could do that. So far, we didn't, because that forces a _lot_ of code to be more complicated, and code that looks correct and innocent can easily fail if Dynamic is not a large positive value. On the other hand, we cannot set Dynamic = MAX_INT because we need to be able to compute products without integer overflow, so the biggest possible value is sqrt(MAX_INT). That was the rationale for 10000...

On >=32bit systems, sqrt(MAX_INT) >= 46340.

We also want a number that's easily recognizable in error messages.

So the following primes are good candidates:
10009
33331
44449

This should be fixed in trunk now.