commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jelle Herold <>
Subject Re: [math] matrix identity, matrix as transformation
Date Mon, 02 Mar 2009 14:25:22 GMT

thanks for taking time to answer this question.

On Mar 2, 2009, at 13:35, Luc Maisonobe wrote:
>> A question on extending commons-math.
>> I'm missing a couple of (basic) functions on the RealMatrix class;
>> for example,
>> void identity();    // set to identity matrix
> There is a MatrixUtil.createRealIdentityMatrix(int dimension) method.
> This method will also probably be rewritten some day when diagonal
> matrices (or at least band matrices) will be supported.

Ok, thanks. What about "in place" methods?

Setting a matrix (back) to identity is something very common.
I suppose it comes down to a balance between speed and simplicity of  
the API?

ps. It can easily be done with a visitor, this might be usefull?

  class SetIdentityVisitor extends DefaultRealMatrixChangingVisitor
	public double visit(int row, int column, double value)
			throws MatrixVisitorException
		if (row == column)
			return 1;
		return 0;

>> boolean isIdentity()    // check if this is an identity matrix
> This makes sense, with an epsilon threshold argument. For now, you  
> cando
> something like the following, but this is a clear memory hog since it
> creates two temporary matrices:
>  RealMatrix id =
>      MatrixUtil.createRealIdentityMatrix(m.getRowDimension());
>  return m.subtract(id).getNorm() < epsilon;

Alright, I suppose this can be done in a visitor as well, using less  

>> Also I'm using them as affine transformations, so I'd like to see  
>> generic
>> RealVector getTranslation()
>> void translate(RealVector v);
>> void setTranslation(RealVector v);
>> etc. (this works for arbitrary dimensions, matrix must be square  
>> though)
> I think I miss something obvious here.

Hm, it very well could be me :-)

> For me, generic translations are affine transforms, not vector
> transforms. They can be computed by additive vector operations, not by
> nxn matrix operations without extension. Do you intend to use the
> operate() method from RealMatrix with extended vectors (i.e. by
> appending a virtual +1 component after the n-components vector) and a
> (n+1)x(n+1) or nx(n+1) matrix as done in computer graphics ?

Yes. In the sense that I assume my vectors and matrices to be in that  
I'm not modifying anything (dimensions etc).

These methods above give/set/multiply the translation component of
the transformation. So for a 3x3 matrix getTranslation() would return
a 2 component vector representing with the x,y transformation, taken
from row 3, column 1 and 2.

(Or transposed: column 3, row 1 and 2, depending on how you represent
  your transforms)

The 3x3 matrix would operate on a 3 component vector, expecting it to be
(x,y,1) or (x,y,0) if needed, or otherwise.

>> So wrote a helper class that works on RealMatrix objects treating  
>> them
>> as transformations, but I'd prefer to have those methods directly on
>> RealMatrix.
>> (Extending RealMatrix is not practical as methods such as  
>> multiply(..)
>> don't return the derived class)
>> Better suggestions are welcome.
> I'm not sure I understood well, so cannot suggest anything yet.

So right now I work as follows (ignoring MatrixUtil for now)

// create a matrix for 2D transformations
RealMatrix t = new RealMatrixImpl(3,3);

// construct single transformation matrix from seperate operations
TransformHelper.scale(t, new RealVectorImpl(new double[] {2, 3}))
TransformHelper.translate(t, new RealVectorImpl(new double[] {10, 10}))

// operator on 3 component vector
t.operate( ... ) // a (x,y,0)

Ofcourse it would be nicer to be able to do

  t.scale(new RealVectorImpl(new double[] {2, 3}))

or maybe even with helper methods

  t.scale(new double[] {x, y}); or

Composing multiple transformations S, T into one matrix is then a matter
of S.multiply(T).

ps. here I'm missing in place operators a bit.

I cannot easily extend RealMatrix with these methods by subclassing  
(because the inherited
multiply then wouldn't get me a transform. Unless I also turn the  
Transformation class into
a decorator, which I don't really like).

So, then I figured this might be usefull standard methods?

Maybe I'm stretching the library here and probably I'm just  
complaining to much :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message