Hi Toby, >> 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... > > I quite like your dimensionality-preserving reasoning, so I updated it > according to your scheme above.
Thanks - we may find reason to reconsider the vector*vector case later, but at least it looks consistent for the moment. > I also have a couple of questions about operations on heterogeneous > matrix types. Principally, should I build infrastructure anticipating > (for instance) the product of a column-major and a row-major matrix? Or > a sparse matrix and a dense matrix? Or should users just convert their > matrices to homogeneous types? Products of matrices with different layouts are already supported. You can run C = prod(A, B) with any combination of row-major and column-major for each of A, B, and C. On the long run this flexibility will also be provided via the scheduler and generator for other operations, so you should definitely design the infrastructure such that it can deal with that. > Also: do you intend to support operations > on sparse matrices in the scheduler? So much to do, so few hours in a > day... Yes, sparse matrices will also be handled soon. The scheduler needs to be able to deal with *all* the operations the API currently provides before the release. As you write, so much to do, so few hours in a day... ;-) 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
