[Scilab-users] Empty matrix

Dang Ngoc Chan, Christophe Christophe.Dang at sidel.com
Tue Jun 5 11:17:46 CEST 2018


Hello,

Thanks to the discussion started by Samuel and the document provided by Rafael (de Boor 1990)
(see http://mailinglists.scilab.org/Scilab-users-Is-cond-0-or-1-bug-15579-td4037987.html )
I discovered this astonishing mathematical object: the empty matrix.

Our only use of this in Scilab is the validity of limit cases.
If we don't have to test the emptiness of a matrix,
it makes the life easier.

However, we also expect that the behavior of such matrices is consistent with the linear algebra.

========== Linear algebra of empty matrices ==========

So a few elements: let us consider a field K (usually K is ℝ or ℂ).
The zero vector space is K^0 = {0}.
This is the most trivial vector space, its dimension is 0 (geometrically it is a point).

Let us now consider E, a K-vector space of dimension n.
There is one unique linear map from E to K^0 which can be represented by the n × 0 empty matrix.
There is also a unique linear map from K^0 to E which can be represented by the 0 × n empty matrix.
And there is a unique linear map from K^0 to K^0 which is represented by the 0 × 0 empty matrix.

The product of the 0 × n matrix by a n × p matrix is the 0 × p empty matrix.
The product of a m × n matrix by the n × 0 matrix is the m × 0 empty matrix.
The product of the m × 0 matrix by the 0 × p matrix is the zeros(m, p) matrix.

So the product of two empty matrices is not always an empty matrix…

Additionally: the 0 × 0 empty matrix is Id0, the identity of K^0.
It is thus a regular matrix.
As the identity, it explains why det([]) = 1
and why some considere that cond([]) = 1 (as for any identity matrix) although it breaks the formula using the norms.

========== About Scilab ==========

Scilab consider only one empty matrix, the 0 × 0, denoted [].
The following features are correct:

sum([]) == 0 // identity element of addition

prod([]) == 1 // identity element of product, also convention for the empty product

inv([]) == []

[]^-1 == [] // but a warning message shows up

cond([]) == 1 // however this is imho more a matter of conventions and 0 is also correct

[]\[] == []

[]/[] == []

linsolve([], []) == []// but a warning message shows up

[]\[0] == []

[0]/[] == []

linsolve([], [0]) == []

The following features are obviously wrong and misleading:

det([]) == 0 // should be 1

linsolve([], [1 1]) == -1 // or can someone explain this result

The following features are algebraically wrong but are acceptable as rules to process special cases
such as a result of find(), e.g. find(a<b) with incidentally a = 1 and b = 0

A + [] == [] // the sum is an internal operation so it is only valid when A = []

A*[] == [] // not always, even not always defined, depends on the dimension of A, see above

[]\[1 1] == [] // only []\[] or []\zeros(n, 1) should be defined as the result of []*x can only be [] or zeros(n, 1)

[1 1]/[] == [] // same as above

========== What do I expect ? ==========

Not much (-: it is more a kind of state of the art, food for thoughts.

The two bugs det([]) == 0 and linsolve([], [1 1]) == -1 should be fixed.

I think it would be better if Scilab sticks with the linear algebra,
just because some teacher could say to their students "play a little bit with Scilab"
and you know where this kind of experiments can lead :-D
but I don't think it is important for the calculation.

However, checking the consistency of the dimensions for + and * is a good rule
and it should imho be done even when [] is involved
(unless people use intensively this feature for some obscure reasons).

However, note that Matlab consider three empty matrices:
[] (0 × 0), 0 × 1 and 1 × 0
the two later cannot be defined as such but can be easily obtained with
find(ones(2, 1) < zeros(2, 1))
and Matlab checks the dimension consistency for + and *.

Also note that R processes all the product with empty matrices correctly:
play a little bit with things like

M <- matrix(, nrow=2, ncol=0)

and the like.

Regards

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


More information about the users mailing list