DynamicAsInteger = 10000, ScalarReadCost = NumTraits<typename traits<T>::Scalar>::ReadCost, ScalarReadCostAsInteger = ScalarReadCost == Dynamic ? DynamicAsInteger : ScalarReadCost, CoeffReadCost = traits<T>::CoeffReadCost,
CoeffReadCostAsInteger = CoeffReadCost == Dynamic ? DynamicAsInteger : CoeffReadCost, NAsInteger = n == Dynamic ? int(DynamicAsInteger) : n, CostEvalAsInteger = (NAsInteger+1) * ScalarReadCostAsInteger + CoeffReadCostAsInteger, CostNoEvalAsInteger = NAsInteger * CoeffReadCostAsInteger
Determines how a given expression should be nested into another one. For example, when you do a * (b+c), Eigen will determine how the expression b+c should be nested into the bigger product expression. The choice is between nesting the expression b+c as-is, or evaluating that expression b+c into a temporary variable d, and nest d so that the resulting expression is a*d. Evaluating can be beneficial for example if every coefficient access in the resulting expression causes many coefficient accesses in the nested expressions -- as is the case with matrix product for example.
|T||the type of the expression being nested|
|n||the number of coefficient accesses in the nested expression for each coefficient access in the bigger expression.|
Example. Suppose that a, b, and c are of type Matrix3d. The user forms the expression a*(b+c). b+c is an expression "sum of matrices", which we will denote by S. In order to determine how to nest it, the Product expression uses: nested<S, 3>::ret, which turns out to be Matrix3d because the internal logic of nested determined that in this case it was better to evaluate the expression b+c into a temporary. On the other hand, since a is of type Matrix3d, the Product expression nests it as nested<Matrix3d, 3>::ret, which turns out to be const Matrix3d&, because the internal logic of nested determined that since a was already a matrix, there was no point in copying it into another matrix.