Hi Toby, > The main difficulty with following the conventions is that it's not > clear which is the convention to pick. NumPy provides both a matrix() > class and a ndarray() class -- the former has semantics closer to matrix > algebra, whilst the latter is designed to be closer to having more > generalised tensor semantics; there is no vector primitive in NumPy. > > The NumPy matrix class has matrix product semantics for the * operator, > and I think sticking with that shouldn't cause confusion, because in > (py)ViennaCL, one knows what rank one's object is: you create a Matrix() > object, and then follow the numpy matrix() convention -- not the > ndarray() convention; if you have a rank-n tensor ndarray instance, then > you'd expect different semantics from an explicitly rank-2 Matrix > instance. > > I think that, because the different types keep the semantics clear, and > there is a precedent in numpy.matrix(), it should be OK to stick to the > matrix product for *. In a NumPy guide for MatLab users, the authors > say, "You can use array for the bulk of your code, and switch over to > matrix in the sections where you have nitty-gritty linear algebra with > lots of matrix-matrix multiplications"[1]. I think that's probably a > reasonable expectation for pyViennaCL users, too. > > [1] http://wiki.scipy.org/NumPy_for_Matlab_Users
Hmm, NumPy probably won't win a user API consistency award for this choice ;-) As you say, in such case I opt for using the NumPy matrix convention, particularly as the PyViennaCL object is also of type Matrix(). Coming back to the original question of how to deal with operator* for vectors: Is np.inner(a, b) the most common way of computing the inner product? If so, then let's just use a function 'inner' for this purpose. Similarly, outer() for the outer product. operator* is then available for scaling vectors and matrices only. 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
