12
$\begingroup$

Dot is not "well-defined" in Mathematica - we cannot simultaneously have it being associative and working with 1D and 2D arrays. For example, the order we substitute for variables should not change the result.

a.b.c /. b -> {1, 2} /. c -> {1, 3} /. a -> IdentityMatrix[2]
(* {{1, 0}, {0, 1}}.7 *)

a.b.c /. b -> {1, 2} /. a -> IdentityMatrix[2] /. c -> {1, 3}
(* 7 *)

This example is a little artificial. Can we construct other examples that might cause more significant problems?

| improve this question | |
$\endgroup$
  • 6
    $\begingroup$ I suggest to make your code much simpler to illustrate your point, like this: a=IdentityMatrix[2];b={1,2};c={3,4}; and now compare a.(b.c) vs. (a.b).c This just makes it easier to see. No need for all the With code :) $\endgroup$ – Nasser Jun 15 '17 at 22:52
  • 2
    $\begingroup$ Why move from "not associative" to "not well-defined"? And it will be associative if you only work with matrices (including symbols whose values are matrices). $\endgroup$ – Alan Jun 15 '17 at 23:58
  • 4
    $\begingroup$ I've found that in general best to not use 1D lists as vectors, for the sort of reasons you bring up. Been burned badly by this. Now I make all vectors either Nx1 matrices, or 1xN, as per the math. Like Matlab does. Then all the proper rules of working with matrices are enforced. $\endgroup$ – MikeY Jun 16 '17 at 3:02
  • 1
    $\begingroup$ I agree that current behavior of Dot is inconsistent. As an inner product defined in details section of documentation it's not associative when rank of "middle" tensor is lower than 2. I'd even go as far as calling this a bug. Dot might be better without Flat attribute and with consistent left-associative (or right-associative) evaluation in case of more than 2 arguments involving explicit rank 1 tensors. But given that Dot worked this way for a long time, I guess WRI will call it a feature not a bug. $\endgroup$ – jkuczm Jun 18 '17 at 16:01
  • 1
    $\begingroup$ If by "artificial" you mean that first example gives suspicious dot product of matrix and scalar, then it's easy to find results that will have same structure, so are less suspicious. E.g. a = {{0, 1}, {2, 3}}; v = {4, 5}; b = {{6, 7}, {8, 9}}; a.(v.b) (* {73, 347} *) vs ClearAll[a, b, v]; a.(v.b) /. {a -> {{0, 1}, {2, 3}}, v -> {4, 5}, b -> {{6, 7}, {8, 9}}} (* {214, 242} *), they both give 2-element vectors. $\endgroup$ – jkuczm Jun 21 '17 at 10:09
10
$\begingroup$

Recently I was surprised when I encountered the following quote from the Mathematica docs:

The Wolfram Language represents vectors as lists, and never needs to distinguish between row and column cases.

(http://reference.wolfram.com/language/guide/OperationsOnVectors.html)

I find this statement somewhat misleading and here is why.

The usual matrix multiplication clearly distinguishes between row and column vectors, because:

$ \left( \begin{array}{cc} 1 & 2 \end{array} \right) \cdot \left( \begin{array}{c} 1 \\ 3 \\ \end{array} \right) = (7), \qquad $ but $ \qquad \left( \begin{array}{c} 1 \\ 2 \\ \end{array} \right) \cdot \left( \begin{array}{cc} 1 & 3 \end{array} \right) = \left( \begin{array}{cc} 1 & 3 \\ 2 & 6 \end{array} \right) $

To write a general matrix multiplication in Mathematica we use Dot:

b.c

If b and c are vectors we may need to specify which vector is column and which is row. I.e. depending on dimensions of b and c we should write either:

 b.c  /. b -> {{1}, {2}} /. c -> {{1, 3}}

{{1, 3}, {2, 6}}

or

 b.c  /. b -> {{1, 2}} /. c -> {{1}, {3}}

{{7}}

If we just use lists we will always get a scalar product

 b.c  /. b -> {1, 2} /. c -> {1, 3}

7

In your example we can explicitly define row and column vectors to avoid the problems:

a.b.c /. b -> {{1},{2}} /. c -> {{1, 3}} /. a -> IdentityMatrix[2]

{{1, 3}, {2, 6}}

a.b.c /. b -> {{1}, {2}} /. a -> IdentityMatrix[2] /. c -> {{1, 3}}

{{1, 3}, {2, 6}}

One can argue that Outer can be used instead. For this simple case I agree, but in other cases it is not always clear where matrix multiplication reduces to an outer product. Thus, for problems with large number of matrix multiplications it may be better to define vectors as $1 \times n$ and $n \times 1$ matrices to avoid any ambiguities.

| improve this answer | |
$\endgroup$
  • 3
    $\begingroup$ Another related problem is that linear algebra code using Transpose doesn't generalize properly when you construct it assuming that row and column vectors may be represented by one dimensional lists. $\endgroup$ – John Doty Jun 16 '17 at 22:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.