Hi Toby, > At the moment, I have the following semantics for *: > > Matrix * Matrix -> Matrix (matrix product) > Matrix * Vector -> Vector (matrix product) > Matrix * Scalar -> Matrix (scalar product) > > Vector * Vector -> Matrix (outer product) > Vector * Scalar -> Vector (scalar product) > > Scalar * Scalar -> Scalar (scalar product) > > [Vector * Matrix is undefined] > > I chose the outer product for the Vector*Vector operation because it > seemed most operationally consistent with my choice for Matrix*Matrix > and Matrix*Vector. As in NumPy, the inner product is calculated with the > dot() method. > > Element-wise multiplication and division are provided in the > element_prod() and element_div() methods. > > I think this is a fairly sensible scheme. I'm open to leaving > Vector*Vector undefined, but it makes me a bit uneasy. I think this is > because I don't want an operator to be unexpectedly unavailable.
I consider Vector * Vector -> Matrix to be surprising or at least somewhat non-intuitive. Following your operations, the most reasonable definition would be > Matrix * Matrix -> Matrix (matrix product) > Vector * Vector -> Vector (element-wise product) > Scalar * Scalar -> Scalar (scalar product) so that operator* maps elements from the same 'space' back into the same space again. I don't see any reason why Vector*Vector->Matrix should be 'more suited' than Vector*Vector->Scalar, hence better to use inner() and outer() in such case. If I'm not mistaken, dot() is just a forward to inner() in NumPy, so this would be consistent. On the other hand, I don't see any problem with leaving vector*vector undefined... Best regards, Karli ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
