Re: Scalars and Matrices:

[Ted Harding]

On 13-Oct-99 A. Scottedward Hodel wrote:
> 
> Sorry; I forwarded the article without fixing mangled spacing.  The
> values are:
> A = [1,  1 ];     # 1 x 2 row vector
> B = [1 ; 1];      # 2 x 1 column vector
> C = [1 ; 2 ; 3];  # 3 x 1 column vector; could be any length, as long
> as its
>                   # a column
> this_works    = (A*B)*C;
> this_does_too = A*B*C;
> this_fails    = A*(B*C);
> 
> With scalar = 1x1 matrix, (A*B)*C is defined, but A*(B*C) is not.  It's
> an annoying detail that the order of operations not only changes flop
> counts, but even whether or not a result is defined.

Sorry, I don't think I can sympathise with this. As a general convention
for associativity,

  A*B*C = (A*B)*C

provided this makes sense (as it does here). Likewise, so does

  C*A*B = (C*A)*B

(and gives the same answer, as it happens, as C*(A*B), i.e. post-
multiplying by the scalar A*B).

If, in attempting to evaluate A*B*C as (A*B)*C, the latter doesn't make
sense then (please correct me if I'm wrong) the attempt should fail.

Except in the scalar case, the matrix product of a chain of factors
only makes sense if the columns of each factor match the rows of the next.

You could plead that C * A * B * C' made sense on the grounds that (A*B)
is a scalar; but it would never arise in that form in the course of
an algebraic derivation and therefore I can't see why you would need to
use that form in a program.

The alternative to sticking to the associative convention would be that
whenever you have an expression (like C*A*B*C') which doesn't make sense
according to the convention, the software could work through it trying to
find things you can stick together, forcing assocation by parentheses, so
that the result does make sense (e.g. C*(A*B)*C' above). But, since
this could lead to ambiguities, I don't think you would want the software
to do that either.

In summary: in my view, the question A. Scottedward Hodel raises is
already resolved by the associativity convention. If that leads to
nonsense, then reformulate the problem.

Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Date: 13-Oct-99                                       Time: 15:03:26
------------------------------ XFMail ------------------------------



---------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.  To ensure
that development continues, see www.che.wisc.edu/octave/giftform.html
Instructions for unsubscribing: www.che.wisc.edu/octave/archive.html
---------------------------------------------------------------------