[Top][All Lists]

[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 16-Nov-2001, 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 "x-y 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

| 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.


Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]