ufl team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/4/7, Pearu Peterson <pearu@xxxxxxxxx>:
> Martin Sandve Alnæs wrote:
>
>  > That's one of the trivial examples in my previous email. A*B and A*v
>  > work out fine, but v*A and u*v would be invalid products in
>  > Matlab/linear algebra notation. If you write (with tensors) "u v", it
>  > (often, usually, always?) means outer(u, v). Translating from linear
>  > algebra notation to UFL tensor notation, "u v" is invalid, "u^T v" is
>  > dot(u,v) and "u v^T" is outer(u, v).
>  >
>  > "Paper notation" contains a lot of special cases that doesn't
>  > generalize, and would lead to a tangled mess of code. That's why we
>  > must make our own precise definitions, that are always well defined
>  > and translates well to code. And since we're dealing with tensor
>  > algebra, we must use tensor algebra as our basis and not linear
>  > algebra where they differ.
>
>
> FYI, in sympycore we have the same problem with matrices
>  and there we have resolved it as follows (for details see
>  http://code.google.com/p/sympycore/wiki/MatrixSupportIdeas):
>
>  0) currently vectors are represented as 1-column matrices
>  1) by default, `A * B` is matrix product.
>  2) matrices have attributes .A, .T, etc (`.T` would be `^T` in your
>  case) that return "array", "transpose", etc *views* of matrices
>  and these views define what kind of multiplication will be used.
>
>  For example, `A.A * B` would be equivalent to elementwise multiplication
>  of matrices. `A.T * B` would be dot product of matrices.
>  Outer products could be modelled as `A.O * B`, for instance.
>
>  Regards,
>
> Pearu

I've already implemented A.T the same way. But I think f.ex. outer(A,
B) is clearer than A.O*B, and "A.O" in itself doesn't make sense to
me. Also, I've done inv(A) instead of A.I.

A.A*B we would currently have to do with manual loops, but I'm not
sure we need it.

--
Martin