[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3D array
From: 
John W. Eaton 
Subject: 
Re: 3D array 
Date: 
Fri, 16 Nov 2001 10:51:20 0600 
On 16Nov2001, Paul Kienzle <address@hidden> wrote:
 What I have seen of matlab's nD array processing is that it is inconvenient
 at best. The linear algebra functions all expect matrices, so having grabbed
 a slice you must collapse it to a matrix before operating on it.
It seems that this is only needed in some cases. For example, I see
that for
a = rand (3, 3, 3);
the expression
svd (a(:,:,1))
produces a result, but
svd (a(1,:,:))
doesn't. So it seems that considering the result to be a matrix works
if the slice is in the "xy plane" of the Nd object. I don't see this
as necessarily bad.
 Since it is now a matrix, you cannot plug the result of the slice
 back into your nD array until
 you expand it again.
I don't think this is necessarily a problem, as long as it is
consistent. You simply need to remember that the orientation must
match in order to perform an indexed assignment. That makes sense to
me.
 Curiously,

 A = [ 1 2 ; 3 4 ; 5 6]
 A(:,2) = [1 2 3] % this gives an error
 A(:,2) = [1 2 3]' % this doesn't
 A(:,2,1) = [1 2 3] % neither does this
I agree with the behavior of the first two indexed assignments, but
not the last, since that should still not conform.
 The only time we care about row and column vectors is in distinguishing inner
 and outer product, and the rest of the time the distinction just gets in the
 way.
Sorry, I have to disagree. Since there is no way to distinguish
between a matrix which happens to have one row from a row vector, I
think you can cause trouble if you design the system to not care about
orientation. For example, suppose you have a 5x5 matrix A. Then
a(n,:) = ones (5, length (n));
works as long as n is a scalar, but suddenly fails if the index N
becomes a vector. That seems bad to me. Better to require the user
to think about the orientation of the matrix from the start, I think.
 Using dot(x,y) for inner product and * for outer product would suit
 me fine since it would make it far more obvious what is being
 computed.
If it matters, there's nothing preventing you from defining dot() (or
inner_product()) and outer_product() functions for your projects.
jwe

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.org
How to fund new projects: http://www.octave.org/funding.html
Subscription information: http://www.octave.org/archive.html

 3D array, Laurent Jacques, 2001/11/13
 RE: 3D array, Ted Harding, 2001/11/13
 RE: 3D array, John W. Eaton, 2001/11/13
 RE: 3D array, adler, 2001/11/13
 RE: 3D array, John W. Eaton, 2001/11/13
 RE: 3D array, adler, 2001/11/15
 Re: 3D array, Paul Kienzle, 2001/11/16
 Re: 3D array,
John W. Eaton <=
 Re: 3D array, Laurent Jacques, 2001/11/14
 Re: 3D array, Laurent Jacques, 2001/11/14