[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: problem with column specification in matrices
From: 
John W. Eaton 
Subject: 
RE: problem with column specification in matrices 
Date: 
Thu, 31 Oct 2002 14:07:56 0600 
On 31Oct2002, Julian DeMarchi <address@hidden> wrote:
 And on that note, Matlab yields

 >> [ linspace (1, 2) ]
 ??? [ linspace (1, 2) ]
 
 Error: ")" expected, "," found.

 It does not like the space between function name linspace and argument list
(1, 2).
Try
[ eye (2) ]
instead. You might expect a 2x2 identity matrix, but I think you will get
[1, 2]
The problem is that Matlab is trying to decide where to break up the
expression into matrix elements, and it is not necessarily doing what
you expect. It seems to work fine for binary operators like +, , *,
etc. So if you have
[ 2  1 ] ==>  is binary op, result is 1
[ 2 1 ] ==>  is binary op, result is 1
[ 2 1 ] ==>  is unary op, result is [2, 1]
this automagic stuff seems great (though I would argue that it only
seems that way, and you'd be better off without it). But when you
have
[ x (y) ]
it is a little easier to be confused. Should that expression in
parens stand on its own, or should it be interpreted as the index for
x? (Or function arguments if x is a function, of course, but that
brings up the problem of matrix/vector indexing and function call
arguments using the same syntax when they probably shouldn't, but I
don't feel like doing that rant today.)
Matlab says that [ x (y) ] should be interpreted as if you had typed
[ x, (y) ], so in your linspace example, you have the equivalent of
[ linspace, (1, 2) ]
which is a syntax error because "(1" and "(1, 2)" are both invalid
expressions in Matlab.
 However,

 [n (1+1./n).^n]

 and

 [n, (1+1./n).^n]

 both yield identical results (space treated as comma).
But not in Octave, unless you have whitespace_in_literal_matrix set to
"traditional". Without that, Octave looks ahead to the "(" and
decides that it should keep grabbing more text until the expression is
complete. So it sees
n (1+1./n).^n
as a single expression, instead of two separate expressions
n
and
(1+1./n).^n
Does that make sense?
Why should whitespace be an expression separator (sometimes) in this
context?
FWIW, the builtin variables like whitespace_in_literal_matrix were
also bad ideas, because they can cause more trouble than they solve.
At this point, I'd be happy to get rid of this variable an always have
the Matlab way of doing things (it would cause less confusion for
Matlab converts, and it would make it easier to write code that always
works the same way no matter what the users preferences are) but
making that change would probably be unpopular as it would probably
also break a lot of working code.
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
