matrix-vector-op class ?

[Rolf Fabian]

Hi, many thanks for your response to
( http:/ /www.che.wisc.edu/octave/mailing-lists/octave-sources/2000/3 )

Paul: Have you had any feedback on mvo.m? 

Yes, by jwe! He stated, that my proposal of a  new  colon-preceeded operator 
class 
e.g.  ( :* ) for matrix vector operation ( here multiplication for instance ) 
causes conflicts 
with the range colon operator if negative limits are involved or explicitely 
signed limits are
involved in ranges ( e.g. 1:+3 ). And he's correct!  I had to agree, that I 
overlooked this problem.
jwe: .....
jwe: What about
* 5:-2
jwe: Is that a range (equal to [-5, -4, -3, -2], as it is now) or some kind of 
matrix-by-vector operation?
jwe: If you'd like to discuss this, can you post a message to help-octave?

Most propably you've noticed,  that I didn't start such a discussion on the 
list yet.
But I'm still convinced, that implementation of matrix-vector-operators (of 
compatible sizes operands)
is a MUST because such a feature is needed VERY OFTEN e.g. relative scaling of 
plots, 
row or column normalization of matrices ..

In order to avoid the above mentioned conflicts, we have to request that signs 
of range-delimiters
must be within parentheses e.g.  5:(-2)   or  1:(+3)  for the examples above. 
That's all, but we'll run into 
considerable backward- ( and maltlab-) compatibility problems. In  summary, a 
colon-identifier for such
an operator class causes parser conflicts and therefore seems to be out of 
discussion
( if we insist on the current handling of signed range delimiters).

The reason of my choice to propose a colon  as an identifier for a new 
mv-operator class lies in it's
mnemoic power. If we look e.g. at multiplication operators, we would have
                A  *  B      ( matrix-by-matrix )
                A .*  B      ( matrix element-by-element )
                A :*  B      ( matrix-by-vector)        << proposed
and such a sequence looks quite ,natural' to me.

But, a colon is'nt a must! It could be anything else, like
                A  ..*  B      ( matrix-by-vector) 
where the identifier mimics a row  instead of a column ( : ) .
But unfortunately,  this tag causes even more conflicts ( try e.g.  1..+2 or 
1../3 , such
statements are necessary for compatibility with matlab line -continuation 
operator ).

If I inspect my (german) keyboard, there are less than a handfull of  
international chars
 which have no meaning to octave's parser and might be candidates

         ?      |- error: invalid character `?' 
@       |- error: invalid character `@' 
        $       |- error: invalid character `$'
}       |- error: invalid character `}'
{       |- error: invalid character `{'

Any other single char is already in use either by octave or for compatibility 
with ML (e.g. tilde ,~').
Curly braces are already common in ML's newer versions and so should be 
reserved. IMO, 
the question mark should also be reserved to be open  for a C-like ,?-operator' 
implementation.

Remaining ,@' and ,$' which both look ugly to me 
        A @* B
        A $* B
or combinations of two (or more chars). 

So,  what to do?
Personally, I would still prefer a  colon-tag for a possible  mvo-class in 
combination with 
a new global flag in order to avoid  backward compatibility.  But I'm afraid 
that jwe doesn't like it. 

Paul: So far the best I've come up with is
Paul: A = B .* x(:,ones(columns(B),1))
Paul: which isn't so bad, but it does seem a bit silly having to create a  
whole separate matrix to do this.

>> Thanks, this is exactly the reason for coding ,mvo.m' <<

Any comments / opinions ?   Rolf




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

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------