Re: [eigen] Recursion and block matrices

[ Thread Index | Date Index | More Archives ]

Thanks for the good tips. I have found that Ref is not working for me with Array (at least, not as well as it works with Matrix). Perhaps, the current devel has not caught up on the
Array side?  Here is source code to illustrate the problem:

#include <Eigen/Core>
using namespace Eigen;

//typedef ArrayXXi D;
typedef MatrixXi D;

int main( int argc, char* argv[] )
  D exponents( 3, 4 );

  Ref< D > e1 =
    exponents.bottomLeftCorner( exponents.rows() - 1,
exponents.cols() );

  e1(0,0) = 3; // Avoid "unused variable" warning.

  return 0;
}// main

This compiles as is, but changing the typedef to the Array one, gives the error:

error: conversion from ‘
Eigen::Block<Eigen::Array<int, -1, -1>, -1, -1, false, true>
’ to non-scalar type ‘
Eigen::Ref<Eigen::Array<int, -1, -1> >
’ requested

Thank you,

On 09/21/2012 11:01 AM, Christoph Hertzberg wrote:
On 21.09.2012 19:05, Norman Goldstein wrote:
-- What was it about the Eigen class designs that made it convenient to
restrict Ref to innerStride==1?
Would it be a major development to remove this restriction? (convenient
for transposing and even/odd

It's only much more efficient at runtime. If you don't mind that, you can allow dynamic inner stride this way:
    Ref<MatrixXf,0,Stride<> >

Read this for details:

I'm not sure if the current implementation would allow passing a transposed matrix to that yet (I guess not).

-- Is there a signature for incr() that would allow me to pass in the
MatrixXd directly, without first
converting it to a Ref in main():
   Ref< MatrixXd > sub( mat );
   incr( sub );

void incr( Ref< MatrixXd > matV );

and in C++11 it should also be possible to use an l-value reference:
void incr( Ref< MatrixXd >&& matV )

-- Are the two expressions
   Ref< MatrixXd > sub = mat;
   Ref< MatrixXd > sub( mat );
supposed to be equavalent?  I think that a compiler is allowed to
interpret the
first one as a default constructor followed by an assignment operator.

No, for a class A
    A a = b; // not allowed if constructor is explicit ...
    A a(b);
call the constructor, and
    A a; a = b;
calls the default constructor and then the assignment operator.
Ref does not have a default constructor so the second interpretation would not even be possible. Of course, there is (almost?) always a rule that the compiler can interpret things differently, if the outcome is the same.


Mail converted by MHonArc 2.6.19+