Re: matrix-vector-op class ?

[Paul Kienzle]

Why not just stick with the ".*" operator?  It is a natural extension
since scalar .* matrix multiplies each element by that scalar, 
vector .* matrix multiplies each row/column (depending on shape) by
that vector, and matrix .* matrix multiplies each element-wise.  Shape
must match in 0, 1 or 2 dimensions, and be of length 1 in the remaining
dimensions.

You could hack it quickly enough into liboctave/mx-op-defs.h by making
MM_BIN_OP, MM_CMP_OP, MDM_BIN_OP, DMM_BIN_OP check for one of the
dimensions being one and the other dimension matching the same dimension
of the matrix.  Better might be to define VM_BIN_OP, MV_BIN_OP, 
VM_CMP_OP, MV_CMP_OP, VDM_BIN_OP, DMV_CMP_OP, but I wouldn't know how
to tell the parser to use these if one dimension of one argument is one.

Paul Kienzle
address@hidden

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