## 2243 Reputation

19 years, 212 days

## Addition of matrix and scalar...

The following code

restart:
A := Matrix(2,(i,j) -> a||i||j):
A + 1;
A + a;

produces the following output:

Why does Maple accept these additions, which mathematically are nonsensical? And why, if accepting these mathematically, does Maple not evaluate them analogously by putting the scalars either inside or outside the matrix in both cases?

## Direct sum of matrices...

Perhaps I am being blind, but I cannot locate a function for performing the direct sum of two (or more, for that matter) matrices, i.e., constructing a new matrix with the two (or more) matrices arranged block-diagonally.

Such a function should, I guess, naturally accompany the function KroneckerProduct in the LinearAlgebra package, because direct products (Kronecker products) of representations (i.e., matrrix-valued realizations of some abstract algebra) are, as is well-known, generally reducible into a direct sum of irreducible subrepresentations.

## Zero vectors and matrices...

Why does the act of multiplying a vector or a matrix with zero produce not a zero vector or a zero matrix, but in both cases zero scalarly? An example:

Vector(4),
Matrix(4),
0*Vector(4),
0*Matrix(4);

Mathematically it makes no proper sense, and annoyingly it forces one to make some special code-adjustments to treat differently nonzero- and zero multiplication.

Important (note added): The problem is present only when the Physics package is loaded, see comment below.

## Conjugation of products of Grassmannians...

Complex conjugation of a product of Grassmannians is defined to reverse the order of the multiplicands (while also complex conjugating each multiplicand by itself, of course). That does not seem to be implemented in the Physics package: The code

with(Physics):
Setup(
mathematicalnotation = true,
anticommutativepre   = theta
):
a := theta1*theta2;
b := conjugate(a);
c := evalc(b);

produces for a, b, and c the following results:

In b and c, the order of the multiplicands should be the reverse, or, equivalently, the signs of b and c should be the opposite. Is it due to an error, or due to not being implemented yet, or have I simply misunderstood something?

The following code of mine, which no doubt may be improved, performs this generalized conjugation (note that reversing a product of c-number-valued, i.e., commutative, quantities is, of course, inconsequential, and thus usual complex conjugation is maintained):

Conj := proc(x::algebraic)
local expr;
expr := expand(x);
if   type(expr,`+`) then map(Conj,expr)
elif type(expr,`*`) then `*`(ListTools:-Reverse(map(Conj,[op(expr)]))[]);
else conjugate(expr)
end if
end proc:

## Grassmannians in the Physics package...

In order to get a little acquainted with the Grassmannian capabilities of the Physics package, I presently consider the following simple setup:

with(Physics):
Setup(
mathematicalnotation = true,
anticommutativepre   = theta
):
A := Matrix(2,(i,j) -> theta||i||j);
B := A . A;
C := Expand(B);

producing for A, B, and C the following results:

To me the [2,2]-entry of B seems erroneous: the first addend has the wrong ordering of the theta's, or, equivalently, the wrong sign. Not so surprisingly, this error is then present also in the [2,2]-entry of C. But in C, the [1,2]- and [2,1]-entries seem erroneous as well: the sign of theta11 in the [1,2]-entry is wrong, and so, too, is the sign of theta22 in the [2,1]-entry.

Have I fundamentally misunderstood something?

 First 8 9 10 11 12 Page 10 of 12
﻿